Currently I support thousands of users on hundreds of machines in a mixed Unix and Windows environment. The legacy environment has 2 separate systems to administer user accounts. On Unix, we still (!?!) use plain old NIS. For Windows, we use Windows Server 2003 R2 with Active Directory (AD). AD can theoretically support Unix authentication, and promises to offer a “one stop shop” for integrated account management. Does it really work? Read more to find out…
We basically have 2 flavors of Unix in wide use. We use a couple of different Linux distributions – Fedora Core 5, 6 and 7 for lab workstations and CentOS 4 and 5 for department servers. We also have a lot of Sun machines, both SPARC and Opteron, running Solaris 10. So our challenge was to enable AD integration for “Red Hat flavored” Linux, and for Solaris 10.
Linux
After some googling, I found Scott Lowe’s blog on Active Directory Integration. Scott has basically done all of the heavy lifting, and has howtos that work. We sat up a test load of Fedora 7 on a VMware virtual machine, and followed his Linux howto. Basically you prepare the AD controllers to supply Unix attributes to Unix clients (in general this is a one time thing, once it’s done, it’s done). Then you set up the ability on the Unix machine to do LDAP queries against AD, so that clients can look up user attributes. Then you enable Kerberos, so that client mmachines and domain users can get and use valid AD Kerberos tickets. It is pretty straightforward, it worked, and we had no substantial issues with it. It is pretty disconcerting to see a Windows user log into a Linux machine with their Windows user name and password, but it seems to work fine.
Solaris
Next I tried this Solaris howto on a Solaris virtual machine. The Solaris howto is very similar to the Linux howto. The AD setup was already completed (since we already had performed it to get the Linux integration to work). So then I configured Solaris for LDAP and Kerberos. Surprisingly, I could get the Kerberos to work (Kerberos is well known to be complicated and cranky), but the LDAP configuration wouldn’t work to save my life. It just silently did nothing. No error messages. Nothing of consequence in the logs on either the AD machines or the Solaris clients. It. Just. Didn’t. Work. Grrr. I could do LDAP queries from the command line, but I’ll be damned if I could get Solaris to use LDAP to look up user attributes. I spent something like 30 hours on it and finally gave up.
Solaris using Windows “Server for NIS”
The fallback idea was to use Windows “Server for NIS” that comes bundled with 2003 R2. I enabled and configured this. It really does do NIS, and Solaris clients can use it for authentication. I had 2 issues with it. The first was that the initial load of NIS with AD passwords only occurs when the AD password is changed. There’s no way to force a copy of the existing passwords. So that means if you activate Windows Server for NIS, you have to tell everyone to change their AD passwords to get them into NIS. That sucks. The other issue I had was that although Solaris could use Server for NIS for secure shelll sessions, I couldn’t get it working for GUI desktop sessions (CDE or Solaris Java Desktop). I’m guessing it was a PAM thing, but I couldn’t figure it out.
Hmm. Server for NIS doesn’t work for GUI sessions. That wouldn’t work for my Sun Ray users. And I didn’t feel like telling hundred, maybe thousands of people to change their passwords. I was stuck…
Solaris Redux
Well, Scott Lowe to the rescue again. He wrote up an updated howto for Solaris, that uses samba to help do some of the heavy lifting. It worked! I could use LDAP to query AD, and I could use samba to join my Solaris machines to the domain. I tell you it’s a bit weird to see Solaris and Linux machines appear in the Windows GUI “Active Directory Users and Computers”, but they do! The only hiccup I had with this updated howto was minor. Solaris 10 keeps it’s Kerberos keytab in a different place than samba does. So although samba will join your machine to the domain (by getting a keytab and storing it in /etc/krb5.keytab), Solaris expects proper keytabs to be in /etc/krb5/krb5.keytab. Good old Solaris, gotta be different to confuse the ignorant. The symptoms are this – LDAP queries work (getent passwd <AD username> works, and kinit works (users can get tickets from the domain), but ssh sessions fail with “file not found”. At first I thought the “file not found” error was a home directory thing, but I believe that it was really sshd whining that it couldn’t find a keytab where it expected to.
Just copying the keytab to the place solaris expected it to be didn’t seem to work either. So I used the ktutil command to read the keytab and write it to the new location like so:
# ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: wkt /etc/krb5/krb5.keytab
After that, logins worked fine.
Next stop, unified home directories for all users, regardless of OS, via NFS and SMB.
