[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. You should not using the -kvno option when creating a keytab with ktpass. Doing places a kvno into the keytab but does not set the kvno within AD. Leaving off the -kvno option writes the actual kvno to the keytab. Jeffrey Altman On 3/4/2010 7:19 PM, Stephen Joyce wrote: > I'm trying to test trusting a Windows 2008R2 krb5 realm and am obviously > missing a step somewhere. I get tokens that don't work. I've been > following the steps at > http://www.dementia.org/twiki/bin/view/AFSLore/AdminFAQ#3_51_Can_I_authenticate_to_my_af > > > I've scanned the list archives and have read about the specific error, > but it hasn't helped me solve my problem so far. > > My setup: > Windows 2008R2 KDC, with afs/[email protected] DES-only ticket created. > > Windows 2008R2 massaged to allow DES tickets. > > 1 test AFSDB > 1 test AFSFS > 1 test client > > My keyfile contains 3 pre-existing keys that I'd like to maintain in the > hopes of conducting a graceful migration from MIT-K5 to 2008R2-K5 auth. > Pre-existing keys are in slots 0,1,2 of the keyfile. > > I've created the afs/[email protected] princ and keytab on Windows and > transferred to linux securely. This enctype is DES-CBC-CRC. > > On the first test server, klist -e -k (new keytab) -t -K shows a KVNO of > 3 and "DES cbc mode with CRC-32". Yay! > > I have configured krb5.conf on both test servers and test client. > > I used asetkey add 3 (new keytab) afs/[email protected] to add the new > key to test AFSDB and test AFSFS and bos restart'ed them. > > I can successfully do the following: > > server> kinit -kt (keytab) afs/[email protected] > server> klist > (shows krbtgt/[email protected]) > > server> kvno afs/[email protected] > (shows kvno = 3) > > client> kinit (regular user) > client> klist > Ticket cache: FILE:/tmp/krb5cc_uid > Default principal: u...@ad > > Valid starting Expires Service principal > 03/04/10 18:23:47 03/05/10 04:23:50 krbtgt/[email protected] > renew until 03/11/10 18:23:47, Flags: FPRIA > Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 > CTS mode with 96-bit SHA-1 HMAC > > client> aklog -d > Authenticating to cell cellname (server testafsdb.cellname). > We've deduced that we need to authenticate to realm AD.DOMAIN > Getting tickets: afs/[email protected] > Using Kerberos V5 ticket natively > About to resolve name foobar to id in cell cellname. > Id 12345 > Set username to AFS ID 12345 > Setting tokens. AFS ID 12345 / @ AD.DOMAIN > > client> tokens > Tokens held by the Cache Manager: > > User's (AFS ID 12345) tokens for a...@cellname [Expires Mar 5 04:23] > --End of list-- > > client> klist -ef > icket cache: FILE:/tmp/krb5cc_31846 > Default principal: [email protected] > > Valid starting Expires Service principal > 03/04/10 18:23:47 03/05/10 04:23:50 krbtgt/[email protected] > renew until 03/11/10 18:23:47, Flags: FPRIA > Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 > CTS mode with 96-bit SHA-1 HMAC > 03/04/10 18:25:53 03/05/10 04:23:50 afs/[email protected] > renew until 03/11/10 18:23:47, Flags: FPRA > Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32 > > However I see two symptoms. > 1. The client logs the following on the console: > "afs: Tokens for user of AFS id 12345 for cell cellname are discarded > (rxkad error=19270408)" > 2. The tokens don't work, of course (when trying to create a file in a > volume on the test AFSFS, which would otherwise be allowed). > > The versions of openafs on all test PCs is not *new*, but is in the > 1.4.x line. > > I'm sure that there's some step I've missed along the way. Any hints? > > Cheers, Stephen > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info >
smime.p7s
Description: S/MIME Cryptographic Signature
