Ok thanks for all the input. Seems pretty straight forward for MIT kerberos. Note I updated my /var/kerberos/krb5kdc/kdc.conf encryption types:
supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal I had to restart the kadmin server, (a reload did not work), to get the new encryption types while changing a password. I tested ktadd on a test user and the only the above keys get created. Summary: upgrade all servers to openafs 1.6.5 ktadd -k /tmp/rxkad.keytab afs/cell cp rxkad.keytab to /usr/afs/etc/rxkad.keytab on all servers restart all servers keep KeyFile in place for a day or more then rename and touch CellServDB On Tue, Jul 30, 2013 at 7:55 PM, Benjamin Kaduk <[email protected]> wrote: > Andrew is spot-on, just two minor clarifications (inline) > > > On Tue, 30 Jul 2013, Andrew Deason wrote: > >> On Tue, 30 Jul 2013 14:39:56 -0400 >> John Sopko <[email protected]> wrote: >> >>> Where is the session key for the afs/cell@REALM service principal >>> derived from? >> >> >> Session keys aren't usually derived from anything in the principal; >> they're chosen randomly. There is a situation for OpenAFS specifically >> where we derive a DES key from other things, but that only happens if >> you disable DES for the entire KDC. That is, for an MIT KDC, it doesn't >> have anything to do with changing the enctypes on the service principal, >> but rather if you disable DES entirely in the KDC configuration. (As you >> may have seen on the list, things here are different for various Heimdal >> versions, but for MIT krb5 you don't need to deal with that.) >> >>> If I remove the des-cbc-crc encryption type from both the >>> afs/cell@REALM and the user principals will things still work without >>> having to upgrade all clients to openafs 1.6.5? >> >> >> Yes, probably. You should really try testing with a test environment or >> test principal if you're unsure about what's going on, though. (You also >> do need to upgrade and configure the _servers_ if that's not clear.) > > > The MIT KDC is happy to generate a DES session key even if a service does > not have a DES enctype in the KDB, for KDC's prior to the 1.11 release. The > 1.11 release gives more control over this feature. > > >>> But when I create a user or a user changes their passwd they do not >>> get the "des-cbc-crc" encryption type, for example kadmin for a user >>> shows: >>> >>> Principal: [email protected] >>> Number of keys: 6 >>> Key: vno 38, aes256-cts-hmac-sha1-96, no salt >>> Key: vno 38, aes128-cts-hmac-sha1-96, no salt >>> Key: vno 38, des3-cbc-sha1, no salt >>> Key: vno 38, arcfour-hmac, no salt >>> Key: vno 38, des-hmac-sha1, no salt >>> Key: vno 38, des-cbc-md5, no salt >>> >>> Notice there is no des-cbc-crc encryption type for a user principal, I >>> believe this is done on purpose. >> >> >> You have other des-* enctypes in there, though, just by the way. >> >>> Using MIT "klist -e" command to show the encryption types while logged >>> in shows: >>> >>> Valid starting Expires Service principal >>> 07/30/13 14:16:12 07/31/13 14:16:12 krbtgt/[email protected] >>> renew until 07/31/13 14:16:12, Etype (skey, tkt): >>> des3-cbc-sha1, des3-cbc-sha1 >>> 07/30/13 14:16:12 07/31/13 14:16:12 afs/[email protected] >>> renew until 07/31/13 14:16:12, Etype (skey, tkt): des-cbc-crc, >>> des-cbc-crc >>> >>> So currently the skey (session key) and tkt key for afs/cs.unc.edu >>> is des-cbc-crc. >>> >>> So if I re-key afs/cs.unc.edu service principal to NOT USE des-cbc-crc >>> my understanding is you still need a des-cbc-crc session key unless >>> you upgrade all clients which is not feasible at this time. Will I be >>> ok without a des-cbs-crc key for the user and the service principal? > > > AFS doesn't care whether it's des-cbc-crc or des-cbc-md5; any DES enctype > will do. > > -Ben Kaduk > > >> You should be fine without a des-cbc-crc key. The session key is not >> something stored in the database or anything like that; it is generated >> every time someone gets an AFS token. MIT krb5 always permits single DES >> session keys, unless the KDC has turned off single DES entirely, or >> unless you twiddle with some really new options that I think don't exist >> in 1.10. >> >> If you want to see an example after the AFS service princ no longer has >> a DES key: >> >> kadmin.local: getprinc afs/localcell >> Principal: afs/localcell@LOCALCELL >> [...] >> Number of keys: 4 >> Key: vno 7, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt >> Key: vno 7, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt >> Key: vno 7, Triple DES cbc mode with HMAC/sha1, no salt >> Key: vno 7, ArcFour with HMAC/md5, no salt >> >> $ kinit adeason >> Password for adeason@LOCALCELL: >> $ aklog >> $ klist -e >> Ticket cache: FILE:/tmp/krb5cc_1000 >> Default principal: adeason@LOCALCELL >> >> Valid starting Expires Service principal >> 07/30/13 14:13:37 07/31/13 14:13:37 krbtgt/LOCALCELL@LOCALCELL >> Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES >> cbc mode with HMAC/sha1 >> 07/30/13 14:13:43 07/31/13 14:13:37 afs/localcell@LOCALCELL >> Etype (skey, tkt): DES cbc mode with CRC-32, AES-256 CTS mode with >> 96-bit SHA-1 HMAC >> >> >> You can also test out some of this service principal and enctype stuff >> without any AFS infrastructure, if you want. If you run: >> >> $ kvno -e des-cbc-crc afs/cellname@REALMNAME >> >> You'll be doing pretty much the same thing that any old aklog does, in >> terms of interacting with the krb5 KDC. You can try that out and test >> other service principals if you want, to see what happens with them. >> >> -- >> Andrew Deason >> [email protected] >> >> _______________________________________________ >> OpenAFS-info mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > -- John W. Sopko Jr. University of North Carolina email: sopko AT cs.unc.edu Computer Science Dept., CB 3175 Phone: 919-590-6144 Fred Brooks Building; Room 140 Chapel Hill, NC 27599-3175 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
