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 havn'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 5to4 type things going on.

Software I used:

• WindowsXP Pro, service pack 2
• MIT Kerberos for Windows 3.0
• OpenAFS Windows client 1.4.1
• OpenAFS plugin 1.0.1 for NetIDMgr

The overall process:

1. Get WinXP to authenticate to MIT Kerberos5 domain
2. Installing and configuring MIT Kerberos; obtaining regular Krb5 tickets from the WinXP ones
3. Installing and configuring OpenAFS

Authenticating using Kerberos5

Some useful background reading, if you care:

• http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/kerbinop.mspx
• http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx
• http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx

To authenticate your WinXP client against an external MIT Kerberos5 server, you need:

• A user principal in the Kerberos domain (duh :))
• A host principal account in the Kerberos domain for the WinXP client
• A local account on the WinXP client for the user

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 * *

If you have working SRV records for Kerberos, you can omit this step. Otherwise, you need to also:

    ksetup /addkdc {REALM} {kdc}

passwd

The host prinicipal password for the machine account

fqdn

The fully-qualified domain name for the WinXP client. I've only tested a situation where the DNS domain is the same as the Kerberos domain, where the mapping is trivial.

REALM

The Kerberos realm. These are typically all uppercase version of the the domain name.

kdc

The DNS name of a KDC for {REALM}. This is obtained from DNS using SRV records if not configured explicity.

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!

Installing MIT Kerberos