Join Ubuntu 18.04 to Active Directory

At work, we are building a data ingress environment for analytical purposes. The setup will include both Windows and Linux based machines for managing the infrastructure and data processing. One of my tasks (next to the usual security hardening) was to investigate how we could add the Linux based nodes to the Windows Active Directory domain for simplified management. Turns out that there are a couple of way of accomplishing that task. It’s not really that straight forward as it is with Windows but once you get the right tools and know what files to edit it’s really not that hard. With this post I want to share my experiences and show you step-by-step on how to add a Linux based host to a Windows Active Directory.

System Security Services Daemon

I’ve tried a couple of options/packages for joining a Linux machine into a Windows based Active Directory domain, but in the end, for me, using the System Security Services Daemon (SSSD) was the most effective way to accomplish my task at hand.  The SSSD is like the intermediary that helps you to configure the system without you needing to know what files you need to edit (Although it can be very useful). The other benefit that I discovered is that it’s available on all major distributions, like RedHat or Ubuntu. So What I will be describing here will be useful in many situations. Let’s dive in.


My setup is straightforward. A single Domain Controller, named DC01 in the “” domain. Next to the DC role it also hosts the DNS role. The client computer is an Ubuntu 18.04 machine, named “Ubuntu18”, and is configured to use the DNS server on DC01. I’ve checked connectivity to DC01 with a simple ICMP ping and name resolution with NSLookup. Both work as expected.


First thing we need to do is install all the appropriate packages. This post will focus on Ubuntu 18.04, but it’s almost the same on other distributions that use apt (or yum) as their package manager. Open up a terminal, gain root privileges, install these packages:

  • Realmd
  • sssd
  • sssd-tools
  • libnss-sss
  • libpam-sss
  • krb5-user
  • adcli
  • samba-common-bin


apt install -y realmd sssd sssd-tools libnss-sss libpam-sss krb5-user adcli samba-common-bin

During the installation of the “krb5-user” you’ll be prompted for the domain name. Fill in your domain name in capital letters. See my example below.


If for some reason this pop-up does not appear (That happened to me once) or you want to change it afterwards, edit the file “krb5.conf” file in the “/etc/” directory. I always add these two entries to the file:

  • dns_lookup_realm = true
  • dns_lookup_kdc = true

That will explicitly tell the client to use DNS for all lookups instead of expecting it to be present in the “krb5.conf” file.

More info about configuration options can be found here:

Timing is everything

Using Kerberos authentication relies heavily on the correct time being set at both ends. It should always be within a maximum of 5 minutes difference between the two entities trying to authenticate. On Ubuntu, “timesyncd” is responsible for all thing related with time. First we need to point the client to the closest time source. Usually this is the DC that will provide the correct time, but any time source will do. Edit the following file to add the NTP source as displayed in the example:



Use these steps to set the correct time:

  • timedatectl set-ntp true (Set the NTP sync to true)
  • systemctl restart systemd-timesyncd.service (restart the service)
  • timedatectl –adjust-system-clock (Force sync)

After a while the time will start to sync. Use “timedatectl status” to get the actual status.

Configure realmd

Realmd is the configuration to add the linux host to a Kerberos realm like Active Directory. It consists out of tools and configuration options. The configuration is stored in the “realmd.conf” file that’s located in the “/etc/” directory.

The configuration that I found useful is the following:

 default-home = /home/%D/%U
 default-shell = /bin/bash

 default-client = sssd
 os-name = Ubuntu Workstation
 os-version = 18.04

 automatic-install = no

 fully-qualified-names = yes
 automatic-id-mapping = no
 user-principal = yes
 manage-system = yes

Information about the various options of the realmd.conf file can be found here:

Auto create home folders

Before we join the domain the system needs to be told that is needs to auto create users home folders. By default this is turned off for domain accounts and needs to be enabled first. This is easily done with the “pam-auth-update” tool. Type in that command while having root privileges and tick the box “Create home directory on login”.


The changes are saved to the file “/etc/pam.d/common-session“.

Testing Directory Access

Now that I have installed all the packages and configured the appropriate settings, I’m ready to test the setup. Ubuntu has a few very useful tools to see if Kerberos authentication will succeed. Use the following command to test it out:

Discover the domain

realm discover

Get a Kerberos ticket for the user Admin

kinit Admin

Display the Kerberos ticket


Destroy the ticket



The reason I destroy the ticket first is that it will otherwise be used during the domain join that I’ll show you next.

Joining the domain

Now that Kerberos is successfully tested, I am ready to join the domain. The tools that I’ll be using was installed with the realmd package, “realm“. Use the following command:

realm join --verbose --user=admin --computer-ou=OU=Linux,DC=corp,DC=bitsofwater,DC=com

In the example above I’ve turned on verbose output, told the command that I will be using the user named “Admin” to join the domain, put the created object into the “Linux” organizational unit in the “” domain. Hit enter and you’ll be prompted for the password, enter it and the domain join is executed. If all goes well it ends with “Successfully enrolled machine in realm”. Easy right!?


Checking the domain, a new object is created in the organizational unit.


If you want to change any configuration setting at a later stage, edit the SSSD file located at “/etc/sssd/sssd.conf“. Only thing I changed is the entry “ldap_id_mapping”, changed it to “True” as I don’t have the POSIX attributes set in Active Directory. Without this set, I could not login because it can’t translate user id’s.

Login Screen

For domain users to be able to login On Ubuntu 16.04 the login screen need to reconfigured. Normally it would only list the local users without the possibility to login other, domain based users. This capability was enabled by editing the unity login screen located at “/usr/share/lightdm/lightdm.conf.d/50-unity-greeter.conf” and adding the line:


On Ubuntu 18.04 there’s no need to change the login screen anymore. Simply selecting “Not Listed?” on the screen will provide you with a username / password screen. Enter the username with or without the domain suffix.


And that’s it! login with a domain account, the user will be authenticate to Active Directory and a local home folder will automatically be created for the user.

I hope that you will find this information useful.

10-07-2018: Update after user feedback

Make sure that your active directory is prepared for IPv6 as Ubuntu 1804 combined with Windows 2016 seems to default to IPv6 under certain circumstances. A user and myself got this error message “Couldn’t join realm: Insufficient permissions to join the domain“. Kind of a bogus message, but it turned out to be missing IPv6 information in AD DNS. Solution was to fix DNS or disable IPv6.

In my example above I used the domain suffix during login. At that time I didn’t know that there was an option to select a default domain if you only enter the user name. Edit the [sssd] section in “/etc/sssd/sssd.conf” to include the following “default_domain_suffix“.




47 thoughts on “Join Ubuntu 18.04 to Active Directory

  1. I’ve tried these instructions just now using Ubuntu 18.04 in a Virtualbox VM, and I cannot authenticate. I have a computer object registered on my domain controller, but when I try to authenticate with su or even rebooting into the login prompt, nothing works. I’ve had this exact same problem with every other guide I follow.

    Liked by 1 person

  2. Hi Sarah,

    Thanks for your feedback! Is here any other error message that you got? Anything in the logs? I had that same problem also, just ddn’t understand it at first. Messed around a lot with the config.

    Where does it go wrong:
    realm join
    or interactive logon

    Let’s see if we can solve it.


      1. I’ve been gathering information and did some testing with creating a sudoers object in AD. You will need to do a schema update though. I’m planning a new blog post on the subject. Seems to be more efficient to do centralized sudo users management.


  3. This problem on Ubuntu has bugged me for weeks:

    All the packages were installed fine. Realm discover went fine. Kinit, klist, kdestroy all went fine. But when I try realm join, after I entered password for the domain admin, I got this error message:

    ! Couldn’t authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
    adcli: couldn’t connect to domain: Couldn’t authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
    ! Insufficient permissions to join the domain
    realm: Couldn’t join realm: Insufficient permissions to join the domain

    At the same time, if I try the same thing from a CentOS box, then everything works just fine.

    In the case of Ubuntu box, the error from the AD side is: eRR-S-PRINCIPAL-UNKNOWN (7). As it turned out, the Kerberos request that resulted such an error is a TGS-REQ request.

    I compared the requests sending from a Ubuntu box and a CentOS box. In CentOS’s case, it’s kRB5-NT-SRV-HST ldap/, which worked perfectly. Where in Ubuntu’s case, the principal name for the service is: kRB5-NT-SRV-HST ldap/localhost, which inevitably result in a unknown principal name error.

    Here are the version of software I’m using:
    ii realmd 0.16.3-1 amd64 DBus service for configuring kerberos and other online identities
    ii adcli 0.8.2-1 amd64 Tool for performing actions on an Active Directory domain
    ii sssd 1.16.1-1ubuntu1 amd64 System Security Services Daemon — metapackage
    ii sssd-ad 1.16.1-1ubuntu1 amd64 System Security Services Daemon — Active Directory back end
    ii sssd-ad-common 1.16.1-1ubuntu1 amd64 System Security Services Daemon — PAC responder
    ii sssd-common 1.16.1-1ubuntu1 amd64 System Security Services Daemon — common files
    ii sssd-dbus 1.16.1-1ubuntu1 amd64 System Security Services Daemon — D-Bus responder
    ii sssd-ipa 1.16.1-1ubuntu1 amd64 System Security Services Daemon — IPA back end
    ii sssd-krb5 1.16.1-1ubuntu1 amd64 System Security Services Daemon — Kerberos back end
    ii sssd-krb5-common 1.16.1-1ubuntu1 amd64 System Security Services Daemon — Kerberos helpers
    ii sssd-ldap 1.16.1-1ubuntu1 amd64 System Security Services Daemon — LDAP back end
    ii sssd-proxy 1.16.1-1ubuntu1 amd64 System Security Services Daemon — proxy back end
    ii sssd-tools 1.16.1-1ubuntu1 amd64 System Security Services Daemon — tools

    Dear Sir, can you spot is there a version difference with what you are using? Or maybe you can point me to a different direction for troubleshooting? Thanks!

    Liked by 1 person

    1. Hi,

      What I can make out from the logs is that your account does not have the user rights to join the domain. “! Insufficient permissions to join the domain”. Could you give it a try with a domain admin or equivalent account?


    2. Ubuntu sets up the /etc/hosts file a little differently to CentOS and I think this is where your problem might be. Try remove the line from your hosts file for the and ensure you have a line using the nic IP address for your system with the fqdn and hostname of your server, e.g.

      # Comment this out
      # server

      # Add this server

      Liked by 1 person

      1. That’s a very good remark. I experienced somewhat the same when I started cloning my VM’s. Renamed my machine using “hostnamectl set-hostname “. Actually had some issues joining the domain as well. Turned out that the hosts file still contained the former name of the computer.


    3. Small update. I started to experience the exact same thing after I had upgraded my Windows server to 2016. After a few hours of troubleshooting I noticed that a ping dc01 would return an IPv6 address instead of IPv4. For simplicity sake I added the dc01 fqdn in the hosts file on a IPv4 address and it worked!

      Hope this helps anyone.


    4. Hey, I had this same error, for me at least it was an issue with reverse DNS being incorrect. You can either fix reverse DNS or add rnds=false to the krb5.conf. I suggest fixing reverse dns. but thats a workaround.


  4. Here’s a fun gotcha that took me a while to figure out: if you already *have* a local user with the same name as the username on your domain, you’ll need to rename that user account, otherwise (at least in 18.04) creating the domain user’s home directory will fail. Even though the new one is in /home//user and the old one was at /home/. No idea why.


    1. Hi Jason,

      I’ve just tested it on my setup and that worked as expected. Had both a superuser in AD and locally. Have you checked your sssd.conf file to include fallback_homedir = /home/%d/%u. The %d will create a directory that represents your domain, creating a home directory inside with the username.


      1. The fallback dir is definitely not colliding with the existing one – as far as I can tell (and nothing in the logs was really illuminating), it falls over simply because the usernames are the same. Once I used usermod to rename my old user, this all worked perfectly.

        Liked by 1 person

  5. I have one sort-of superficial question though: how can we populate the user information for the local account for the domain user? For example, at the moment instead of my full name, my entry on the login screen and in Gnome’s menu is simply the capitalised version of my domain username. Do you know of a way to change that?


    1. That I would have to guess. Take my user “John Doe” for example with the sAMAccountname “john”. In my setup the gnome menu on the top right of the screen shows “John Doe” instead of his login name. My best bet would be that the displayName attribute from the user account in AD is used here. Hope it helps.


      1. Hmm, my “displayName” is , – my Gnome menu definitely doesn’t display that. Do you know which part of this (sssd, realmd, pam) would be responsible for populating that?


  6. To answer my last question, it looks like SSSD, specifically the “sss_useradd” command. But there’s no way to configure displayed user name.


  7. Hi Michael,

    I’ve just followed your tutorial and it works parcially. I have a Domain in a Zentyal Server, I did everything and everything works except the login.

    I can’t login from Ubuntu using the %u@domain . Do you have any idea?


      1. Kinit works fine, I can order a ticket for the user I want to login.


        domains =
        config_file_version = 2
        services = nss, pam

        ad_domain =
        krb5_realm = CHARLOTTESCHOOL.UK
        realmd_tags = manages-system joined-with-adcli
        cache_credentials = True
        id_provider = ad
        krb5_store_password_if_offline = True
        default_shell = /bin/bash
        ldap_id_mapping = True
        use_fully_qualified_names = True
        fallback_homedir = /home/%d/%u
        access_provider = ad


  8. One more tip: you need to update apparmor’s home directories list. Do sudo dpkg-reconfigure apparmor and enter /home/ Not doing this makes snap apps fail with ‘cannot create user data directory’ as per bug #1620771.

    Liked by 1 person

  9. Thanks to everyone here for being so helpful. Starting a week ago maybe, it seems there was a change made to something that broke SSSD AD support. I can sudo -s -u %USER% and become that AD user with no issues after joining, but trying to log into a session in the first place as that user just says “system error.” There are no hints to speak of in /var/log/auth.log or anything in the SSSD logs beyond reiterating “system error.” Does anyone have any ideas what might be happening here?


  10. Great Article, after 2 days I came to this manual and solved my issue and now I am able to login with the domain user, thanks Michael.
    I have now one question- i am able to do RDP with XRDP with the regular admin user but can’t do RDP login with domain users, do you know why? or how can I solve it? I am using Ubuntu 18.04.



  11. Michael – thank you for the guide. I was even able to add the Domain Admins group to the ‘sudoers’ list so they could effectively be admins of the Ubuntu server. I added `”%domain admins” ALL=(ALL) ALL` to `/etc/sudoers` and then added “sudo” to the `/etc/sssd/sssd.conf` file; i.e. `services = nss, pam, sudo`.

    My goal now is to create a share on the Ubuntu box that the domain admins can access from windows. I would greatly appreciate any guidance you can give to help me accomplish this.


  12. Hi Derek,

    Thanks for the feedback. Always appreciate people taking the time to write back to me. Did you see my guide on centrally managing SUDO users? It’s listed here:

    As for creating a samba share that should be really straightforward. Look here:

    Hope it helps!


    1. Thanks for the prompt response, Michael.

      I did see your ‘sudo/AD’ guide and may try that in my local environment; but there would likely be too much red-tape involved to implement that in a client environment.

      I will check out your link for the samba share, thanks again!


  13. Very nice manual and works really well. Big hug for this, been digging around in the web a lot and nearly was going to let Ubuntu down in favor of Windows …

    Just one addition for special case:
    If you have a AD domain with a .local ending, then you need to change something to make it work with avahi on Ubuntu 18.04 (FQDN resolution for local domain will not work otherwise). Credits to, I have removed [NOTFOUND=return] in /etc/nsswitch.conf and then it worked out fine.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s