Getting WinXP to authenticate to a MIT Kerberos5 KDC and use AFS, all with single-sign-on, is not too difficult. However it does not appear to be completely (or correctly) documented anywhere.
You will need a correctly configured Kerberos5 domain and AFS server, which is probably its own set of headaches. I haven't done that; it was already setup correctly. I simply connected a WinXP client. The OpenAFS network here is using Kerberos5 natively. There is no krb524 type things going on.
Software I used:
http://web.mit.edu/Kerberos/dist/index.htmlhttp://openafs.org/release/latest.html
https://www.secure-endpoints.com/As of Sep 5 2006, new versions of KfW and the OpenAFS NetIDMgr plugin are available. You must always get the OpenAFS NetIDMgr plugin built for the version of KfW you are installing.
The approach documented here is a very basic configuration with some caveats:
The overall process:
Some useful background reading, if you care:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/kerbinop.mspxhttp://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspxhttp://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspxTo authenticate your WinXP client against an external MIT Kerberos5 server, you need:
The host principal (called a "machine account" by Microsoft) is needed by WinXP. If this is absent or incorrect, you cannot login. I'm not sure what WinXP uses the host prinicipal for; perhaps it is some form of mutual authentication, where WinXP uses the machine account to protect against a fake domain controller.
The host principle must be encrypted with the des-cbc-crc method; nothing else seems to work. Yeah, I know, its a really weak encryption method. If you want to use a random password (which is probably reccomended), make sure you write it down; you need to type this into the WinXP client too. This restriction on encryption methods applies only to the host principal; my own user principal is encypted with with des3-cbc-sha1 method, and that works just fine.
The local account on the WinXP client is part of the odd "trust" relationship that ends up in place between the Kerberos5 domain and the WinXP client. The client maps the Kerberos principal to a local account for the purposes of file permissions, group membership, and so on. (The stuff typically kept in ldap). I added myself the "Administrators" built-in group, and did not worry about it; AFS enforces its own permissions.
The host prinicipal is added using the kadmin tool like any regular Kerberos5 principal:
kadmin q "addprinc -edes-cbc-crc:normal pw {passwd} host/{fqdn}"
On the WinXP client, execute the following in a command prompt window:
ksetup /setdomain {REALM}
ksetup /setmachpassword {passwd}
ksetup /mapuser * *
ksetup /addkdc {REALM} {kdc}
The ksetup program has lots of options; you can see them all by using ksetup /h.
Finally you must reboot your WinXP client. When it starts up again, you should hopefully have the option to login to your Kerberos realm. Even better, if you did everything right, it should work! Woohoo!
Next, you need to install KfW. The OpenAFS client for Windows cannot use the WinXP credentials directly; KfW will import the WinXP credentials into a traditional Kerberos5 ticket for regular Kerberos software, such as OpenAFS.
The latest version (3.0) of KfW comes with a new pluggable framework called the "Network Identity Manager". The idea is that different packages or authentication schemes can install their own plugins into the NetIDMgr; then the user can manage all of their credentials from a single place. Personally I find it very quirky. However, once configured, it will grab your WinXP credentials and convert them into regular Kerberos5 ones.
Unfortunately, I find that is the only useful thing it does, and isnt particularly good at that, either; but you need it, so you live with it.
Once you have installed KfW, start the Network Identity Manager. Use the View -> Layout -> By Location menu sequence; you should see some credentials under the MSLSA: location. It may have already imported them, too; I cant remember the default configuration. If you select the MSLSA: credential, and use the Credential -> Import Credentials menu option you'll get Kerberos API credentials, which are called API: credentials in the list.
Open up the NetIDMgr configuration dialogue using the Options -> General menu option. Under the "Kerberos 5" tree item, there is an "Import Tickets" option. Set it to "always".
We aren't quite finished with this yet, we'll be coming back to it later.
Installing the OpenAFS client asks you a few questions:
It will then prompt for the cell name. Enter your AFS cell name here. The settings for the other options are:
Then you are presented a "AFS Credentials Configuration" dialogue:
Our AFS SRV records in DNS are working, so configuration is quite simple. Once the obligatory reboot is over, you'll be offered a "Obtain new AFS tokens" dialogue when you login. Just press cancel; AFS native authentication is not being used (its going to come from Kerberos). Don't worry! This dialogue is offered only once, not every time you login.
If your SRV records are not working, you'll need to manually edit the CellServDB file. If you have a working unix client, the same file should work. Probably you'll need to restart the AFS client after changing/replacing the CellServDB file.
Once the AFS client has started, you should be able to Run the \\afs\all location, and see your cell.
By now there should be:
The last step remains: getting Kerberos5 tickets into OpenAFS. OpenAFS for Windows client comes with the familar aklog.exe program that does just that. Find it using the Windows Explorer, and run it. The AFS Client window should change from saying "You do not have tokens" to listing the token imported from Kerberos5.
If you install the OpenAFS plugin for NetIDMgr, then when you use the NetIDMgr to get new Kerberos5 credentials you can automatically get OpenAFS credentials. However I find this approach has quite a few limitations:
However, installing the plugin allows you to see the tokens in the AFS cache, as well as the copy stored by Kerberos.
To work around those absurd problems, I use the following friendly batch file called afs.bat which has a shortcut in the "Startup" folder:
c:
cd "\program files\mit\kerberos\bin"
ms2mit
cd "\program files\openafs\client\program"
aklog
The ms2mit program forces KfW to import the MSLSA credentials. The useful feature is that it does not exit until that is done, so makes a useful synchronisation point. Then aklog puts the ticket into OpenAFS.
One page links to WinXP+Krb5+AFS:
