[OpenAFS] Summary: AFS and Active Directory interoperability
Sat, 3 Sep 2005 13:55:01 +0200
After about two weeks of work I got it working to authenticate against
an Active Directory for gaining access to AFS. As there are many little
details about the procedure of doing this and there is much obsolete and
incomplete information on the internet about the topic I'm giving an
overview of the steps that need to be done.
First I want to remark that I got much help from Sergio Gelato from the
mailing list to get this working.
As a special condition I did a completely new setup of AFS and thus
didn't have to migrate any user data etc.
1) You have to use an up to date OpenAFS version. I got it working with
OpenAFS 1.4.0-rc2 from CVS. In respect to stability you don't need to
worry. I didn't realise any problems except sometimes for the kernel
module (using kernel 2.6) when playing around to much with the AFS
2) Additional software: There are two tools I needed to use Active
Directory instead of kaserver.
asetkey: This utility can read a kerberos5 keyfile and write it into the
aklog: An alternative to klog for getting an AFS token when not using
At least aklog is shipped with the OpenAFS source code but not built by
default. In OpenAFS 1.4.0-rc2 it is built when using the configure
option "--with-krb5" but it didn't compile successfully for me.
asetkey is (or should I say 'once was' ...) part of the AFS-Kerberos5
For my purpose I used the following binary package from debian:
If you don't use debian and can't use .deb packages try the deb2targz
This binary package contains both aklog and asetkey.
3) Create a principal in the Active Directory for afs@<your cellname>.
The passphrase for the principal doesn't matter. Note that it is simpler
to choose the same name for the afs cellname as for your realm. If you
don't you have to configure your AFS servers to use the correct realm
name in krb5.conf
When you created the afs principal extract the key for this principal
using the ktpass command on the windows command line. You should tell
ktpass to export the key using the encryption type DES_CBC_CRC (MD4/MD5
should also be okay).
A very important thing is that you have to tell Active Directory
explicitly to "use DES encryption types" for the afs principal. This is
done in the account properties for afs@<your cellname>
4) Copy the key extracted by ktpass from active directory on your AFS
servers. Now you have to use asetkey to convert the key into an AFS
KeyFile. This is done like this:
asetkey add <kvno> /path/to/AD-Keyfile afs@<your cellname>
Note that you have to specify the correct key version number. Also the
binaries from debian search for OpenAFS configuration files in
/etc/openafs and /etc/openafs/server. I had to create a symbolic link
from the path of the OpenAFS KeyFile and ThisCell, CellServDB to
/etc/openafs/server for asetkey to work.
As I had a clean and new OpenAFS setup I didn't need any old keys from
OpenAFS so I delete all existing keys using asetkey delete before
issuing the above command.
Make sure the key version numbers of AFS and the Active Directory match
after you've written the new key into AFS. You can check this by using
for the AFS KeyFile and ktutil (syntax depends on wheter you use Heimdal
or mit-kerberos5) for the kerberos-key extracted from AD.
5) Now the communication between AFS and Active Directory should already
work. The only difference now is that you have to use aklog instead of
klog to get your AFS token.
To manually test if it works I first get a kerberos5 ticket from AD for
Then I use aklog with verbose output to see if everything is okay
getting the token:
The output should say that it got the correct kerberos realm to
authenticate to and that aklog is using the kerberos5 ticket natively.
In the past it was needed to use something like krb542d to convert
kerberos5 tickets into kerberos4 tickets before aklog could be used but
this is not needed any more as I see it.
aklog then should have generated an AFS token from the kerberos5 ticket.
You can check this using the normal 'tokens' command from AFS.
At this point you should be successfully authenticate as 'testuser' and
be able to work with testuser's homedirectory on AFS for example.
If you get an error like "key version number mismatch" or "unknown key
version number" when trying to access AFS directories after you issued
the aklog command then it is very likely that you either really got a
key version number mismatch for the keys in AD and AFS or the DES
encryption is not correctly enabled on the AD side (which was a problem
that cost me some days of debugging ...).
Well, that's it. I hope this little howto will be useful and saves
someone some time.