How to Join Linux to Active Directory Domain Using Realmd and SSSD

Table of Contents

Click to expand overview

Overview

  • realmd orchestrates the setup
  • adcli performs the actual domain join
  • kerberos handles authentication
  • ldap supplies directory info
  • sssd glues everything together for the system to authenticate and manage AD users (including mapping Windows SIDs to Linux User/Group IDs)

💡 Note: Unless otherwise specified, the steps in this guide apply to both RHEL-based and Ubuntu-based systems. Where package names or service tools differ (e.g. chronyd vs systemd-timesyncd), both options are shown.

Click to expand Pre-Join Checklist

Pre-Join Checklist

  1. It is recommended to use the domain admin Administrator user to join with Active Directory. If Administrator user cannot be used, the normal Active Directory user should have following permissions.

  • On the object types:

    • Computer

  • Standard permissions required for joining all systems to an AD:

    • Reset password
    • Read account restrictions
    • Write account restrictions
    • Validated write to DNS host name
    • Validated write to service principal name

  • Additional permissions required for joining Linux systems to an AD:

    • Read DNS host name attributes
    • Write DNS host name attributes
    • Read DNSHostName
    • Write DNSHostName
    • Read msDS-AdditionalSamAccountName
    • Write msDS-AdditionalSamAccountName
    • Read msDS-SupportedEncryptionTypes
    • Write msDS-SupportedEncryptionTypes
    • Read Operating System
    • Write Operating System
    • Read Operating System Version
    • Write Operating System Version
    • Read OperatingSystemServicePack
    • Write OperatingSystemServicePack
    • Read servicePrincipalName
    • Write servicePrincipalName
    • Read userAccountControl
    • Write userAccountControl
    • Read userPrincipalName
    • Write userPrincipalName
  1. Set Domain Controller as DNS server

For RHEL/Alma

nmcli con mod "Wired connection 1" ipv4.dns "10.0.0.1"
nmcli con up "Wired connection 1"

For Ubuntu

sudo resolvectl dns eth0 10.0.0.1
  1. Verify DNS resolution for AD service. This is how the system will find your Domain Controller.
dig +short SRV _ldap._tcp.example.com
dig +short SRV _kerberos._tcp.example.com
dig +short SRV _kerberos._udp.example.com
  1. Verify network connectivity to the Domain Controller
# DNS Ports
nc -zv adserver1.example.com 53
nc -zuv adserver1.example.com 53

# LDAP Ports
nc -zv adserver1.example.com 389
nc -zuv adserver1.example.com 389
nc -zv adserver1.example.com 636

# Kerberos
nc -zv adserver1.example.com 88
nc -zuv adserver1.example.com 88

# Kerberos Kadmin
nc -zv adserver1.example.com 464
nc -zuv adserver1.example.com 464

# Active Directory: Global Catalog
nc -zv adserver1.example.com 3268
nc -zv adserver1.example.com 3269

# NTP
nc -zuv adserver1.example.com 123
  1. Validate NTP time sync with Domain Controller

Kerberos requires your system clock to be closely in sync with the Domain Controller. Using your DC as the NTP source prevents login failures caused by time drift.

For RHEL/Alma

chronyc sources
systemctl stop chronyd
chronyd -q "server adserver1.example.com iburst"
systemctl start chronyd
systemctl status chronyd
chronyc tracking

For Ubuntu

Edit /etc/systemd/timesyncd.conf to use your domain controller as an NTP source

[Time]
NTP=adserver1.example.com
FallbackNTP=ntp.ubuntu.com
sudo systemctl restart systemd-timesyncd
sudo timedatectl set-ntp true
timedatectl status
# verify the time source
timedatectl show-timesync --all
  1. Set hostname as FQDN
hostnamectl  set-hostname server.example.com

RHEL/Alma Setup

sudo dnf install -y sssd realmd adcli oddjob oddjob-mkhomedir samba-common-tools

# Verify domain is discoverable
sudo realm -v discover example.com

# Join the domain (you'll be prompted for the password of the domain user)
sudo realm join -v --user=administrator example.com

# Enable automatic home directory creation on login
sudo authselect select sssd with-mkhomedir --force

# Optional: restart SSSD service to apply settings
sudo systemctl restart sssd

# Check SSSD config syntax
sudo sssctl config-check

Ubuntu Setup

sudo apt install -y sssd-ad sssd-tools realmd adcli libnss-sss libpam-sss samba-common-bin oddjob oddjob-mkhomedir packagekit

# verify domain is discoverable
sudo realm -v discover example.com
# join domain
sudo realm join -v --user=administrator example.com

# automatic home directory creation
sudo pam-auth-update --enable mkhomedir

# Optional: restart SSSD service to apply settings
sudo systemctl restart sssd

# check /etc/sssd/sssd.conf syntax
sudo sssctl config-check

Leave the Domain

sudo realm leave --user=administrator example.com

Verify Setup

Check if SSSD can resolve users/groups

id [email protected]
getent passwd [email protected]
getent group [email protected]

Try a test login

ssh '[email protected]'@localhost

Test Kerberos Authentication

kinit [email protected]
klist

Allow Only Specific Groups to Log In

By default, all domain users can log in after the system joins the domain. You can restrict access to specific groups like this:

Verify SSSD can resolve the group

getent group [email protected]

Permit only [email protected] group to log in

# Replace 'LinuxUsers' with the actual name of your AD group
# If using `use_fully_qualified_names = True`, use [email protected].
# Otherwise, just 'GroupName' may be sufficient depending on your config.
sudo realm permit -g '[email protected]'

This will:

  • Allow only users in the group [email protected] to log in.
  • Automatically updates the access control section in /etc/sssd/sssd.conf.
  • Take effect immediately

To permit multiple groups, add them in the same command

# Permit multiple groups to log in
sudo realm permit -g "[email protected]" -g "[email protected]" -g "[email protected]"

Verify with

realm list

Look for a section like:

login-policy: allow-permitted-logins
permitted-groups: [email protected]

sssd.conf

This file contains sensitive credentials. Set strict permissions:

sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf

After editing sssd.conf

# Check SSSD config syntax
sudo sssctl config-check
# Restart SSSD service to apply settings
sudo systemctl restart sssd
Click to expand example /etc/sssd/sssd.conf 
[sssd]
domains = example.com
# Default domain suffix appended 
# to usernames when missing
default_domain_suffix = example.com
config_file_version = 2
# Services SSSD will provide: 
# NSS for system info
# PAM for authentication
services = nss, pam

[domain/example.com]
realmd_tags = manages-system joined-with-adcli
id_provider = ad
access_provider = ad
ad_domain = example.com
# Enable caching of user credentials locally
cache_credentials = True
# Map AD Security Identifiers (SIDs) to Unix IDs
ldap_id_mapping = True

# Use fully qualified usernames (e.g. [email protected])
use_fully_qualified_names = True
default_shell = /bin/bash
# Home directory path template for users 
# (e.g., /home/username_domain)
override_homedir = /home/%u_%d
fallback_homedir = /home/%u_%d

# Ignore unreadable Group Policy Objects 
# to prevent login issues
ad_gpo_ignore_unreadable = True

# Cache Kerberos password to allow offline login
krb5_store_password_if_offline = True
krb5_realm = EXAMPLE.COM

# Enable dynamic DNS updates for the system's 
# IP/hostname
dyndns_update = True
# every 12 hours, SSSD will attempt to update
# the DNS records for the hostname/IP 
# in Active Directory.
# 43200 seconds = 12 hours
dyndns_refresh_interval = 43200
# Update DNS PTR record for reverse lookup
dyndns_update_ptr = True
# Time-to-live for DNS records (in seconds)
# How long clients will cache this system's 
# DNS records locally
# 3600 seconds = 1 hour
dyndns_ttl = 3600
# Use Kerberos GSS-TSIG for secure DNS updates
dyndns_auth = GSS-TSIG
# Hostname of this system registered in AD/DNS
ad_hostname = server.example.com
# Disable user/group enumeration for better performance
enumerate = False

Dynamic DNS (DynDNS)

DynDNS allows your server to update its own DNS A/PTR records automatically. This saves you from having to manually add the server to DNS.

The system must be allowed to update its own DNS record on the Domain Controller. Typically, by default, a computer has permission to update its own DNS records if:

  • The DNS zone is set to Secure only dynamic updates.
  • The computer account is not restricted explicitly.

Verify the system has permission:

  1. In Active Directory Users and Computers, find your server
  2. Right-click → Properties → Security tab.
  3. Make sure the computer account has Write permissions to its DNS record in the DNS zone.

Test DDNS Update Using nsupdate

On your Linux system:

nsupdate -g
> server <your_dns_server_ip>
> update add server.example.com 3600 A <your_ip_address>
> send
  • g uses GSS-TSIG (Kerberos) authentication.
  • If the update succeeds without errors, your machine is authorized.
  • If you get permission errors, your machine is likely not allowed or there’s a DNS/AD permission issue.

Troubleshooting DynDNS

Make sure your machine has a valid Kerberos ticket for the AD domain:

klist

Check SSSD logs

journalctl -u sssd
grep dyndns /var/log/sssd/sssd_domain.log

Errors like “access denied” or “failed to update DNS” indicate permission or config problems.

Troubleshooting

Drop SSSD Cache and try to log in again

sss_cache -E

If login fails after a successful join, check /var/log/secure and journalctl -xe for errors.

Run sssd -d 9 -f to debug live authentication problems.

Additional Info

realmd

  • A high-level tool for discovering and joining identity domains like Active Directory or FreeIPA.
  • Automates the configuration of sssd, kerberos, and nsswitch.conf.
  • Simplifies domain join/leave operations.

adcli

  • A command-line tool used by realmd to create and manage machine accounts in Active Directory.
  • Handles low-level domain join operations and keytab generation.
  • Communicates with the AD DC over LDAP and Kerberos.

sssd

  • Provides authentication and identity information from external sources (like AD, LDAP, or Kerberos).
  • Caches credentials for offline logins and integrates with PAM (authentication) and NSS (identity lookup).
  • Maps AD SIDs to Linux User/Group IDs
  • Manages access control and group membership resolution.

kerberos

  • A secure authentication protocol used by Active Directory.
  • Provides ticket-based authentication that avoids transmitting passwords over the network.
  • Required for secure logins and SSSD’s AD integration.

LDAP (Lightweight Directory Access Protocol)

  • A protocol for querying and modifying directory services like Active Directory.
  • Used by sssd and adcli to retrieve user, group, and machine information.
  • AD exposes directory info over LDAP on ports 389 (unencrypted) and 636 (LDAPS).