In a post a couple of years ago I gave an example on how to configure an Ubuntu 12.04 server to authenticate to Active Directory. Things used to be hard back then. Now we have the realmd realm enrollment manager to do the hard work of joining the host to an Active Directory domain, and the System Security Services Daemon or SSSD to do the actual authentication and authorization work whenever it is needed. And things are much easier to configure and get running.

Also in the mean time Microsoft has deprecated the Identity Management for UNIX extension to Active Directory. It used to be used to manage POSIX attributes in the AD for use by UNIX clients. Luckily, the SSSD has a nice coherent way of mapping Windows user and group ids to UNIX ones so that POSIX attributes may not be needed at all in the AD anymore, making things more straighforward. If you still need to be able configure attributes by individual LDAP entry basis, you may need to look into FreeIPA and ID Views. The automatic id mapping is not compatible with the old POSIX attributes in the sense that once you enable automatic id mapping, all the existing POSIX attributes are ignored.  So you may have to fix group memberships, for example, if your POSIX group memberships don’t match the Windows group memberships (the Windows group memberships are the ones that will be used with id mapping). And of course all the uid numbers will be changed when you flip the switch and enable automatic id mapping.

If you haven’t been using POSIX attributes in the AD schema before, you don’t have to worry about anything I said in the last paragraph. It just works.

Prerequisites

SSSD and realmd can be found in the Ubuntu repositories, so installation is easy. But a couple of things must be taken care of first.

The first prerequisite is, make sure you are using your Active Directory DNS servers. They will be used to query the addresses of the domain controllers, and when the domain is joined, DNS records (forward and reverse) are added.

The second prerequisite is that your time keeping should closely match the AD domain controller machines (usually within 5 minutes of each other). Use your domain controllers as NTP time sources, or at least use the same time sources for the domain controllers and the Linux hosts to keep their clocks very close to each other.

Install Kerberos client, SSSD and tools

Install the Kerberos client, the realm enrollment tool, the System Security Services Daemon, the AD client tool, and Samba tools:

When prompted, type in your AD Kerberos realm. It should generally be your domain name in capital letters (“koo.fi” becomes “KOO.FI”). If your DNS is working properly, that should be all that is needed for the Kerberos client to work alright. Otherwise you may need to add your servers to /etc/krb5.conf.

Authenticating with Kerberos

Try getting a Kerberos ticket as domain administrator:

The output of klist should look like this:

That shows we now have a ticket valid for some hours, meaning the Kerberos authentication is working fine to the domain controller. We can proceed to configuring the realmd realm enrollment tool which will join us to the domain, and later use this ticket to actually execute the join operation.

Configuring realmd

Edit /etc/realmd.conf:

The automatic-install=no option will disable automatic installation of packages by realmd.

The default-home=/home/%D/%U option will make the home directories of users be of form /home/DOMAIN/USERNAME, eg. /home/koo.fi/administrator. The default-shell is the shell for users.

The computer-ou option tells where the machine account will be added in AD.

The automatic-id-mapping=yes option makes SSSD use automatic id mapping instead of user and group ids stored in POSIX attributes in AD. The SSSD automatic id mapping is intelligent in that it can guarantee the same UNIX uid and gid on different hosts when all the hosts are using SSSD.

The fully-qualified-names=no option will by default remove the domain part from user and group names. It may result in name collisions, but makes things easier for users since they only have to type in their username part and not the domain part every time.

Joining The Host to the Active Directory Domain

You can use the “realm discover” command to see if the Active Directory domain can be discovered. It requires avalid Kerberos ticket as a domain administrator.

Output should look like:

We have all the required packages already installed, so let’s just join:

Output looks like:

After a successful join, you should be able to resolve individual users and groups using getent:

If you run into a “Failed to join the domain” error, try the join with user given as an option:

If you run into a “Necessary packages are not installed” error, you may try to install packagekit:

And then try again. There’s a bug in Launchpad about it.

Controlling Who Can Log In

Also at this point you should be able to log in with any AD user id by default. You can control who can and who cannot login with

You can see the changed policy and permitted logins with

Output:

Enumerating Users and Groups

The SSSD configuration file /etc/sssd/sssd.conf was generated by the realm join command and will look something like this:

For performance reasons by default SSSD will not try to enumerate every user and group from AD, but will only query for them when requested. If you want to enable enumeration, add:

under your domain stanza in sssd.conf (and “restart sssd”). It is quick for a small directory, but may be slow for a large one. It can be handy for debugging, as you can list all users and groups with
“getent passwd” and “getent group”.

Automatic Home Directories

To create home directories at first login, add a pam_mkhomedir.so line in /etc/pam.d/common-session:

That’s basicly it. At this point you should have a fully functioning AD login for selected users on your Ubuntu server.

Internals

The “machine account” Kerberos principal is saved into the file /etc/krb5.keytab. You can list its contents with “klist -kt /etc/krb5.keytab”:

Here the local server’s hostname is “server”. SSSD uses this keytab file and the principals in it to periodically refres Kerberos tickets, which are saved in the file  /var/lib/sss/db/ccache_<REALM>. For example “klist -c /var/lib/sss/db/ccache_KOO.FI”:

Here we can see three active tickets. These are used to authenticate the host to AD and fetch information from LDAP.

There are also .ldb files under /var/lib/sss/db which you can dump using tdbdump tool from the tdb-tools package if you want to see internal configuration and cached data.

The IP address of the AD domain controller currently used as KDC can be found in /var/lib/sss/pubconf/kdcinfo.<REALM>.

Links

• Ubuntu Server Guide: SSSD and Active Directory
• How to Join Ubuntu 14.04 to Active directory using Realmd
• Handling POSIX attributes for trusted Active Directory users and groups in FreeIPA (PDF)