[OpenAFS] krb5 trust, rxkad error=19270408... I'm missing
Fri, 5 Mar 2010 12:36:53 -0500 (EST)
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.
-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
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
Any other ideas welcomed.
PANIC - Physics and Astronomy Network Infrastructure and Computing
University of North Carolina at Chapel Hill
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