On a server without AD integration, each new employee gets a local account manually. With a headcount of 50, this takes 2 hours per week. Passwords aren't synchronized, and access to shared resources is configured separately. Our integration experience exceeds 10 years — we've implemented over 50 projects. SSSD and Realmd are standard tools for linking Linux and AD. According to Red Hat documentation, SSSD is recommended for centralized authentication.
How It Works
Realmd is a domain discovery and join tool. It runs once when joining the domain. SSSD (System Security Services Daemon) is a constantly running daemon: it contacts AD for authentication, caches credentials, and provides user information through NSS. Unlike Winbind, SSSD supports caching and GPO — critical for fault tolerance. Authentication via SSSD is 3 times faster under 1000+ user load due to caching.
Domain Join
apt install realmd sssd sssd-tools adcli krb5-user samba-common-bin
# Or on RHEL: dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools krb5-workstation
realm discover corp.example.com
realm join --user=Administrator corp.example.com
realm listAfter joining, verify with: id [email protected]. If the command returns user information, it's working.
SSSD Configuration
The auto-generated config works but needs adjustments for production. Here's a typical configuration with explanations:
[sssd]
domains = corp.example.com
config_file_version = 2
services = nss, pam
[domain/corp.example.com]
ad_domain = corp.example.com
krb5_realm = CORP.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
access_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
# jsmith instead of [email protected]
fallback_homedir = /home/%u
ad_gpo_access_control = permissive
# or enforcing if GPOs neededuse_fully_qualified_names = False is an important parameter. Without it, users log in as [email protected], which is inconvenient. With it, just jsmith, but may conflict with local users. cache_credentials = True allows login during temporary DC unavailability. The cache is stored in /var/lib/sss/db/.
How to Auto-Create Home Directories?
On first login, there's no home directory. pam_mkhomedir creates it automatically. Activate via pam-auth-update --enable mkhomedir (Debian) or authselect enable-feature with-mkhomedir (RHEL). Alternatively, add manually in /etc/pam.d/common-session: session required pam_mkhomedir.so skel=/etc/skel/ umask=0077.
Restricting Access by AD Groups and sudo
Not all AD users should log into every server. Two methods:
# Via realm
realm permit -g '[email protected]'
realm deny --all
# Via sudoers
echo '%[email protected] ALL=(ALL:ALL) ALL' > /etc/sudoers.d/ad_groups
echo '%[email protected] ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart *, /usr/bin/journalctl' >> /etc/sudoers.d/ad_groups
If use_fully_qualified_names = False, use %LinuxAdmins.
Diagnostics and Common Errors
sssctl domain-status corp.example.com
sssctl user-checks jsmith
journalctl -u sssd --since "10 minutes ago"
kinit [email protected] && klistA common problem: sssd cannot reach the DC after network configuration changes. sssctl domain-status shows Online or Offline. When Offline, check DNS (SRV records _ldap._tcp.corp.example.com must resolve), server time (Kerberos tolerance < 5 minutes), firewall (ports 88/tcp, 389/tcp, 636/tcp to DC). Another frequent scenario is UID/GID duplication when using multiple domains; solved via ldap_id_mapping.
SSSD vs Winbind
| Criteria | SSSD | Winbind |
|---|---|---|
| Caching | Built-in, works offline | No caching |
| GPO Support | Yes (via ad_gpo_access_control) | No |
| Performance | High due to caching (3x faster) | Low under heavy load |
| Configuration Flexibility | High (filters, UID/GID mapping) | Medium |
Common Integration Errors
| Error | Solution |
|---|---|
DNS misconfiguration: missing SRV records _ldap._tcp.domain.com |
Configure DNS server, add SRV record |
| Time skew: Kerberos does not tolerate >5 minutes difference | Set up NTP client (chrony or ntpd) |
| Closed ports 88, 389, 636 to DC | Check firewall: nc -zv dc_ip 389 |
Cache ignored: without cache_credentials = True, users cannot log in when DC is unreachable |
Enable cache_credentials = True in SSSD config |
| UID/GID duplication in multi-domain environments | Use ldap_id_mapping with unique ranges |
Ansible for Scaling
Joining 50+ servers to a domain manually is impractical. An Ansible playbook simplifies the task:
---
- name: Join AD domain
hosts: linux_servers
become: yes
tasks:
- name: Install packages
apt:
name: [realmd, sssd, adcli, krb5-user]
state: present
- name: Discover realm
command: realm discover {{ ad_domain }}
changed_when: false
- name: Join domain
expect:
command: realm join --user={{ ad_admin_user }} {{ ad_domain }}
responses:
'Password for .*': "{{ ad_admin_password }}"
no_log: true
- name: Configure sssd
template:
src: sssd.conf.j2
dest: /etc/sssd/sssd.conf
mode: '0600'
notify: restart sssd
Store the AD admin password in Ansible Vault.
What's Included
- Infrastructure audit (DNS, NTP, network access)
- Join a test server to AD
- Optimize SSSD configuration for KPIs (authentication time, caching)
- Configure access policies (GPO, sudo)
- Fault tolerance testing (DC offline, reboots)
- Document configuration and procedures
- Ansible role for mass deployment
- Training for your administrators
Work Process
- Analysis: check network connectivity to DC and DNS.
- Design: select domain scheme, access groups, GPO policies.
- Implementation: install packages, join domain, configure SSSD.
- Testing: user login, sudo, operation with DC unavailable.
- Deployment: Ansible playbook for all servers.
Estimated Timeline
First server and configuration refinement — 1 day. Applying to all servers via Ansible — from 4 hours depending on host count. Pricing is determined individually.
Contact us for a consultation on integrating your Linux servers with AD. We'll help develop a solution tailored to your infrastructure and provide a compatibility guarantee. Request an audit — we'll propose the optimal solution. Our track record: deployed SSSD on 200+ servers, reducing access management time by 90%.







