Ubuntu 14.04 Active Directory Authentication

5.00 avg. rating (95% score) - 1 vote

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.


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


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.


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>.


15 thoughts on “Ubuntu 14.04 Active Directory Authentication”

  1. I followed these instructions but getent would not return any domain users or groups. I found that /etc/krb5.conf did not contain the entries required in the [realms] and [domain_realm] sections. Once I added them it worked.

  2. I have a set-up like this but now want to use samba shares with AD group access controls. Do you know how to map the groups?

    1. Hi, this configuration already maps groups. You should be able to list group members with eg.

      You can use those groups when configuring Samba.

  3. Followed you guide and it all worked perfectly, thanks!

    One thing though.
    I dont have any host/servername.domainname@DOMAINNAME type principals in my keytab.

    I have host/servername@DOMAINNAME, servername@DOMAINNAME and RestrictedKrbHost/servername@DOMAINNAME, how do I get host/servername.domainname@DOMAINNAME principals I need them because ssh gssapi checks against them.

    If they aren’t present I get Unspecified GSS failure. Minor code may provide more information\nNo key table entry found matching host/servername.domainname@\n

  4. Followed you guide and it all worked perfectly, thanks!

    There is just one thing. With the AD user being in the sudoers when sudo is executed an event is generated like so

    myhost : Feb 25 08:14:15 : myuser : problem with defaults entries ; TTY=pts/0 ; PWD=/home/my.domain/myuser;

    I am wondering if this has something to do with the UMASK that is set in ‘/etc/pam.d/common-session’.

    Any ideas?

  5. Hello,

    I followed your guide for a Ubuntu 14.04 lxc container. I can enroll in the realm, but I can´t resolve users using getent.

    With a kvm machine it all works fine.

    Could you please give me a hint?

    1. I would add enumerate=True along with some debug_level to sssd.conf and then see what you get in your log files while running getent passwd. See “man sssd.conf”. I hope that leads you to the culprit.

      1. That did it, at least part of it.
        The permissions on the sssd.conf weren´t set correctly, it needs to be owned by root.root and have 0600 permissions.

        I can resolve AD users now, but I can´t login with them. I just get
        “groups: cannot find name for group ID xyz”

          1. To clarify:
            I can resolve users and groups with getent.
            I can log in as AD-user

            The only thing I can´t do is su AD-user.

  6. thanks for the tutorial… it works fine on linux boxen….

    however, if a user creates a file/directory on windows, it comes up as different UID:GID on my linux box and the user cannot access it on linus.

    anything i missed?


  7. I have an interesting situation where I have join privileges, but only to a specific OU within the domain. Is there a way to specify which container to join during the join process?

Leave a Reply