[OpenAFS] krb5 trust, rxkad error=19270408... I'm missing something

[Stephen Joyce]

A lil' bit more testing, but no solution yet.

Extracted a new keytab on 2008R2 per Jeff's suggestion. I omitted the kvno 
flag, and repeated extraction until I got a kvno of sufficient value not to 
interfere with existing keys.

For ktpass:
-crypto ALL creates a keytab with DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, 
AES256-SHA1, AND AES128-SHA1 ciphers despite specifying +DesOnly (and 
previously checking the des only flag under account properties).

+SetUpn is the default for ktpass in 2008R2. The Upn is set to 
afs/cell.name. I also tried using afs/cell.name@AD.DOMAIN, but could not 
aklog with that value.

The new keytab, when installed (and the former removed), shows the same 
results as before: kinit and aklog work, but AFS doesn't accept the tickets 
despite the fact that the key is in the keyfile in the correct slot for the 
kvno. afs/cell@AD keytab is DES, kvno is identical in all locations...

Possibly unrelated, but I've tried modifying krb5.conf on the test client 
to disable all but DES-DBC-CRC, but when the krbtgt for the 2008R2 domain 
in the ccache is DES, aklog fails with Kerberos error -1765328343. If I 
make the same change on a client in our production setup, aklog still works 
fine.

google suggested verifying the kvno in AD by examining 
msDs-KeyVersionNumber in ADSI. I can't find that attribute vi ADSI in 2008. 
But since I'm no longer specifying -kvno, and it's incrementing on each 
iteration, presumably wherever the 2008 schema stores the kvno, it's 
correct.

Any other ideas welcomed.

Cheers, Stephen
--
Stephen Joyce
Systems Administrator
PANIC - Physics and Astronomy Network Infrastructure and Computing
University of North Carolina at Chapel Hill 
voice: 919.962.7214
fax: 919.962.0480

On Thu, 4 Mar 2010, Jeffrey Altman wrote:

> On 3/4/2010 10:56 PM, Stephen Joyce wrote:
>> On Thu, 4 Mar 2010, Jeffrey Altman wrote:
>>
>>> [C:\]translate_et 19270408
>>> 19270408 = ticket contained unknown key version number
>>>
>>> What does kvno report when using the regular user?
>>> Is it still three?  My guess is not.
>>
>> After a kinit on a client (to a regular user account in AD), the kvno of
>> afs/cellname@ADDOMAIN is still 3.
>
> well, the error is unknown kvno.  either the kvno in the service ticket
> is not 3 or there is no kvno entry for 3 in the KeyFile.
>
> Unfortunately, there is no mechanism for logging errors from within
> the rxkad security class.  The best you can do is attach a debugger
> to a service that you are connecting to and place a break point at
> each of the two locations where RXKADUNKNOWNKEY is set as the error
> code.
>
>
>