Joining Linux to Active Directory: A No-Nonsense Guide to SSSD and Realmd

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

Stop Managing Accounts One Server at a Time

Manually managing local user accounts across 50+ Linux servers is a recipe for a bad weekend. It is tedious and insecure. If you are already running a Windows environment, your Active Directory (AD) domain is the perfect place to centralize your Linux identities. By the end of this guide, you will log in to your Linux boxes using your AD credentials. You will also be able to enforce group-based access and manage sudo permissions directly from your domain controller.

Quick Start (5 min)

I recommend starting with a clean slate. Before you type a single command, ensure your Linux server can reach your Domain Controller (DC) over ports 389 (LDAP), 445 (SMB), and 88 (Kerberos). Your DNS settings must point to your AD DNS servers. This is the most common point of failure.

1. Install the Required Packages

First, grab the tools that do the grunt work. We use realmd to discover the domain and sssd to handle authentication and caching.

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

During the installation of krb5-user, you will see a prompt for your default Kerberos realm. Type your domain name in ALL CAPS (e.g., EXAMPLE.COM). Kerberos is picky about case sensitivity.

2. Discover and Join the Domain

Verify that your server can actually see the domain. Use the realm discover command:

realm discover example.com

If the output looks correct, join the machine to the domain. You will need credentials for an AD account, like a Service Account or Administrator, that has permissions to join computers.

sudo realm join --user=Administrator example.com

3. Verify the Connection

Test the bridge. Try to pull information for an existing AD user:

id [email protected]

Behind the Scenes: SSSD vs. Realmd

I prefer realmd because it automates the headache of Kerberos and SSSD configuration. In the past, admins had to manually edit krb5.conf and smb.conf. One typo there could break everything. realmd acts as a smart coordinator for these services.

The Power of SSSD

The System Security Services Daemon (SSSD) makes this setup robust. It does more than check passwords; it caches credentials. This is a lifesaver if your network connection to the DC blinks out. Your users can still log in using the cached data until the connection recovers.

On my production Ubuntu 22.04 nodes with 4GB of RAM, SSSD handles hundreds of simultaneous authentication requests without breaking a sweat. It is significantly more efficient than older methods like Winbind.

DNS: The Foundation

DNS issues cause 99% of realm discover failures. AD relies heavily on SRV records to locate LDAP and Kerberos services. Your Linux server must use the AD Domain Controller as its primary DNS. Check your records with this command:

host -t SRV _kerberos._udp.example.com

Tuning SSSD

While realmd creates a functional config, you will likely want to tweak /etc/sssd/sssd.conf. A common edit is removing the domain suffix from usernames. This allows you to log in as username instead of the longer [email protected].

[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
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 = False
fallback_homedir = /home/%u

Restart the service after any changes: sudo systemctl restart sssd.

Advanced Control: Sudo and Access Groups

Once joined, you should restrict who can actually access the server. You probably don’t want every single domain user logging into your database servers.

Restricting Login Access

I usually deny everyone first and then selectively allow specific AD groups.

sudo realm deny --all
sudo realm permit -g "Linux Admins"

This command ensures only members of the “Linux Admins” security group can SSH into the box.

Automating Home Directories

When an AD user logs in for the first time, they need a place to store files. Enable the pam_mkhomedir module to automate this process. It saves you from manually creating folders for every new hire.

sudo pam-auth-update --enable mkhomedir

Granting Sudo Privileges

You can map AD groups to root privileges. Create a dedicated file in /etc/sudoers.d/ to keep your configuration clean.

sudo nano /etc/sudoers.d/ad-admins

Add this line. Remember that spaces in AD group names must be escaped with a backslash:

%Linux\ Admins ALL=(ALL) ALL

Practical Troubleshooting Tips

Joining AD to Linux isn’t always smooth. Here is what I have learned from the field:

  • Time Sync is Critical: Kerberos will fail if your server’s clock is more than 300 seconds (5 minutes) off from the DC. Always use chrony to sync with your domain controllers.
  • Clear the Cache: If you update a user’s group in AD and Linux doesn’t see it, flush the cache: sudo sss_cache -E.
  • Check the Logs: When things go sideways, journalctl -u sssd is your best friend. For deep debugging, set debug_level = 9 in your sssd.conf.
  • Hostname Symmetry: Your local hostname should match the computer object name in AD. Use hostnamectl set-hostname myserver.example.com before joining.

Consolidating your identities into Active Directory is a massive win for security. It feels great to disable a single AD account and know that access is instantly revoked across your entire Linux fleet.

Share: