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.


Windows Activation

At times I need a semi isolated Lab environment that will last for an extended period of time. Using Windows as an operating system I could fall back on using the evaluation version of the OS but wouldn’t it be cool if I could be using our corporate activation services for that? Luckily there’s a very easy way to get your machines activated, even when you run a lab environment. As most of you know Windows activation is accomplished by using the KMS service. It’s a service that uses anonymous RPC at port 1688. Being anonymous by nature is something we can take advantage of. To start using the corporate server you should do an inventory first. On your corporate network use the NSLookup utility to query for KMS entries.

nslookup -type=srv _vlmcs._tcp

If your environment contains KMS servers it will list something like this: SRV service location
svr internet address =

Now you have the name and IP address of your corporate kms server, go to your lab setup and create a DNS service record in the _tcp. zone.

  1. Open the DNS management on your DNS server.
  2. Expand the DNS Zone.
  3. Right-click on the “_tcp” folder and select “Other” -> “New Records“.
  4. Select Service Location (SRV) as the new record type.

Fill in the following information for the new DNS record:

Service: _VLMCS
Protocol: _tcp
Port: 1688
Priority: 10
Host offering the service: (or the IP address)

Go to your client or server and at an elevated command prompt type:

slmgr /ato

this will activate your machine. Use:

slmgr /dlv

to see the activation status.