[OpenAFS] no-DES transition with AD without administrator

Andrew Deason adeason@sinenomine.net
Wed, 14 Aug 2013 17:51:48 -0500

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:

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:

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