Linux SSSD Active Directory Join and Troubleshooting

Joining a Linux server to Active Directory is a two-command job; keeping logins working afterwards is where the work is. SSSD and realmd hide the Kerberos and LDAP plumbing, which also means that when something breaks the failure usually surfaces as a vague "permission denied" or a user that simply does not resolve. This guide covers a clean join with realm, the parts of sssd.conf that actually matter, and the diagnostic path for the failures that show up days later.

Discover and join

# realm discover ad1.example.com
ad1.example.com
  type: kerberos
  realm-name: AD1.EXAMPLE.COM
  domain-name: ad1.example.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: adcli
  required-package: samba-common-bin

# realm join -v ad1.example.com
Password for Administrator:
 * Calculated computer account name from fqdn: AD-CLIENT
 * Using keytab: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/ad-client.ad1.example.com@AD1.EXAMPLE.COM: FILE:/etc/krb5.keytab
 * Successfully enrolled machine in realm

realm discover resolving successfully proves the host can query the AD SRV records - the single most common cause of failed joins. If discovery returns nothing, fix DNS before touching SSSD: the client must use the AD DNS servers for the domain, and NetworkManager overwriting /etc/resolv.conf with DHCP-provided servers is a classic source of "it worked yesterday" breakage.

The configuration that matters

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

[domain/ad1.example.com]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD1.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = ad1.example.com
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

Four lines decide most behaviour. id_provider = ad uses the AD provider with Kerberos, LDAP and ID mapping integrated. access_provider = ad lets AD determine who may log in - if it is set to simple (which is what realm permit configures), your carefully populated AD groups are ignored. use_fully_qualified_names = True requires user@domain style logins, which surprises people who expect short names. cache_credentials allows logins when the DC is unreachable - convenient on laptops, but it means revoked accounts can still authenticate against a cached credential.

Verification

# id user@ad1.example.com
# getent passwd user@ad1.example.com
# sssctl domain-status ad1.example.com
# sssctl user-checks user@ad1.example.com
# systemctl status sssd

sssctl user-checks is the fastest way to see which stage fails: resolution, authentication or authorisation.

Troubleshooting by symptom

• User resolves but cannot log in: almost always the access provider or an AD group restriction. Test with sssctl user-checks and check krb5_realm case (realms are upper case).
• Login fails after a DC change or password reset: clear the SSSD caches (sss_cache -E, then restart) - stale cached credentials are a frequent culprit.
• Everything fails simultaneously on one host: clock skew. Kerberos rejects tickets when the client and DC clocks differ by more than a few minutes, so check time synchronisation before blaming SSSD.
• Account exists but no home directory or shell: set fallback_homedir and a sane default_shell, and enable pam_mkhomedir or oddjob so the directory is created at first login.
• Permitted users suddenly can see other accounts: an unqualified realm permit --all in someone's script. Keep authorisation explicit.
• Debugging: add debug_level = 0x3ff0 under the domain section, restart SSSD and read /var/log/sssd/sssd_<domain>.log. Raise it only for the investigation - full debug logging is chatty and slow.
• Computer account problems: the machine password rotation can fail behind a broken network path; adcli update or a re-join with realm join --client-name resolves duplicate computer accounts left behind by re-imaging.

Related: systemd-resolved DNS troubleshooting, Linux server operations guide, and ISC DHCP server configuration.

原文链接：https://ubuntu.com/server/docs/how-to/sssd/with-active-directory/