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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
