Join an Ubuntu server to Active Directory with realmd

Joining a Linux server to Active Directory lets the operating system resolve domain users and groups and, where permitted, authenticate them through SSSD. realmd handles domain discovery and configures the supporting services without requiring you to build the Kerberos and SSSD configuration by hand.

This example joins an Ubuntu server named maxdev01 to ad.example.com. Replace every example value with the names used by your environment.

Decide what you are joining

This procedure is for a server that needs Active Directory identities and logins. It uses SSSD and does not turn the host into a Samba file server. A server that will provide SMB shares needs a Samba member-server design and an appropriate identity-mapping strategy.

Before changing authentication on a remote server:

Keep an existing root or local-administrator session open.
Confirm that a local account still has sudo access.
Take a configuration backup or virtual-machine snapshot where appropriate.
Arrange a console or out-of-band recovery path.
Ask the AD team which organizational unit, join account and login groups to use.

The account used for the join only needs permission to create or update the computer object in the intended organizational unit. It does not need to be a Domain Administrator.

Check DNS and time first

The server must use DNS that can resolve the AD domain and its service records. Check the current resolver and test an AD SRV record:

resolvectl status
dig +short _ldap._tcp.dc._msdcs.ad.example.com SRV

Kerberos also depends on synchronized clocks. Confirm that time synchronization is active and that the server time agrees with the domain controllers:

timedatectl status

Fix DNS or time synchronization before attempting the join. Repeatedly retrying with broken discovery will only produce misleading authentication errors.

Set the fully qualified hostname

Give the server a stable, unique fully qualified domain name:

sudo hostnamectl set-hostname maxdev01.ad.example.com
hostname --fqdn

hostnamectl changes the system hostname. It does not reliably maintain /etc/hosts for you. If your network configuration requires a static hosts entry, edit it separately and make sure the address, short name and fully qualified name agree with DNS. Do not add a stale address merely to make hostname --fqdn return the expected value.

Install realmd and SSSD

Refresh the package index and install the domain-discovery, SSSD, PAM and AD join tools explicitly:

sudo apt update
sudo apt install \
  realmd \
  sssd \
  sssd-tools \
  libnss-sss \
  libpam-sss \
  adcli \
  samba-common-bin \
  packagekit \
  dnsutils

Installing the packages explicitly makes the intended authentication stack visible. realmd can use PackageKit to request missing dependencies, but that should not replace reviewing what will be installed on a managed server.

Discover the domain

Ask realmd to discover Active Directory before making any changes:

realm discover ad.example.com

The output should identify the server software as active-directory, show the Kerberos realm and list SSSD as the client software. A discovery failure usually points to DNS, routing, firewall or time configuration rather than bad join credentials.

Join Active Directory

Join with the delegated account supplied by the AD team:

sudo realm join ad.example.com --user=join-account

The command prompts for the account password without putting it in shell history. Do not pass a password on the command line.

To place the computer account in a specific organizational unit, add its distinguished name:

sudo realm join ad.example.com \
  --user=join-account \
  --computer-ou="OU=Linux Servers,OU=Servers,DC=ad,DC=example,DC=com"

Agree the OU with the AD team first. Moving the computer later can affect delegated permissions or policies attached to that OU.

Verify the join

Check the configured realm and the machine-account relationship:

realm list
sudo adcli testjoin

Then confirm that NSS can resolve a known domain user:

getent passwd 'test.user@ad.example.com'
id 'test.user@ad.example.com'

A successful realm join is not enough on its own. getent and id prove that the operating system can retrieve the identity it will use for ownership and access checks.

Restrict who can log in

Do not leave every domain user able to log in unless that is the intended policy. Deny domain logins, then permit the approved group:

sudo realm deny --all
sudo realm permit --groups 'Linux Server Users@ad.example.com'

Keep the local recovery account outside this policy. Test the permitted group and an ordinary domain account that should be denied before closing the original administrator session.

If interactive users need local home directories, enable their creation on first login:

sudo pam-auth-update --enable mkhomedir

Use a separate SSH session to test a permitted domain account. Confirm login, group membership, home-directory ownership and any approved sudo policy. Joining the domain does not automatically grant administrative access.

Reboot only when you need to

A successful realm join configures and starts the required services, so a reboot is not normally part of the join. Reboot when another operating-system change requires it or when your change procedure includes a restart test.

Either way, verify the relationship again after the next reboot:

realm list
sudo adcli testjoin
id 'test.user@ad.example.com'

Leave the domain

If validation fails and you need to roll back, keep the local administrator session open and remove the domain configuration deliberately:

sudo realm leave ad.example.com --user=join-account

Confirm with the AD team whether the computer object should be removed or retained for investigation. Restore any DNS, hostname, PAM or access-policy changes made outside realmd, then test local login before ending the recovery session.

Settings

Keyboard shortcuts