[OpenAFS] Summary: AFS and Active Directory interoperability

[Matthias Gerstner]

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 
configuration.

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 
OpenAFS KeyFile

aklog: An alternative to klog for getting an AFS token when not using 
kaserver.

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 
migration kit.

For my purpose I used the following binary package from debian:

http://packages.debian.org/stable/net/openafs-krb5

If you don't use debian and can't use .deb packages try the deb2targz 
utility.

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

asetkey list

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 
my user:

kinit testuser
<password>

Then I use aklog with verbose output to see if everything is okay 
getting the token:

aklog -d
<debug output>

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.

Best Regards,

Matthias Gerstner