Joining Ubuntu Server to Windows AD with SSSD: Centralized Management for Hundreds of Users – ITFROMZERO

Table of Contents

The Nightmare of “Manual User Management”

If you’re only running one or two Ubuntu Servers, using the adduser command every time a new employee arrives is still manageable. However, imagine your infrastructure scaling to 50 or 100 servers. At that point, resetting a password for a developer or revoking access for a departing employee will consume your entire day. That’s why every professional Sysadmin looks for ways to bring Linux under the same roof as Windows Active Directory (AD).

Back when I first started, I once spent a whole week just configuring authentication for a Lab Server cluster. After many “hard-learned lessons,” I realized that AD integration doesn’t just centralize management; it acts as a critical security checkpoint for the enterprise.

Should You Choose SSSD or Samba Winbind?

To connect Linux and AD, we typically choose between two popular options:

Samba Winbind: A legacy solution based on the SMB protocol. Winbind is powerful, but its configuration files are often incredibly long. It’s also prone to UID/GID identification errors if you aren’t well-versed in ID mapping.
SSSD (System Security Services Daemon): The modern standard for Ubuntu and RHEL. SSSD offers excellent caching, allowing users to log in normally even if the connection to the Domain Controller (DC) is unstable or interrupted.

Why SSSD is the “Perfect Match” for Sysadmins?

I implemented this configuration in a staging environment running Ubuntu 22.04 with around 200 AD users. The results were very positive:

Key Advantages

Response Speed: The caching mechanism makes user queries nearly instantaneous, reducing the load on the DC.
Minimalist Configuration: The sssd.conf file is only about 20-30 lines long, making it much easier to maintain than Samba’s mess.
Kerberos-Based Security: The entire authentication process complies with the strictest enterprise security standards.

A Few Minor Notes

The DNS system must be extremely accurate (both A and PTR records). If DNS is “out of sync,” SSSD will stop working immediately.
Pay close attention to UID/GID mapping if you are operating complex file-sharing systems.

Practical Deployment Process

In this guide, we’ll assume the domain is itfromzero.local and the Domain Controller (DC) has the IP 192.168.1.10.

Step 1: DNS and Time – Two Vital Factors

Never skip this step. The Kerberos protocol is extremely sensitive to time drift. If the time on Ubuntu and AD differs by more than 300 seconds (5 minutes), the domain join will fail immediately.

# Set hostname to FQDN standard
sudo hostnamectl set-hostname ubuntu-server.itfromzero.local

# Install chrony for accurate time synchronization
sudo apt update && sudo apt install chrony -y
sudo systemctl enable --now chrony

Check your /etc/resolv.conf file. Ensure the first nameserver is the IP address of your Domain Controller.

Step 2: Installing Connectivity Tools

Instead of manually installing each library, we’ll use realmd to automate most of the heavy lifting.

sudo apt install -y realmd sssd sssd-tools adcli samba-common-bin packagekit

Step 3: Joining the Domain

First, check if Ubuntu can “see” the AD:

realm discover itfromzero.local

If the results show domain information, you’re halfway there. Now, execute the join command using an account with Domain Admin privileges:

sudo realm join -U Administrator itfromzero.local

Step 4: Optimizing SSSD Configuration

By default, you’ll need to type [email protected] to log in. To shorten this to just user, edit the following configuration file:

sudo nano /etc/sssd/sssd.conf

Find and change use_fully_qualified_names = True to False. Also, configure automatic home directory creation so users don’t encounter errors upon login:

use_fully_qualified_names = False
fallback_homedir = /home/%u

# Note: This file must have 0600 permissions
sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl restart sssd

Step 5: Automatically Creating Home Directories for New Users

To have the system automatically create the /home/username folder on the first login, run the following command:

sudo pam-auth-update --enable mkhomedir

Verifying the Results

Confirm that Ubuntu recognizes the AD user by using the id command:

id your_ad_user

If the screen displays the full UID, GID, and groups from Windows, your system is ready for action.

Pro tip: To prevent anyone with an AD account from being able to SSH into the server, you should restrict access to a specific technical group:

sudo realm deny --all
sudo realm permit -g "IT_Admins_Group"

In summary, joining Ubuntu to AD isn’t difficult as long as you have good control over DNS and time synchronization. Good luck streamlining your workload and managing your systems more professionally!