[OpenAFS] That infamous, magnificent bastard, error 19270408.

[Marcus Watts]

Quoting randomly from past exchanges:
> by your friend and mine, rxkad error 19270408.  Our windows clients  
> are working perfectly, and our Solaris -8- configuration is working  
> perfectly with its internal k5/k4 bits but our Solaris 9  
> configuration against strict Krb5 isn't.  It's a pretty standard  

Ok.  If I understand this right, your past clients are using
"krb524d" to convert tickets -- and are storing a "real" kerberos 4
ticket.  This latter key can *only* be des, because that's the
only encryption mode supported by kerberos 4.
If you have slightly newer code, you may have a version
of aklog that does "rxkad 2b".  If so, it's unwrapping the
kerberos 5 ticket, throwing away some bits it doesn't need,
and sending the guts.  If you have the very newest code, you
probably have a version of aklog that sends the kerberos 5 ticket over
"as is".  This is probably what your solaris 9 + openafs 1.4.1 client
is doing.

Onto your error:
19270408 = RXKADUNKNOWNKEY
this can be returned in the source several ways:
rxkad/rxkad_server.c -- around line 349, just before a call to
	tkt_DecodeTicket -- if ts->get_key returns nz.
	Usually get_key is a reference to afsconf_GetKey.
	The fileserver has a wrapper that spits out an
	interesting message -- see [1] "to try" below.
rxkad/ticket.5.c - label at "unknown_key:".
	There are 2 goto's to this label:
	/a/ etype is not ETYPE_DES_CBC_CRC, ETYPE_DES_CBC_MD4,
		or ETYPE_DES_CBC_MD5
		Of course, when you did "klist", it looks
		like you "shouldn't" hit this condition.
	/b/ get_key (same logic as rxkad_server) returns
		an NZ code.

So, some things to try:
[1] fileserver:
does this message appear in FileLog ???
	afsconf_GetKey failure: kvno %d code %d
--> attempt to present kvno that does not match anything in KeyFile
--> some other problem.  (so, what is the value of code ?)
	Absence of message but presence of error probably means
	that you've hit ticket5.c case /a/ above; the bad etype.
	If so, thing [3] to try below will be very interesting...

[2] solaris 9.  Try "aklog -524".  This will cause aklog to
use "old" the 524 logic.  It might work.  Who knows?  Certainly
will rule out a lot if it does...

[3] kadmin
run kadmin.  Do this:

kadmin:  getprinc afs/cats.ucsc.edu@CATS.UCSC.EDU
kadmin:  getprinc afs@CATS.UCSC.EDU

now check the results.
You should not have a "cats@CATS.UCSC.EDU" principal.
If you do have one, beware.
	Its keys must match those in your keyfile, and must not
	duplicate those for cats/cell@realm.
You should have exactly one key type; it must be des,
and it should be des-cbc-crc32.  If you have other key types,
beware.

Here's what I get in my test cell (which I named cats.umich.edu
for absolutely no reason connected to your cell...):
kadmin:  getprinc afs@CATS.UMICH.EDU
Principal: afs@CATS.UMICH.EDU
Expiration date: [never]
Last password change: Tue Aug 30 04:14:44 EDT 2005
Password expiration date: [none]
Maximum ticket life: 4 days 04:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Aug 30 04:14:44 EDT 2005 (mdw/admin@CATS.UMICH.EDU)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 3, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin: 

NOTE: There is exactly one key type here.  des-cbc-crc32.

Here is something you probably should NOT see:

kadmin:  getprinc afs-k5@CATS.UMICH.EDU
Principal: afs-k5@CATS.UMICH.EDU
Expiration date: [never]
Last password change: Mon Jul 31 18:13:02 EDT 2006
Password expiration date: [none]
Maximum ticket life: 4 days 04:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Jul 31 18:13:02 EDT 2006 (mdw/admin@CATS.UMICH.EDU)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 4
Key: vno 2, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 2, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 2, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 2, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:  

Note - 3 key types here.  Note, this server principal is "afs-k5".
The server logic for that in my test cell understands aes keys.  If
this were a key for just "afs", this would be Bad, because
the rxkad logic would not know how to handle aes or des3.
Instead, it would error out, at the server end, with
your friendly error, 19270408 .

[4] here's something else that might be interesting to try:
pull over an old copy of "pts" from your solaris 8 environment.
Run that latest aklog.  Now, without touching afs inbetween, try
the old copy of pts.  With luck, you'll see some message like:

	% pts e mdw
	libprot: funny kvno (256) in ticket, proceeding
	Name: mdw, id: 25131, owner: system:administrators, creator: uniqname,
	  membership: 82, flags: SOM--, group quota: 29.
	% 
That "funny kvno" is afs's way of saying that it's going to pretend
that it's not an rxvab ticket and is just going to use rxkad.
More importantly, that value 256 means that your aklog really did
store a straight kerberos 5 ticket into ktc, and it isn't
doing rxkad 2b or 524.

[5] find your krb5kdc logs.  Look at requests for the indicated good &
bad hosts.  Using my test cell, here are some sample lines:
/a/
Aug 21 21:58:01 lose-the-lion.ifs.umich.edu krb5kdc[26664](info): TGS_REQ (1 etypes {1}) 141.213.229.100: ISSUE: authtime 1156211875, etypes {rep=18 tkt=1 ses=1}, mdw@CATS.UMICH.EDU for afs@CATS.UMICH.EDU
/b/
Aug 21 21:58:32 lose-the-lion.ifs.umich.edu krb5kdc[26664](info): TGS_REQ (1 etypes {18}) 141.213.229.100: ISSUE: authtime 1156211875, etypes {rep=18 tkt=18 ses=18}, mdw@CATS.UMICH.EDU for afs-k5/cats.umich.edu@CATS.UMICH.EDU

in case a, my tgt was aes (18), and the server ticket & session key are des
{tkt=1 ses=1}, ticket type because that's the best key in my kdc for that service,
and session key because my copy of aklog claimed it only did des "(1 etypes {1})"
in case b, my service supports aes, so I got a ticket encrypted under aes {tkt=18}
containing a session key encrypted under aes {ses=18}.  (My copy of aklog
happened to claim it only did aes... (1 etypes {18})".)

[6] this isn't really a thing to try, but I'm curious
and perhaps the explanation will shed more light on your
problem.  You have kvno 1 and 3 in your keyfile, but
your kdc only issues kvno 1.  How did you create the
2 keys in your keyfile, & why does your kdc not know of
kvno 3?

					-Marcus