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.

Infrastructure

My setup is straightforward. A single Domain Controller, named DC01 in the “corp.bitsofwater.com” 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.

Packages

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

Command:

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.

Linux-ADJoin-002

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:
https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/libdefaults.html

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:

/etc/systemd/timesyncd.conf

Linux-ADJoin-003

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:

[users]
 default-home = /home/%D/%U
 default-shell = /bin/bash

[active-directory]
 default-client = sssd
 os-name = Ubuntu Workstation
 os-version = 18.04

[service]
 automatic-install = no

[corp.bitsofwater.com]
 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:
https://www.freedesktop.org/software/realmd/docs/realmd-conf.html

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

Linux-ADJoin-005

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 corp.bitsofwater.com

Get a Kerberos ticket for the user Admin

kinit Admin

Display the Kerberos ticket

klist

Destroy the ticket

Kdestroy

Linux-ADJoin-007

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 corp.bitsofwater.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 “corp.bitsofwater.com” 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!?

Linux-ADJoin-008

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

Linux-ADJoin-011

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:

greeter-show-manual-login=true

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.

Linux-ADJoin-010

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

 

 

 

35 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:
    kinit
    realm join
    or interactive logon

    Let’s see if we can solve it.

    Like

      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.

        Like

  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 fftechs.int 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?

      Like

    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 127.0.1.1 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
      # 127.0.1.1 server.example.com server

      # Add this
      192.168.1.1 server.example.com 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.

        Like

    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.

      Like

  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.

    Like

    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.

      Like

      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?

    Like

    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.

      Like

      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?

        Like

  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.

    Like

  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?

    Like

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

        sssd:

        [sssd]
        domains = charlotteschool.uk
        config_file_version = 2
        services = nss, pam

        [domain/charlotteschool.uk]
        ad_domain = charlotteschool.uk
        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

        Like

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

    Liked by 1 person

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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