Active Directory Integration for Linux Servers with SSSD and Realmd

Every new employee means manual hassle with local accounts, scattered passwords, and configuring access to shared resources. We integrate Linux servers into Active Directory using SSSD and Realmd turnkey—from audit to deployment, ensuring centralized authentication and ongoing support.

Our competencies:

Frequently Asked Questions

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1359
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1330
  • B2B Advance company logo design
    B2B Advance company logo design
    776
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1077
  • AIDER company logo development
    AIDER company logo development
    1022
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1113

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 list

After 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 needed

use_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] && klist

A 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

  1. Analysis: check network connectivity to DC and DNS.
  2. Design: select domain scheme, access groups, GPO policies.
  3. Implementation: install packages, join domain, configure SSSD.
  4. Testing: user login, sudo, operation with DC unavailable.
  5. 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%.