Learn Kerberos - Linux Clients with Active Directory

#Introduction

In episode 18 you understood that AD runs Kerberos as its default authentication: the domain is a realm, the DC is a KDC, and krbtgt is the master key. The question now: how do Linux servers get into that same "kingdom" — so that the same user can log into Windows and Linux without two separate passwords?

Episode 19 answers that. Joining Linux to AD means three things at once: creating a computer object in AD, configuring the Kerberos client (krb5) to know the AD realm, and installing SSSD as the bridge between PAM/NSS and AD's Kerberos + LDAP. The result is Single Sign-On: first login with an AD password, and from then on every GSSAPI-supporting service immediately trusts your Kerberos tickets.

#Main Discussion

#Two Main Paths: SSSD vs Winbind

In general, there are two approaches used in the real world:

• SSSD (System Security Services Daemon) — modern, recommended for RHEL/Rocky/Fedora and Ubuntu. One daemon handles Kerberos authentication, fetching users/groups from AD LDAP, caching, and offline access.
• Samba Winbind — the classic approach from the Samba ecosystem; still used in environments already married to Samba for file sharing.

This series focuses on SSSD because it's more relevant for modern Linux workloads, especially servers that only need authentication and identity without sharing SMB files.

#Prerequisites: DNS and Time

Before touching realm join, there are two prerequisites just as crucial as those in the MIT Kerberos lab from episodes 4-6:

1. DNS must recognize the AD domain. Linux must resolve the name example.com and find the DC via the _kerberos._tcp.dc._msdcs.example.com SRV record. AD depends heavily on DNS — without it, the join will almost certainly fail.
2. Time must be synchronized with the DC. AD's clock skew tolerance is the same as MIT Kerberos: 5 minutes. Point chronyd at the PDC emulator or a time source shared with the domain.

Verify both before proceeding:

dig +short _kerberos._tcp.dc._msdcs.example.com SRV
chronyc tracking
timedatectl status

If chronyc tracking shows a difference of more than 5 minutes from the DC, stop and fix the time first — you'll only face KDC_ERR_PREAUTH_FAILED or Clock skew too great later.

#realm join: One Command, Much Work

The core packages needed: realmd, adcli, sssd, and oddjob-mkhomedir (to create home directories automatically). On RHEL/Rocky:

sudo dnf install realmd adcli sssd oddjob-mkhomedir -y

Then join the domain with an account that has permission to create computer objects (usually administrator or a designated service account):

sudo realm join EXAMPLE.COM -U administrator

realm join does many things at once behind the scenes: adcli connects to the DC, creates a computer object in AD, writes the krb5.conf configuration, generates /etc/krb5.keytab for the host/<fqdn> host principal, and prepares the SSSD configuration file at /etc/sssd/sssd.conf. After success, verify the status:

realm list

The realm list output shows the joined domain, realm, and generated configuration. If you see login-formats: %U@example.com and login-policy: allow-realm-logins, the machine is officially a domain citizen.

#Anatomy of the SSSD Configuration

The /etc/sssd/sssd.conf file is the brain of authentication. The [sssd] section registers the domain and services; the [domain/example.com] section manages how authentication and identity are fetched. An example configuration produced by realm join, already adjusted:

/etc/sssd/sssd.conf

[sssd]
domains = example.com
services = nss, pam
config_file_version = 2
 
[domain/example.com]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
id_provider = ad
auth_provider = ad
access_provider = ad
krb5_server = dc01.example.com
ldap_uri = ldap://dc01.example.com
cache_credentials = True
default_shell = /bin/bash
use_fully_qualified_names = False

Important points you need to understand:

• auth_provider = ad means SSSD authenticates via Kerberos against AD — at login, SSSD internally runs kinit with the user's credentials.
• krb5_server points to the DC; it can hold several space-separated names for failover.
• ldap_uri is used to fetch users/groups from AD over LDAP (e.g. for UID/GID resolution).
• cache_credentials = True allows offline login when the DC is unreachable — useful but it means password hashes are stored in the local cache, so manage it wisely.

#authselect: Wiring Up PAM and NSS

On the RHEL family, realm join automatically picks the sssd profile for authselect — the mechanism managing /etc/pam.d and /etc/nsswitch.conf. You can check and force it:

sudo authselect select sssd with-mkhomedir
authselect current

The sssd profile connects PAM to the pam_sss module (which talks to SSSD), and with-mkhomedir ensures a home directory is created automatically at first login. On Ubuntu/Debian, the same role is held by pam-auth-update, by checking the SSSD module.

#The Login Flow That Actually Happens

When a user types a password at the Linux login prompt, the following sequence runs:

1. PAM calls pam_sss, which forwards the credentials to SSSD.
2. SSSD performs an AS_REQ to the DC — the password becomes a key, is sent as preauth, and the DC replies with a TGT.
3. The TGT is stored in SSSD's internal cache (not an ordinary file cache), and the user is considered successfully authenticated.
4. NSS (via pam_sss/sssd_nss) maps the user to a UID/GID from AD LDAP.
5. When the user needs to access GSSAPI-supporting services (SSH, NFS, SMB), SSSD uses that TGT to fetch service tickets — exactly the episode 3 flow.

For the machine itself, the host keytab /etc/krb5.keytab stores the key of the host/linux01.example.com@EXAMPLE.COM host principal. This keytab is used for machine authentication — for example by cron, by applications running as root, or when the system needs to prove its identity to AD without user interaction.

sudo klist -kt /etc/krb5.keytab
sudo kinit -k -t /etc/krb5.keytab host/linux01.example.com

kinit -k authenticates without a password using the key in the keytab — a quick way to confirm the AD machine account and its keytab are healthy.

#Best Practices for Linux + AD

• Never log in as root. Make every login use a domain account with limited privileges, and use sudo with rules based on AD groups (%domain\admins).
• Keep password and encryption policy strong. Make sure the AD GPO doesn't allow RC4 for Kerberos connections from Linux (details in episode 21).
• Keep time synchronized continuously. AD treats a drifting clock as a threat; correct chronyd prevents confusing errors.
• Monitor SSSD logs. All Kerberos conversations are recorded in /var/log/sssd/ and the journal — journalctl -u sssd is the first door when authentication misbehaves.
• Treat the keytab as a secret. /etc/krb5.keytab is equivalent to the machine's password; make sure only root can read it.

#Initial Troubleshooting

When login fails, don't guess immediately. Run a sequential check:

realm list
authselect current
sssctl domain-status example.com
sssctl cache-expire
journalctl -u sssd -n 50 --no-pager

If sssctl domain-status example.com shows a connection error to the DC, re-check DNS and port 88/tcp. If the error talks about a principal or encryption, compare the enctypes supported by Linux and AD — a topic we'll go deep into in episode 21. For deeper problems, KRB5_TRACE on SSSD (via sssctl debug-level) will show every Kerberos step SSSD performs — the same tool we'll use heavily in episode 23.

#Conclusion

In episode 19 you made Linux servers full citizens of an AD domain. We covered the SSSD vs Winbind choice, the DNS and time prerequisites, the realm join that automatically creates the computer object and host keytab, the anatomy of the SSSD configuration ([domain/example.com], krb5_server, ldap_uri), the authselect sssd profile, the login flow via Kerberos, and best practices plus initial troubleshooting.

Key points to take with you:

• Joining AD = creating a computer object + configuring krb5 + SSSD as the PAM/NSS bridge.
• DNS SRV and a synchronized clock are absolute prerequisites before a join.
• SSSD runs an internal kinit with the user's password; the TGT is cached for SSO.
• The host keytab at /etc/krb5.keytab authenticates the machine without user interaction.
• realm list, authselect current, and sssctl domain-status are the first diagnostic tools.

In the next episode, episode 20, we go up one level of abstraction: SPN Management & Delegation — managing service identity in AD, rotating keytabs, and dissecting delegation (including the risk of its abuse). See you there!