Kerberos V, AFS, and Windows 2000

I now appear to have AFS working in Windows 2000. But before I expound on that, lets back up to talking about seamless authentication in Red Hat Linux.

There are currently two methods of being authenticated by my hosts in the Kerberos realm, at least as far as SSH is concerned: you type in your password which is successfully authenticated against the KDC, or you have a Kerberos ticket (TGT, I think, right?) in the realm already. In the first scenario, no problem, I can get you AFS credentials on login. Go in to /etc/sysconfig/system-auth and replace all instances of pam_krb5.so with pam_krb5afs.so. Done. The output of klist looks a little different after you log in, but I’m pretty sure this is working. In the second case, where you’re authenticated thanks to the Kerberos/GSSAPI patches to SSH, I’m not totally sure. For starters, stick forwardable = true in /etc/krb5.conf under the libdefaults section. This is going to make sure that once you log in on host A, then SSH to host B, your TGT that you had on host A magically sticks with you on host B. I don’t think you get an AFS token, though, and I do believe that no PAM calls are made by SSH when it authenticates you via Kerberos/GSSAPI/whatever. Perhaps this is fixable; if it could open a session or something I think pam_krb5afs might be nice enough to fetch us AFS credentials. I’m personally considering stuffing aklog in /etc/profile or something, though. I guess I’m going to have to look in to this more.

Anyway, now on to Windows. The documentation for Windows seems to be lacking, actually, but I somehow made it through. First I decided to get Windows authenticating against my MIT Kerberos V KDC. On your Windows 2000 CD there’s a directory called \Support\Tools. Run the setup.exe in there and install it. These are some Resource Kit tools, including the all-important ksetup.exe which we’re going to be using quite a bit.

Now check out Turbo Fredriksson’s comments on how ey got Windows 2000 to authenticate to an MIT KDC. Someone else on the same list spoke of “a [bug] in MIT Kerberos 1.2.3-1.2.6 that breaks Microsoft clients”. Also of importance to our cause is Microsoft’s “Step-by-Step Guide to Kerberos 5 [...] Interoperability which is somewhat OK. There’s also Microsoft’s “Answers to Frequently Asked Kerberos Questions”, which I don’t think I used much if at all. Finally, check out this all important post about having to use pre-authentication to make W2K authenticate to an MIT KDC. Indeed, if you read all the threads on “Win logon to a MIT Kerberos V KDC?” above in September and October archives on that list you’ll find more useful information.

With our reading out of the way, lets get on with the action. First make a host principle on your KDC for your W2K computer. The principal, as with other host principals, should be called host/HOSTNAME.REALMNAME. For example, my W2K computer is called bigmama, and my realm is myrealm.com, so I’d make my host principal host/bigmama.myrealm.com. Don’t use -randkey to generate this, though; assign it a password. You’ll have to type this in to Windows by hand. (Anyone know of a better way to do this?) Also, use the parameter -e des-cbc-crc:normal to addprinc; Windows and MIT Kerberos V apparently only have des-cbc-crc and des-cbc-md5 in common. (I wonder if des-cbc-md5 is supposed to be more secure? I kind of doubt it.) So the end command for me looks like addprinc +requires_preauth -e des-cbc-crc:normal host/bigmama.myrealm.com. Now go over to your windows box and run the sequence of commands in the first post in the above reading. This is a little different from the MS instructions, but I think it works. Now reboot. Don’t be a lazy ass; reboot. Seriously.

While your Windows box is rebooting, invent a cure for cancer. With the time you have left after that, still waiting for the Windows box to come back, go ahead and check all your user principles in the KDC. They need to have pre-authentication turned on. If you getprinc a principal from kadmin and don’t see something like Attributes: REQUIRES_PRE_AUTH, you need to turn this on for the principal. Try something like modprinc +requires_preauth PRINCIPALNAME. In my setup I did not need to turn on pre-authentication for krbtgt/MYREALM.COM or host/bigmama.myrealm.com, as one of the posts in the above threads suggested. I’m not sure of the security concerns involved in requiring or not requiring pre-authentication for either of these principals. You can stick default_principal_flags = +preauth in /var/kerberos/krb5kdc/kdc5.conf under the configuration for your realm to make pre-authentication a default attribute for all new principals created. (You may need to restart the kadmin service and/or the krb5kdc service.)

Hopefully your W2K box is back up by now. Go to log in. Notice the third box where you can now select something like “MYREALM.COM (Kerberos Realm)” IIRC. You need to select that. Type in your user name and password. Hopefully you’re authenticated and logged in successfully. Good job Tonto. If you have problems, try checking /var/log/krb5kdc.log on your Red Hat KDC. Also, I forgot to mention this, but this is only authentication; you need to have a local account on the box already created to be able to authenticate via the KDC.

So now we’re authenticating via Kerberos V. Time for AFS. Install the OpenAFS client for Windows. You should probably reboot now, I think. Next go and install Wake. Wake is apparently a user-friendly interface to Kerberos and AFS, in addition to supposedly being the only working method for basically doing an aklog from Windows these days. When installing make sure to turn off all the Rose-Hulman stuff, and tell it that you want it to get Kerberos tickets from Windows. You will need a C:\WINNT\krb5.ini, such as mine:

[domain_realm]
	.myrealm.com = MYREALM.COM
	myrealm.com = MYREALM.COM

[realms]
	MYREALM.COM =
	{
		kdc = kerberos.myrealm.com
		admin_server = kerberos.myrealm.com
		default_domain = myrealm.com
	}

Now stick the Wake shortcut from the Wake group in the “All Users” startup folder. Reboot for fun (or maybe just log out). When next you log in, hopefully you’ll still authenticate to Kerberos V, then Wake will get you some AFS tickets and tokens. The Wake icon in my system tray shows a black rectangle with a green line through it behind a black circle which also has a green line through it; I presume this means “we’re working.” Also, the red “X” on your AFS client system tray icon should eventually disappear once it realizes it’s gotten some tickets/tokens/whatever.

Note that we’re not enabling the AFS client “get tickets when I log on” thing because it doesn’t work in a setup with Kerberos V instead of the AFS Kerberos server; at least, this is the case from what I’ve read. There may be other ways to do the equivalent of an aklog, but I haven’t found them, and Wake works quite swimmingly.

I have one anomaly in my /var/log/krb5kdc.log:

Jan 20 04:19:49 kerberos.myrealm.com krb5kdc[5466](info): TGS_REQ
(7 etypes {23 -133 -128 3 1 24 -135}) 10.1.2.3(88): UNKNOWN_SERVER:
authtime 1043050761,  username@MYREALM.COM for
HOST/BIGMAMA-AFS@MYREALM.COM, Server not found in Kerberos database

I don’t exactly know what this is, but I’m hoping that I can turn off some option in the AFS client and make it go away.

This is kind of incomplete, but I’ve done a lot of shit to get this all working and I don’t remember half of it. If you have problems you can try mailing me, but I think I doubt I can help you. Now I think I’ll play with performance some, see what I can do. Then I need to convert my existing desktop box fully over to LDAP and start migrating my UID upwards. I also found LDAP versions of useradd, usermod, and userdel. I guess I need to think about some administration issues. I don’t know if I’m going to use AFS’ uss tool or not. I haven’t really decided where home directories should go.

(Note: the use of “ey” above was a gender-neutral pronoun, supposedly. Check out the Gender-Neutral Pronoun FAQ.)