darkness

It’s been a while since I’ve written. I’ve had many late nights working with verin (that’s the name of my new file server, BTW) and I think (I’m coming down with|I have a) cold. Not that it’s any excuse for not making an entry since then. In typical fashion, I’ll now write of events completely out of order.

euphorik and I spent an hour or so tonight talking about depressing music. He thinks August and Everything After is a depressing album. After thinking about it, I kind of agreed. Other artists I think we were both able to agree on: Mazzy Star, Portishead (sort of). I can’t think of any of the others. I guess I don’t think of some of these as depressing, necessarily; some of them occur to me, at least at times, as just being thoughtful and different. What do I know about depression or thoughtfulness, though?

I pretty much have the file server situation squared away. I have a single password for both Windows and Linux, I can access my shared drive in both, and I have some semblance of security. I’ll try and take it step-by-step, but unfortunately I did > instead of >> into a text file that was filled with notes I wanted to write here so I may miss some steps.

First, in a semi-final act of desperation, I mailed the Samba mailing list. Andrew Bartlett was kind enough to reply to me. He gave me a little hope, but this came after I was 2/3 of the way done with the simpler solution of doing Samba 2.2 as a PDC and doing password synchronization. Anyway, maybe someday I’ll try writing the code to put the Kerberos key into Samba’s secrets.pdb or whatever it is, and see how far I get from there.

One thing I realized I had to set up was SSL LDAP, and LDAP Kerberos authentication. In retrospect I don’t think I’m even using this – but at the time I’m sure I thought it was an imperative. To do this I followed the instructions in the LDAPv3 HOWTO. I did “set up a CA” using the OpenSSL mini-CA stuff. Check out /usr/share/ssl/misc for the CA.sh script, IIRC. I started from the section titled “Building OpenLDAP v2″ pretty much. One hazard to watch out for: if you’re using Red Hat 8.0 and you want to do Kerberos (GSSAPI) authentication, make sure to install the cyrus-sasl-gssapi package. Red Hat 8.0’s OpenLDAP is built with the necessary configure options. I did add in all three SSL certification options as given in the HOWTO. I have not created any indexes, though I probably should and quite probably will at some point in the future. I don’t have many ACLs set up, and certainly not as many as the example in the HOWTO. You will need the Kerberos principal and you’ll need to ktadd the key for the principal into /etc/krb5.keytab as shown. One detail: OpenLDAP from Red Hat 8.0 doesn’t run as root IIRC, so you’ll need to make a group to own the /etc/krb5.keytab file, then put the ldap user in that group. Don’t worry if your userPassword attribute doesn’t start appearing in Base64; mine didn’t. For testing OpenSSL, if you can’t get supportedSASLMechanisms to return anything over an unencrypted connection, try going to the next part where you test with an SSL connection; I think in my case, the SSL connection showed the proper results whereas the unencrypted connection displayed no results. YMMV. You can see my /etc/openldap/slapd.conf.

Next I must have set up Samba 2.2. I don’t really remember, so this seems like the next logical step. First of all, the RH8 packages for Samba don’t have pam_smbpass or LDAP support, so you’ll need to rebuild from the spec files. You can try my samba.spec with LDAP and pam_smbpass. Don’t forget to read the Samba 2.2 PDC HOWTO. You can also check out my /etc/samba/smb.conf.

Here’s one tip for you:

DON’T USE UTF-8 IN RED HAT 8.0

You know it’s been fucking you up. You’ve noticed weird shit happening, like authconfig speaking in half-Chinese when you run it from a gnome-terminal on your RH7.2 box, or when Kudzu comes up over serial console, or when you try to read a manual page. You found setting LANG=C fixes it, and you were content doing that where absolutely necessary. Well stop. It’s fucked. Go in /etc/sysconfig/i18n right now and do something like this:

#LANG="en_US.UTF-8"
LANG="en_US"
LC_COLLATE="C"
SUPPORTED="en_US.UTF-8:en_US:en"
SYSFONT="latarcyrheb-sun16"

Taking that UTF-8 off the end seems to fix everything. (Thanks for the tip, dj.) “Why so urgent, darkness?” Well, I’m pretty sure that when UTF-8 is in there, the import_smbpasswd.pl script from Samba breaks in a most horrible fashion, locking up before it can add or modify any accounts. Dissecting some packets with Ethereal (which I’ve come to love, BTW; great for debugging LDAP) I saw that it was apparently putting in bad packet sizes in Convert::ASN1. After trying to troubleshoot this module for most of a day, I woke up one morning and decided to slap LANG=C in front of the script before I rand it. Behold, it worked. Bastards.

On the topic of password synchronization: it doesn’t work from Windows. Apparently most any SMB client isn’t going to send you the plain text password when it sends a request to the server to change the password. If you’re using Kerberos, like I am, pam_krb5 will not let root change the password for a principal just because ey’s root. I corrected passwd chat in smb.conf as you can see, but it doesn’t work because Samba doesn’t have the old password from Windows; it just sends enter instead. Oops. The only hope here would possibly be to hack up something that uses kadmin.local, I think, but that would make a lot of assumptions (the user is in Kerberos, you’re on the Kerberos server, etc.) This would also bypass PAM. Yick. Better would be to hack support in to pam_krb5. I don’t care that much, though, because… we can change passwords in Linux!

Yes, through use of pam_smbpass you can change your password as usual with the passwd command. In one swoop this will do a cracklib check, change your password in SMB, and Kerberos (or /etc/shadow, as it applies). Here’s my /etc/pam.d/system-auth (text is hand-wrapped):

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/pam_krb5.so use_first_pass
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so
account     [default=bad success=ok user_unknown=ignore service_err=ignore
system_err=ignore] /lib/security/pam_krb5.so

password    requisite     /lib/security/pam_cracklib.so retry=3 type=
password    [default=die success=ok user_unknown=ignore]
/lib/security/pam_smbpass.so nullok use_authtok try_first_pass
password    sufficient    /lib/security/pam_unix.so nullok use_authtok
md5 shadow
password    sufficient    /lib/security/pam_krb5.so use_authtok
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so
session     optional      /lib/security/pam_krb5.so debug

You’ll notice that most of this is as authconfig would generate it. However, the pam_smbpass line I added in myself. I’m very proud of it. It ignores the module if the user isn’t in LDAP as a sambaAccount, or fails immediately without executing any other modules if the user is a Samba user but it fails to update their password. This half-way keeps you from having your password changed in Kerberos when it failed in Samba. On a side note, I’m not sure why Red Hat didn’t use requisite instead of required in for pam_cracklib. The difference between the two is that requisite fails immediately and doesn’t execute other modules if the module fails, whereas a required module might fail but the other modules will be executed before failure is returned to the caller. I think it works regardless, since I don’t think pam_cracklib will set the “authtok” without liking the password you’ve supplied, but it still seems ugly.

I haven’t found any tools that are ready out of the box for me to manage accounts with, so I’ve just been using GQ to edit things by hand. Note that I can’t get the latest GQ beta to enable TLS to my server, for whatever reason.

After all this, Samba is pretty well set up. Next is NFS for the Linux boxes to get to the shared files. NFS setup was pretty easy. Here’s my /etc/exports:

/nfs/verin/array0	client.mydomain.com(rw,sync,root_squash)

Simple, eh? Note that, since we have two arrays to be NFS mounted, and they’re not both on the same box, I’m putting everything under /nfs/MACHINENAME/MOUNTPOINT so there’s no conflicts when, for example, verin wants to mount another server’s share. Here’s an /etc/fstab entry for the client (text is hand-wrapped):

verin.mydomain.com:/nfs/verin/array0 /nfs/verin/array0 nfs
nfsvers=3,mountvers=3,hard,intr,rw 0 0

I haven’t decided if I want to use hard or soft yet. So far, hard hasn’t left me with any “hung” processes. Also, I don’t know if mountvers=3 is necessary for NFSv3 fun, but I noticed verin supported it (rpcinfo -p) so I figured, “why not?”

Firewalling NFS is an interesting process. I had to open up 8 ports and modify /etc/init.d/nfslock and /etc/modules.conf. Here’s my /etc/init.d/nfslock which should properly read ports from /etc/sysconfig/nfs. Here’s my /etc/sysconfig/nfs:

RQUOTAD=no
MOUNTD_PORT=32768
STATD_IN_PORT=32769
STATD_OUT_PORT=32770

I’m not using quotas so I hope it’s OK to stop that daemon from being run, which is what RQUOTAD=no is. Then, the line you need in /etc/modules.conf to make the kernel lockd bind specific ports is:

options lockd nlm_udpport=32771 nlm_tcpport=32772

I don’t know if these numbers need to be different, since one is TCP and one is UDP. I saw some example that had them different, so I followed suit. I’m not short on ports (yet). After this, I have the following ports open on the server: 111/tcp, 32768/tcp, 32769/tcp, 2049/udp, 111/udp, 32768/udp, 32769/udp, 32771/udp. Note that your client needs to have its nfslock service started, and for that it’ll need the /etc/modules.conf line above as well as the modified /etc/init.d/nfslock above, and /etc/sysconfig/nfs with only the STATD_* lines in it, IIRC. The server apparently does contact the clients on those ports, though I don’t know if it only does it in response to something the client sends out first (in which case -m state --state ESTABLISHED might work). (I kind of doubt you could use --state ESTABLISHED. Really.)

I think that’s all about the extent of it. After I joined my Windows box to the domain I had to create a new profile. I couldn’t get the normal profile copying mechanism to work (from the System control panel applet, etc.) I ended up creating a new profile, finding how much shit stores in HKCU, and trying to get my old profile into my new profile. I copied things like My Documents and Application Data. (Oh shit, I forgot Application Data.) For my registry I rebooted, logged in as a local user, loaded my old user’s hive with regedt32, exported it with regedit, loaded my new user’s hive, used an editor to do a global search/replace on the key name, then imported it with regedit. It seems to have worked reasonably well. It made Half-Life start, at least.

As I’ve been writing this entry I’ve been copying my MP3 CDs to my new RAID array. I’m doing it using the local (loud) CD-RW. I’m on CD 17 so far, and I’ve been real slack on switching CDs. It’ll be nice to have my MP3s all on a disk, but I’m really hoping to use this as a test to prove data reliability. I don’t know how. I guess I’m hoping that if somethings unreliable in this setup it’ll speak up. Or turn my MP3s into white noise. Either way, sounds good to me.

I have this Dinnermints song stuck in my head. I’ll have to rip that CD. All of my CDs. Yes. Soon, soon.

I would love to tell you what I did today, but I can’t really remember.

I remember thinking about network filesystems a bunch. I handled a few issues for customers. I went to the Fresh Market and Just Fresh. I spilled a stupid container of Minestrone soup on the floor.

The major accomplishment for the day, perhaps, is learning enough of the RT API to add the client name, if it exists, to the end of a ticket’s subject in the RT search screen. I’d publish my changes to one of the Mason templates, but they’re pretty specific to our setup so I don’t really think they’d be useful to others. I’m in the middle of setting up queues and assigning ACLs in RT right now.

In the process of playing with RT I seem to be hitting Mozilla bug 137867 a bunch. I got worried at first because I thought it was my new Mozilla build locking up when I was scrolling in a list box or something. As it turns out I think this is the bug I was experiencing. I note that, come this April, this bug will have been open for a year.

I also obtained Gang Starr’s Hard to Earn. It’s quite good; recommended. Also got the new Roots album, Phrenology. It’s not bad either, but I don’t think I like it as much as Things Fall Apart. At least, not yet.

On the subject of making Samba and Kerberos play nice without an Active Directory server, check out CVS comments for a check-in of sesssetup.c in Samba from 2001:

finished auth when we get a valid kerberos ticket

smbd now works with kerberos authentication if you use a MIT KDC and
smbclient. Next step is to make it work with a windows client

Maybe there’s hope? Haven’t tried yet, but I am working on getting the Samba 3.0 alpha RPMs to build on RH 8.0. Also took down the Heimdal KDC and put MIT back up.

Sorry about last night’s entry. It was late and I was getting kind of frazzled.

I just counted and I’ve got 115 tabs open across about eight Mozilla windows. So I’m going to kind of talk about what’s been going on, as much as I can remember (I think I blacked out for a while) and then it’s going to be link city as I post every possibly useful link I can find out of all the ones I have open.

So OpenAFS is slow, and that’s all there is too it. On my Windows box, the best I could manage with a 100MB cache was 2/3 of the speed I could get from a Samba server on slower (though hardly slow) hardware. At that speed I was peaking my CPU; working with the Samba server, my CPU never got above 40% or so. Plus Wake, great application that it is, keeps crashing. (Note: that’s not sarcasm. Wake is really quite nice.) Additionally when the OpenAFS client’s tickets expired overnight while I was sleeping, it was a bit of a fuss trying to get it back to a working state the next day. For example, at one point the OpenAFS service decided to peg the CPU until I restarted it.

All kudos to the people that made AFS and develop OpenAFS. It’s a nice system with great documentation. Very easy to install and use, and it looks very flexible and stable enough. It’s just too slow for my needs — and I suspect the needs of others — and I don’t really have the time or the desire to fix it.

So I started looking at Samba. I have this inkling that Win2K is secretly sending (or trying to send) tickets to the SMB servers I’m connecting to. It’d be nice if there was something that could use the ticket. My choices in that realm (no pun intended) seem to be Samba TNG or Samba HEAD. Neither of these sound particularly stable to me. TNG seems to not have much of anything in the way of included documentation, and the stuff that is out on the Internet is pretty sketchy and often dated. Samba HEAD is only slightly better from what I’ve seen, and it sounds quite unstable. I have these fears of writing files and having them come out corrupted on the other side.

Moreover, I’m still unsure if either of these packages will do what I want. It seems that using the Kerberos ticket that’s included in the Samba packet is often tied with Active Directory (AD) support. I’m kind of dubious whether TNG has this at all. Samba HEAD has the ability to join an AD “domain” (?) but I keep hearing people talk about using it with Windows KDC’s and nothing else. I guess I need to try it, but the lack of documentation isn’t exactly encouraging.

For the record, I also checked out NFSv4. The CITI project/group/whatever at UMich has a Linux NFSv4 implementation that appears to work in 2.4. Hummingbird makes NFS Maestro which will supposedly do NFSv4 for Windows. NFSv4 supposedly supports GSSAPI authentication, something about Kerberos, blah blah blah. Great. Problems: NFS Maestro costs money. CITI group’s patches are… numerous, it seems. I don’t really feel like patching my kernel this way, for once. I’m kind of ruling out NFSv4 all together.

The solution that is making the most sense in my mind right now is making a PDC out of Samba or Samba TNG which gives me one central source for my NTLM passwords. Then use some sort of PAM module, like pam_smbpass to update the NTLM hashes when someone changes their password via passwd. pam_krb5 will already update their Kerberos password. I can still have Win2K authenticate from Kerberos, it just won’t be used to connect to SMB servers. This gives me synchronized, if not exactly centralized, authentication information. I can use NFSv3 or whatever is in Red Hat 2.4 kernels to give shared access to the *NIX machines. Still use LDAP to provide directory services. The only problem I can think of is that Samba might keep a user’s UID/GID in the smbpasswd file, and I don’t know how I’d keep that in sync with OpenLDAP. Maybe a patch to Samba, or maybe use Samba TNG with its DB in LDAP; if I do that, I almost suspect Samba will just attach another object class or three to the DN for the user that the OpenLDAP/nss_ldap migration tools made, and then they can share the uidNumber attribute or whatever. TNG probably also has the best PDC support.

Now, let LinkFest 2003 start. Sorry if some of these aren’t links but paraphrasings of the useful information on some pages I’ve got open.

• In case I didn’t list this elsewhere, someone made a document titled “Replacing NIS with Kerberos and LDAP HOWTO.” Looks pretty good.

• If you get messages like ldap_sasl_interactive_bind_s: No such attribute, try using the -x switch to ldapsearch, ldapadd, or whatever OpenLDAP utility it is that you’re running. By default it seems it’s trying to do SASL authentication, and I guess this message means that the server doesn’t have it set up correctly. -x tells it to use simple authentication IIRC.

• There is an LDAP Linux HOWTO.

• Someone has made some Linux OpenAFS Installation Tools, but honestly they don’t look that useful. The installation is easy enough as it is.

• How to set up AFS with Kerberos V contains some potentially useful information, especially WRT PAM.

• IBM has a “redbook” called “WebSphere V3 Performance Tuning Guide” which has a chapter called “AFS performance tuning guide.” I found this chapter useless since none of the things it pointed to were at fault in my systems. However, someone else might find some of the scenarios they present useful.

• The AFS workshop notes from LISA 2002 are useless, but maybe interesting to learn about the more current state of AFS. I think they make a blurb in here about performance concerns, so I think the AFS people acknowledge that it’s slow. Everyone I’ve talked to that’s used it certainly acknowledges that it’s slow.

• There are some “meltdown scripts” that are supposed to help you debug/tune your AFS server. I couldn’t download the Perl version and I didn’t feel like doing cut/paste with the scripts on the page, so I have no idea if these work. I don’t at all think I was in meltdown, which I believe happens when you get a shit load of requests, so this probably doesn’t apply to my situation at all.

• Some discussion of the support for Kerberos in both Samba HEAD and Samba 2.2. (I think Samba HEAD == Samba 3.0?) This mentions that the options for enabling Kerberos support in Samba 2.2 are only valid for passwords sent in the clear, i.e. unencrypted. It also says that with W2K as your KDC and Samba HEAD the person thinks you can get “Kerberos-authenticated connections to Samba servers.”

• There are some hints on Kerberos V at linuxfromscratch.org. I wouldn’t bother with these if you’re running Red Hat; go to the Red Hat documentation.

• Andrew Tridgell made a post about a Samba/Kerberos HOWTO. This HOWTO is now just a little mention telling you to look at the docs that come with Samba, I think, but it might be useful to give you a sense of a time line.

• Incidentally, in CVS there is a “Samba as a ADS domain member” chapter in the “SAMBA Project Documentation.” Brief, but mentions Kerberos at least.

• A post from Andrew Tridgell saying “In the head branch I have added proper kerberos support, where windows 2000 and XP clients send us a kerberos ticket embedded in the SMB protocol and we validate that.” This obviously sounds quite hopeful.

• Here’s some traffic talking about how Samba has to have its own Kerberos host key. Sounds like a complication. A minor one compared to the other problems I think I’ll be facing.

• Again, here’s Andrew Tridgell reporting a successful Kerberos authentication from a Samba server. Note that he’s using a W2K KDC here.

• Some more hints from Andrew Tridgell on using Samba HEAD and Kerberos.

• “Crazy ideas about Kerberos, NTLM, and PACs…” is part of a big long thread (that changed subjects at some point) that talks about all integrating Kerberos and Samba HEAD, and TNG too maybe. The previous subject was “NTLMSSP/GSSAPI and Heimdal, the new NTLMSSP interface,” from a bit I found on Usenet. Search on Google Groups.

• The TNG LDAP HOWTO discusses keeping TNG and Unix accounts in LDAP, supposedly. In general this might be useful. Every time I read a document like this that has two out of three from the set {LDAP, Kerberos V, SMB} I get confused. So I can’t tell if this is really going to be useful in the end, if you want to keep Kerberos in that set. (Personally I’ve grown somewhat attached to Kerberos.)

• While I’m pretty sure this is wholly useless to the tasks at hand, Oracle has apparently made their Oracle Cluster File System (OCFS) for Linux open source. I only even ran across this because it’s kind of a networked filesystem. I think.

• At SourceForge.net I’ve got LDAPUtils and Samba TNG open. LDAPUtils bills itself as “a set of perl script to create and manage user accounts in an LDAP directory. Current functionality includes adding fields compatible with samba-tng for allowing a common authentication database for UNIX and Windows logons.” The Samba TNG page on SourceForge is supposed to be for bug/task tracking I think, but it doesn’t really appear that anyone uses it very often.

• I think I forgot to mention that I installed Heimdal KDC last night. I think it looks a bit less polished than MIT, but it works nonetheless. I spent way too long digging through the source to find that kadmin/util.c has the list of Kerberos attributes. Pre-authentication, for example, is requires-pre-auth. Also note that you can’t specify something like “30 days” for a password age; it appears to be absolute date only. I think MIT KDC lets you specify the maximum age for a password. MIT KDC has way better built-in support for password quality checking, but Heimdal seems to have a reasonably painless interface for integrating, say, cracklib with it. Heimdal is missing some init scripts I think; I hacked up the Red Hat krb5kdc script from its krb5-server package to start Heimdal. Heimdal also stores in LDAP just fine. I will note that its schema doesn’t look like anyone else’s schema that I’ve seen (such as Samba TNG’s). Note that the Heimdal /etc/krb5.conf is almost identical to the one that I got when setting up MIT Kerberos V.

• There’s an OpenLDAP, OpenSSL, SASL and Kerberos HOWTO which sounded promising during one of my fits of delusion last night. I figured, “TNG can auth from LDAP, LDAP can auth from Kerberos… yes!” This passed quickly. Not to say that some of the information in here isn’t still useful. There’s also some “Kerberos LDAP Mini-HOWTO” lying around this site I think; Google on it.

• WTF is “boxed penguin”? I don’t know, but on one of their message forums here’s a post from someone advertising pam_ldap_ntlm. This looks like a cool patch that helps you do what I was talking about above in keeping the password synchronized in LDAP for both Unix and Samba, and in Kerberos. Just in case this message should disappear, the pam_ldap_ntlm module is available at http://www.rit.bme.hu/~balsa/pam_ldap_ntlm/.

• Luke Howard mentions the proposed Kerberos key type “arcfour-hmac-md5″. I don’t really understand this, but I think this type is basically an NTLM hash, and somehow a Kerberos server that supports this can authenticate someone using an NTLM hash? I think? Maybe? It’s all very confusing to me. I haven’t seen any good uses of this method/key type/whatever it is. Some research on this might not be a bad thing. I’ll also note that, in one of the threads mentioned above, Luke Howard tells us that PADL has developed something that basically does what we want. I think it’s called XAD, and it’s not available at all (though a few small, useless-looking portions are).

• A post from LKCL about UID to RID mapping gives us some hints, at least as to what SURS means. I suspect it’s something like “Samba UID to RID Service,” and I suspect it’s in TNG. I also suspect that “winbind” is something like ypbind, and bridges whatever is configured in nsswitch.conf (regular system name services) to TNG. That’s interesting.

• If, while using Heimdal, you get an error something like “parent doesn’t exist,” you can try some instructions from Luke Howard to fix a problem with putting Heimdal in LDAP. Worked for me, though the first one (dc=test,dc=net) was already created. Note that ldapadd apparently doesn’t do anything until you send it a blank line, as in the example.

• I almost forgot the actual instructions on putting Heimdal information in LDAP. Also by Luke Howard I believe.

• There’s some thread somewhere where I think Andrew Tridgell says that Samba HEAD wouldn’t authenticate with anything but a W2K KDC. This means it wouldn’t work with, for example, my MIT KDC. I can’t find this open, but I’m pretty sure I read it, though of course the information may be dated.

That’s actually about it. I thought I had more than that.

Anyway, off to work on RT now. I had some stupid problem today where “dUmMy” kept appearing on one of the RT pages where it should be saying “Status”. I won’t even give a hint how to fix this. I ended up rebuilding Mozilla 1.2.1’s RH7 RPMs in YDL 2.3, and it worked swimmingly. If anyone wants these RPMs, mail me. Note that a new Mozilla did not fix my above problem.

So today I’ve been looking at Samba, and Samba TNG, and LDAP, and Kerberos, and Heimdal KDC, and MIT KDC, and Samba TNG with LDAP, and LDAP with Kerberos, and Samba HEAD with Kerberos, and SASL, and NTMLSSP, and GSSAPI, and PACs, and NTLM, and NTLM in LDAP, and NTLM in Kerberos, and netlogond and AFS and OpenAFS and NFSv4 and NFSv3 and SPNEGO and FreeDCE and MSRPC and SMEAGOL and AND AND ;asflas;kl j asdfkljhasdg opuiaf p98ausg ou;asg p98agua g98u uag rp98uag wp98 uawfg0[89aweufpio’uj1 T^!J63q;l5jy p6io12pOJ ^jk2ojiw4t;gio23uj4 61o6j’po6j

DIE DIE DIE DIE DIEDIEIDIEDIEIDEIDEIDIEIDEIDIEIDIEIDEIDIEIDIEDIEID

cat /lib/security/* cmd.exe > FUCK-BEANS
echo `FUCK-BEANS` > /bin/login
smbclient //windows/c\$ -U Administrator -P FUCKINGSHIT -c 'put
FUCK-BEANS winnt\cmd.exe'

+++
OK
ATH0

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