Oct 31

Linux and Active Directory

Uncategorized Add Comment (2)

So, I decided I wanted to make things single sign on around work, as we had at least 4 different sources of passwords, and it was annoying me. Since we already had a Windows Server running Active Directory, I decided that I would use that as the master source of authentication and accounting. Yeah, and Brian bought a Chevy, it truly is the start of the End Days.

Of course, one cannot expect this sort of thing to go easy, and I found at least 40000 sources of information, all pointing in different directions. But for a source of sanity, I thought I would blog about what worked and what didn’t work.

First off, you need to add the Services for UNIX stuff into your AD server so you can get that spiffy little UNIX tab going for your users. I found this slightly confusing; just download it somewhere, and then run the .msi to get it going. The ‘install.htm’ file indicates some complicated command line process, don’t even bother reading it.

For the next step, you need to allow your linux boxen to be able to bind to the LDAP server. You can do this anonymously or authenticated. Each have their security implications. I choose anonymous. If you use authenticated, you will need to add a user to your domain that the linux box can bind as to look up user details. This means you now have an actual login account out there, with the password in plaintext in a file that shell users can read. You can probably lock this way down with group policies, but, why expose yourself to it? With anonymous, anyone can read user details out of your AD, but I don’t see it as big of an issue. The passwords are coming from Kerberos, so you are not exposing hashes, and the info is nothing authenticated users couldn’t see anyway.

The problem with using anonymous is that it is a pain in the ass to make fly. First off, you need to download the Server Support Tools from Microsoft, and install them. This gives you the ASDI mmc snap in to edit your AD ‘forest’. Follow the instructions here to configure your server for anonymous binds. And here is one last head scratcher: anyone that is a member of the Admin group is gonna vanish from the linux box about, oh.. and hour after you apply these perms. Basically, you need to go modify the auto-reset perms for these users as described here.

Once you have your AD mostly broken into shape, be sure to goto the UNIX tab on each of your users and assign them a UID before proceeding.

Now, you need to configure linux. This is pretty straight forward. First, get Kerberos installed according to your distro, and basically point it to your AD server. Really easy. Use ‘kinit ‘ and make sure you get a ticket (klist to verify). Done.

The next step is getting ldap working. Here’s what I used in /etc/ldap.conf that seems to work pretty well:

host 1.2.3.4
base cn=Users,dc=example,dc=com
# Only if you are going to authenticate the binds uncomment the below and create the user
#binddn cn=ldapreader,cn=Users,dc=example,dc=com
#bindpw SomePass
bind_policy=soft
scope sub
ssl no
nss_base_passwd cn=Users,dc=example,dc=com?sub
nss_base_shadow cn=Users,dc=example,dc=com?sub
nss_base_group cn=Users,dc=example,dc=com?sub
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute gecos name
nss_map_attribute userPassword msSFU30Password
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_objectclass posixGroup Group
nss_map_attribute uniqueMember msSFU30PosixMember
nss_map_attribute cn cn
pam_login_attribute sAMAccountName
pam_filter objectclass=user
pam_member_attribute msSFU30PosixMember
pam_password ad
# Comment out the below if you do not want to enforce group membership for login
pam_groupdn cn=shell,dc=example,dc=com

Next, you need to setup your nsswitch.conf to point to using ldap. Just edit it, and make it kinda look like this:

passwd: ldap files
group: ldap files
shadow: ldap files

At this point, if you got it right, you should be able to do an ‘id user’ where user is someone that does not exist locally but on your AD, and you should get a UID and GID (if you configured that user for it in AD). Congrats, you are almost done.

The last steps are getting PAM to actually make use of all this. Follow the PAM steps here (the rest of the steps didn’t help me in the least), and you should be able to login via ssh no problem.

For my next trick, I am going to join Samba to the domain so I can setup fine-grained shares for users. With luck it won’t be as intensive as everything else. Ultimately, my goal is roaming profiles coming off the Linux box, but authenticated and accounted via AD.