CentOS 6 Authentication to Active Directory – Part 2

A while back, I described a method for authenticating CentOS and RHEL servers to Active Directory using LDAP.  While this approach is easy to set up and works right out of the gate, there are a few drawbacks to it that I’ve run across:

• Changing passwords from the Linux server does not work unless you set up LDAP over TLS/SSL, which I’ve found very difficult (though not impossible!) to accomplish
• While changing the passwords does work, it can be very user unfriendly.  In particular error messages given are very cryptic to the lay user.  Unless you are in IT, you’re not going to know or care about the LDAP error codes that are reported back, nor are you going to want to research what the appropriate character classes are for the AD passwords so that you can choose from at least three of them appropriately.

In this article, I’ll describe how to use winbind to join your Linux server to a Microsoft Active Directory and become a domain member.

First, you need to set up your users in AD with the required POSIX attributes.  At a minimum, you need to set only two attributes, uidNumber and gidNumber.  For the uidNumber, I recommend using the RID of the user you are setting these attributes for.  You can also set unixHomeDirectory, gecos and loginShell if you want to maintain this information in AD.  These are optional in the set up I am proposing, so it could be considered more of a best practice than a requirement.  So my user object looks something like this (many many attributes omitted for brevity):

Then you need a group to go with it.  Note that I’ve set this user’s gidNumber to 513.  In order for winbind to operate, the gidNumber in AD needs to be set to a group that exists in AD – that is, a user’s primary group can’t be a local group.  The user simply will be ignored by winbind and therefore Unix.  Keeping that in mind, this is the object dump of my AD group:

Note how the uidNumber for the user object and the gidNumber for the group are based off of the RID of the object (the last number of the object’s SID).  This isn’t required.  You can set the gidNumber and uidNumber to any arbitrary (but unique) value you choose.  I did it simply because the SID is going to be unique in a directory.

Now that we have our user and group objects set up, using winbind relatively simple to do.  The first thing I do is to make sure you have the appropriate packages installed.  A simple yum command will set that up.

Next, I run authconfig-tui and select ‘Cache Information’ and ‘Use Winbind’ under ‘User Information’ and ‘Use MD5 Passwords,’ ‘Use Shadow Passwords,’ ‘Use Winbind Authentication,’ and ‘Local authorization is sufficient’ under ‘Authentication.’   This will configure PAM and NSS for you so you don’t have to worry about editing those files by hand.  Unfortunately, (at least the way I want to do things), authconfig-tui does not handle setting up smb.conf quite the way I want it to AND it tries to start winbind without joining it to the domain first.  We’ll clean up that cache files that the aborted attempt at starting winbind makes and there are only a couple files to edit by hand and they are consistent across all servers in the domain.

So first:

Then make sure your /etc/hosts looks similar to the following:

Pretty simple, right?  It was just one of the things I found that made my life easier since anaconda (or maybe Network Manager?) has a tendency to put the hostname in with the localhost line, which I’ve found confuses certain applications.

Next, /etc/krb5.conf needs to be tweaked a bit:

And finally, the all-important /etc/samba/smb.conf.  I’ll show you what I do with it and then explain it afterwards.

There are a lot more options you can put in your smb.conf if you want your server to serve up cifs or smb shares or printers, etc.  I’m just focusing on authentication, and this is a configuration file that works to perform this function.  Things to note here are that I am setting the id range for uid’s and gid’s to be from 500 – 33554431.  This may not work for you if you already have local users that have id’s in this range.  CentOS and RHEL work on trying to keep all service accounts (apache, mail, sshd, nscd, etc) uid numbers under 500 so this seemed like a good place to start for me since all of my users will be in AD (no local or LDAP accounts).  If you’ll recall, I mentioned above that the loginShell and unixHomeDirectory attributes are not required.  That is true, but only if you have the template shell and template homedir set (as above).  If either of these attributes are missing, the values from smb.conf will be used.

Now that we’ve got samba configured, we’re ready to join the domain.  Using an account with privileges to join servers to the domain, run

The createcomputer argument is not required.  It is used if you want your computer object to be place into the directory in a different OU from /Computers.  If that doesn’t matter, just leave off the argument altogether.  Another thing to note is that you’ll most like receive what looks like an error – usually it’s that the account doesn’t exist in Kerberos or a DNS update failed.  This is fine; just look for the text “<computername> joined to domain.”

Finally start up the winbind service:

Now, you should be able to authenticate with your AD users and get user information.  A word of warning – although authentication and commands like finger and id work against the AD users, one of the shortcomings of winbind is that getent passwd and getent group will not return any entries for AD accounts or groups.  Just something to keep in mind.

One of the side benefits of having your computer joined to the domain is that you can now easily run queries or create and delete users and groups.  For example, if you wanted to find information about Tester X, you could run

[root@winbind-teste ~]# net ads search -P ‘(cn=Tester X)’

This would return an ldif-like stanza of the Tester X object.  The -P tells net ads search to use the computer’s machine account to authenticate while performing the search.

Conclusion

In the end, I’ve presented two methods of integrating your Linux system authentication into an existing AD infrastructure – one using straight LDAP into AD and the other using winbind to join the machine to the domain and use native calls.  There advantages to each method.

Advantages to LDAP:

• Easy to configure
• Is a more “standard” configuration for Unix and Linux
• Returns user information properly with commands like getent passwd

Advantages to Winbind:

• Uses native calls into AD
• Presents a slightly more user-friendly interface into functions (eg, passwd displaying more readable errors)
• Allows for changing passwords without having to worry about setting up certificates
• Certain AD functions can be achieved using the ‘net’ command

During the course of my testing and speaking with other Unix engineers, I’ve gotten the impression that authenticating to AD is looked down upon.  I don’t see it that way.  If you’ve got an established directory service set up, there’s no reason why it shouldn’t be leveraged.  In fact, AD authentication just goes to show the strength of *nix systems; after all, how many Windows systems do you know of that can authenticate exclusively against LDAP or NIS?