Linux integration with Active Directory: part 1

At work I've been running Samba 4 for quite a while. Because Samba 4 is still in Alpha I didn't just move everything over to use Samba 4 for authentication, but instead I started out by moving services over one by one. I actually started with e-mail routing (will detail in a later post) and authentication. Later on I added proxy authentication and fileserver authentication / authorization, Windows XP and Windows 7 clients and last but not least actual Linux (PAM) user authentication.

In this post I will detail how to join a (Debian / Ubuntu) Linux machine to the domain, setup Kerberos, setup nss to make Linux aware of domain users and setting up PAM to allow domain user authentication. I'm using Samba 4 as Active Directory implementation, however this should all just work against a Windows server hosted Active Directory as well. I'm going to make use of a feature that requires Windows Server 2003R2 or newer, or IDMU (Identity Management for Unix), but that's only used to store the users' shell in Active Directory.

First off, I'm assuming that DNS is properly set up. It's not needed, since both Kerberos and Samba can be made to work without DNS, but best case that means a lot of hosts file mess on almost all involved computers. Honestly it's easier to even do a manual DNS setup than to keep such a hosts file mess up to date. I will detail some parts for the non-DNS case as well, since it's useful information.

Setting up Kerberos

Now on to the real work. Setting up Kerberos is really easy:

# apt-get install krb5-config

This should probably ask just one question: the default Kerberos realm. This normally is the uppercase Active Directory domain name. If you don't have DNS setup it will also ask two more questions:

• The kerberos servers
• The kerberos admin servers

These are the Active Directory Domain Controllers (although Samba 4 doesn't provide the kadmin interface right now). You probably need to add these to your hosts file as well.

If you actually want to check if it's working, you should probably install krb5-user as well and try to do a kinit to acquire a Kerberos ticket, but if you've done a few servers you'll probably believe me when I tell you you don't need krb5-user for Kerberos support.

Joining the domain

Now it's time to join the Linux machine to the domain (since Kerberos is working). We start by installing winbind:

# apt-get install winbind
# /etc/init.d/winbind stop

We don't need an active winbind instance around, so let's stop it right away. If smbd or nmbd are running stop those as well.

Now continue by editing /etc/samba/smb.conf to contain all of the required configuration for Active Directory support:

[global]
netbios name = yourhostname
server string = your host description

realm = YOUR.REALM
workgroup = YOURWORKGROUP
security = ADS
local master = no
preferred master = no
dns proxy = no

# set password server if you don't have functional DNS
#password server = dc.domain.tld

encrypt passwords = true
# setting kerberos method = system keytab prevents pam_winbind from
# authenticating users for me, but the following does work
kerberos method = secrets and keytab

# Using winbind default domain = yes makes usernames work without domain part
winbind use default domain = yes
winbind enum groups = yes
winbind enum users = yes
# winbind nss info = rfc2307 makes winbind use posix attributes from AD
winbind nss info = rfc2307

# map untrusted to domain = yes allows any user to be mapped to the domain user
# with the same username, but also prevents local samba accounts from being used
map untrusted to domain = no

# template homedir can be used to designate the location of users' home
# directories
template homedir = /home/%U
# template shell defines the default shell for when none is set in the posix
# loginShell attribute for a user. Setting this to /bin/false allows login only
# for those users that have this attribute set. pam_winbind also has an option
# to limit access to several groups only, which is actually a real security
# measure unlike this attribute which might be changed by users
template shell = /bin/false

# The first two idmap lines are for the domain, the other two for local samba
# accounts. Using the rid backend maps the ids to the end of the user's SID,
# which makes consistent id mapping across servers possible.
idmap config yourworkgroup : backend = rid
idmap config yourworkgroup : range = 10000 - 49999
idmap uid = 50000 - 100000
idmap gid = 50000 - 100000

Replace all the fields in bold with values applicable to your domain.

Now it's time to join the domain:

# net join -UAdministrator
Enter Administrator's password:
Using short domain name -- YOURDOM
Joined 'YOURHOST' to realm 'your.domain'
[2012/02/10 21:15:35,  0] libads/kerberos.c:333(ads_kinit_password)
  kerberos_kinit_password YOURHOST$@YOUR.REALM failed: Client not found in Kerberos database
DNS update failed!
# /etc/init.d/winbind start
 * Starting the Winbind daemon winbind                                   [ OK ]
# 

If DNS is not properly set up, use net join -UAdministrator -Sdc.yourdom, this tells net what server it should use for the join.

As far as I know these errors are nothing to be concerned about, but the DNS update failed means that net/Samba wasn't able to register the host in DNS. If you have DDNS updates from a DHCP server or there's already a static entry for the server in DNS then you don't need to worry at all. Now try wbinfo -u and see if the Active Directory users show up.

Setting up nss

Setting up nss is another easy step, we just need to add two references to winbind, for both passwd and group. Edit /etc/nsswitch.conf and change the passwd and group lines:

...
passwd:         compat winbind
group:          compat winbind
...

Verify with getent passwd that all the domain users are listed and their home directories make sense. Now would be a good time to change the loginShell attribute for your user, because as you can see it now is /bin/false for all users.

Setting up PAM

Now that the users actually 'exist' on the machine, let's enable authentication for them as well (if your package manager hasn't already done that for you):

# pam-auth-update
...
Some PAM module packages provide profiles that can be used to
automatically adjust the behavior of all PAM-using applications on the
system.  Please indicate which of these behaviors you wish to enable.

PAM profiles to enable:

   [*] Unix authentication
   [*] Winbind NT/Active Directory authentication
...

Now let's logon to the server from another computer:

$ ssh user@yourhost
user@yourhost's password: 
...
Could not chdir to home directory /home/user: No such file or directory
user@yourhost:/$

That's not good is it? Well, it is, but let's make it better, but first...

It doesn't work!

Oh well, bad things can happen. It should work, it works for me on multiple machines, both freshly installed and some older installations, both latest and long-term Ubuntu releases and different Debian releases. But it doesn't work for you... There's a few places you can check right now, one is /var/log/auth.log. However, this might not be the most useful log file in case of authentication failures against Active Directory. A good help though is to start winbind in debug mode:

# winbindd -d 3 -i

This will list a lot of debug information. Look at the messages that occur during a login attempt, it helped me to discover that I needed to use kerberos method = secrets and keytab in smb.conf. It wasn't saying so directly, and don't expect it to tell you the solution to all your problems, but the error messages can be informative...

Finishing touches

Now to continue where we left off, apparently we don't have a home directory on the server yet. This makes sense, and there's a proper solution. We just need to tell pam to use a module that will make a home directory for a user logging in. Let's do so by adding one line to the end of /etc/pam.d/common-account:

session required pam_mkhomedir.so umask=0077 skel=/etc/skel

You can change the umask, but 0077 means that the directory is owned by the user and that group and other have no permissions at all. Now if we login we end up in our newly created home directory.

Next up is sudo. There's a possibility you want to grant sudo rights to someone in your domain, for instance to the Domain Admins group. Of course this is not any different from granting permissions to a local group, I'm detailing it here for a more complete solution. Edit /etc/sudoers in your favorite editor and add the following line:

%domain\ admins ALL=(ALL) ALL

The backslash is just used to escape the space in the group name, otherwise this is no different than any other sudoers entry.

We've come a long way from where we started, but there's still room for improvement. We enabled login using Active Directory credentials, but what if we already logged in somewhere else? In Windows SSO (Single SignOn) works out of the box, but let's add it to our Linux machine(s) as well. What we need for SSO is Kerberos, and since we just set that up we can use it for other services as well. For now I'll only discuss on setting this up for OpenSSH. In /etc/ssh/sshd_config there are two commented lines that we need to change and uncomment so they look like this:

...
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
...

Don't be fooled by the Kerberos lines, they're not needed for Single SignOn. Now restart SSH:

# /etc/init.d/ssh restart
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service ssh restart

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the restart(8) utility, e.g. restart ssh
ssh start/running, process 32441

Now back to the other computer to do a ssh login and see if you can log in without having to supply a password. If it doesn't work, try the following command:

$ ssh -vvv -o PreferredAuthentications=gssapi-with-mic user@yourhost

This will show a lot of debug messages, probably with a descriptive error message near the end. One thing to keep in mind is that the client needs to know the Kerberos principal for the host it's connecting to. This is because with Kerberos, the client is also verifying that the server is actually (according to Kerberos) who it's trying to connect to. The way ssh determines the principal is by using the HostKeyAlias, which defaults to the host you're connecting to. However, it's easy to cheat if there's no working dns by supplying -o HostKeyAlias=yourhost on the ssh commandline.

We can make this even better than it is right now. You might have noticed that if you're logging in using password authentication that you actually get a Kerberos ticket, pam_winbind makes sure this happens. But now that we log in using Kerberos authentication, we don't get a ticket. Seems strange, but it's not. Ssh has decided to turn credential delegation off by default, but we can turn it on again. To do this on a per-user basis you can edit ~/.ssh/config and add the following line:

GSSAPIDelegateCredentials yes

Now if you logon to the machine using Kerberos your ticket is delegated and you can use it to ssh to other computers as well.

Final notes

You should now have a quite-well-integrated Linux machine. In future parts I will discuss mail routing and authentication and proxy server authentication and authorization. This post might be expanded to include some topics that were missing at first, I will try to keep an update list in here as well.