As some people have hopefully noticed, the how-to-rekey.txt document for the OPENAFS-SA-2013-003 advisory mentions a migration procedure that does not require the involvement of realm administrators for MIT and Heimdal. For Active Directory, it sort of mentions that a similar procedure exists, but it doesn't say how to do it.
Chris Garrison expressed interest in hearing more about this, so with his permission I'm reproducing here his question that instigated this conversation, and I'll try to explain the procedure a bit. The original question, from jabber: > Chris Garrison: does the AFS service principal have to have > afs/cell/DOMAIN as its name? Can it be newafs/cell/DOMAIN? I ask > because our AD admins had to check a DES-only bit for our service > principal to work once upon a time. So, if we want to transition to a > new DES-less principal, it'll take coordinating timing with the AD > admins for our switchover, where if we had another name to use, we > could have it all set up beforehand. Also to get this out of the way (others have asked this, too): yes, the principal name must be afs/cell@REALM. However, you can generate new keys yourself without an AD admin for the switchover, and get them to later turn off the DES bit on the AFS account to actually enable using stronger enc types. This still involves potential downtime while you distribute the keys, but during that downtime/switchover phase, you don't need the AD admins. The key part of this is that we generate new keys for both DES and non-DES. We can do this as a non-admin using msktutil, using the account credentials for the AFS account. If you don't know the password for the AFS account in AD, you can generate a keytab using the existing KeyFile using the steps in how-to-rekey.txt that mention 'asetkey list'. If you only have the credentials for the afs/cell@REALM principal, you will need the --keytab-auth-as option to msktutil. Right now the newest version of msktutil (0.5) does not have this option, so you'll need a patch for it: <http://repo.or.cz/w/msktutil.git/patch/234deef2dd00c4f42d5ba8de5de941855a8e4a56> Anyway, you can run something like this to generate the new keys: $ msktutil -k /tmp/afs.keytab --use-service-account \ --account-name afs-cell -u --service afs/cell \ --keytab-auth-as afs/cell --enctypes 0x1F The options you should use may change depending on your setup, but the important one that's different from "normal" is the --enctypes option. This will turn on all enctypes for the principal. If you don't specify this and leave it as the default, msktutil will try to only turn on non-DES enctypes and clear the DES_ONLY bit for the account. Since it cannot clear the DES_ONLY bit for the account since you're not an admin, it will result in the allowed enctypes list to be set to only non-DES enctypes, and the DES_ONLY flag will still be set. Since the DES_ONLY bit requires DES, and the list of allowed enctypes prohibits DES, you would then be unable to acquire tickets at all for the account (at least, that is my experience; I'm not sure if different policy or Windows versions can affect this). So after running that command, you have an afs.keytab file that contains both single DES and non-DES keys for the AFS service princ. What you need to do next is to add the DES keys from the keytab into the KeyFile, and then put the non-DES keys into rxkad.keytab. Remember that you should not put single DES keys into rxkad.keytab. To get the single DES key into the KeyFile, you should be able to use the old asetkey command like in the old days. Something like: # asetkey <kvno> /tmp/afs.keytab afs/cell@REALM Removing the single DES keys to create a DES-less rxkad.keytab file can be done with the regular ktutil command. The exact commands to run are specified in a proposed update to how-to-rekey.txt. They should eventually be on the web site, but in the meantime, you can view those instructions here: <http://git.openafs.org/?p=openafs-web.git;a=patch;h=5b81778334858760a9ed6cc3da875accb44660c4> After that, you should deploy the KeyFile and rxkad.keytab that you just generated to all servers in the cell and restart them, as per the regular migration procedures. Once that is done, all of the servers should now be able to accept authenticated users that are using either DES or non-DES AFS service tickets. The DES_ONLY account bit is still set in AD, and authentication should continue to work. Now you can request the AD admins to turn off the DES_ONLY bit for the AFS service account. Whenever they do, authenticating users should now start to get non-DES AFS service tickets, but all of the servers should accept them and everything should still work. Once you've verified that everything still works and after you've waited for any extant tokens to expire, you can get rid of the KeyFile. Or if you're on 1.4, you can remove the keys from the KeyFile and generate random keys, as per the migration documentation. Note that the above has not been rigorously tested or anything; while I've tried the various parts of this and believe it should work, it certainly has not been tried in a 'real' environment. I kind of gave up on including it in the official documentation when I realized you needed an AD admin to clear the DES_ONLY bit, so all of the official procedures were focused on more. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
