You upgraded the workstation and the login screen ignores domain credentials
You just deployed a new Fedora machine for a developer, and the IT team expects them to log in with their corporate Active Directory account. You run the join command, the terminal hangs for ten seconds, and the login screen refuses to recognize the domain user. The machine has an IP address and can ping the domain controller, but the identity layer is completely silent. You are staring at a local account prompt when you need enterprise authentication.
What is actually happening under the hood
Active Directory is not a simple database. It is a Kerberos realm, a DNS zone, and a certificate authority operating as a single unit. Fedora does not speak Active Directory natively. It relies on SSSD to translate directory queries into local Linux authentication requests. The realmd service acts as the negotiator. It discovers the domain, requests a Kerberos ticket, creates the computer account in AD, and writes the configuration files that tell SSSD where to look for users and groups.
Think of the authentication flow like a corporate badge system. The badge reader is SSSD. The security guard who validates the badge against the central database is Kerberos. The phone call you make to register the badge is realmd. If the clock on the badge reader is off by five minutes, the guard rejects it. If the phone line drops during registration, the badge never gets printed. If the reader is configured to look at the wrong database, it shows an error even though the badge is valid.
Kerberos is strictly time-sensitive. The protocol rejects any authentication ticket that is older than five minutes by default. DNS must resolve both the domain name and the _kerberos._tcp service records. If either fails, the join process aborts before it ever touches the configuration files. SSSD runs as a background daemon and maintains a local cache of user credentials. This cache allows users to log in when the domain controller is unreachable, but it requires explicit configuration to enable offline access. The realmd tool handles the initial handshake and writes the baseline configuration. It does not manage advanced caching or complex group filters. You must understand the handoff between DNS, Kerberos, and SSSD to troubleshoot failures effectively.
Check the authentication pipeline before blaming the domain controller. Run journalctl first. Read the actual error before guessing.
Prerequisites and package installation
Check the system clock first. Fedora ships with chrony enabled by default, but a fresh install or a virtual machine that was paused for days might have drifted. Verify synchronization with a quick status check.
chronyc tracking
# Shows the reference clock and system time offset
# If the offset exceeds 500 seconds, force a sync with chronyc makestep
# Kerberos will reject tickets if the drift exceeds five minutes
Next, install the identity stack. The package list covers the discovery tool, the daemon, the Kerberos client, and the AD integration libraries.
sudo dnf install realmd sssd sssd-tools adcli krb5-workstation samba-common-tools
# realmd handles domain discovery and join operations
# sssd provides the local authentication daemon and cache
# adcli performs the actual AD computer account creation
# krb5-workstation supplies the Kerberos ticket cache utilities
sudo systemctl enable --now sssd
# Starts the daemon immediately and ensures it survives reboots
# systemd creates the necessary symlinks in /etc/systemd/system
Fedora's default firewall usually allows Kerberos traffic out of the box, but explicit rules prevent runtime configuration drift. Add the services and reload the firewall to apply them to the active session.
sudo firewall-cmd --permanent --add-service=kerberos
sudo firewall-cmd --permanent --add-service=kerberos-admin
sudo firewall-cmd --reload
# Reloads the runtime configuration to match the persistent rules
# Without reload, the active firewall ignores the new service definitions
Discovering and joining the domain
Run the discovery command to verify network connectivity and retrieve the domain metadata. Replace example.com with your actual Active Directory domain.
realm discover example.com
# Queries DNS for SRV records and verifies Kerberos realm availability
# Returns the domain name, type, and required packages if missing
# Fails immediately if DNS cannot resolve the _kerberos._tcp record
If discovery succeeds, join the domain using a domain administrator account. The --user flag specifies the credentials, and the command automatically handles the machine password generation.
sudo realm join --user=Administrator example.com
# Requests a Kerberos ticket for the admin account
# Creates the computer object in the AD domain
# Writes the initial SSSD and NSSwitch configuration files
# Prompts for the password and exits silently on success
The command will prompt for the administrator password. If it completes without output, it succeeded. realmd operates silently on success and prints errors to stderr on failure. The tool modifies /etc/nsswitch.conf and /etc/pam.d/system-auth to route authentication requests through SSSD. It also generates /etc/sssd/sssd.conf with the domain name and default provider settings. Do not manually edit the SSSD configuration while realmd is managing the domain. The tool will overwrite custom changes during the next join or leave operation. If you need advanced tuning, use realm leave first, edit the files manually, then rejoin with the --install flag to skip automatic configuration.
Trust the package manager. Manual file edits drift, snapshots stay.
Verify the integration
Check the domain status first. The output should show the realm as joined and list the configured login settings.
realm list
# Displays the domain name, type, and SSSD configuration status
# Confirms that NSSwitch and PAM are pointing to the identity provider
# Shows the configured login format and required packages
Test user resolution without triggering a full login. The id command queries SSSD directly and returns the UID, GID, and group memberships.
id jdoe@example.com
# Resolves the domain user through SSSD
# Returns uid, gid, and groups if the cache is populated
# Fails with no output if SSSD cannot reach the domain controller
Run getent passwd jdoe@example.com to verify that the Name Service Switch is routing the query correctly. If both commands return valid output, the authentication layer is functional. Reboot the machine and test the graphical login screen. The display manager will now accept domain credentials. If you need offline login support, enable credential caching in the SSSD configuration and run sss_cache -E to clear stale entries.
Reboot before you debug. Half the time the symptom is gone.
Common pitfalls and what the error looks like
Time drift is the most frequent cause of silent failures. If the system clock is out of sync, Kerberos returns KRB_AP_ERR_TKT_NYV or KRB_AP_ERR_SKEW. The terminal prints Failed to join domain: Cannot find KDC for requested realm. Fix the clock before retrying the join.
DNS misconfiguration breaks discovery entirely. If realm discover returns No such domain, your resolver cannot find the _kerberos._tcp.example.com SRV record. Check /etc/resolv.conf or your NetworkManager connection settings. Point the DNS servers to the domain controllers, not a public resolver. Public DNS servers do not host internal SRV records.
SELinux denials appear when SSSD tries to access files outside its allowed context. Fedora enforces strict policies by default. Check the audit log for one-line summaries before changing the enforcement mode.
journalctl -t setroubleshoot | tail -n 20
# Filters the journal for SELinux denial summaries
# Shows the denied process, target file, and suggested fix
# Use sealert -a /var/log/audit/audit.log for detailed policy analysis
Setting SELinux to permissive mode bypasses the checks but leaves the system exposed. Only use it for temporary debugging. Restore enforcing mode immediately after identifying the policy gap.
sudo setenforce 0
# Temporarily disables SELinux enforcement for testing
sudo setenforce 1
# Restores strict enforcement after debugging
# Always verify with getenforce before deploying to production
Configuration file permissions cause SSSD to refuse startup. The daemon requires /etc/sssd/sssd.conf to be readable only by root. If the permissions drift to 644, the service fails silently and drops to a fallback state.
sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf
# Restricts access to root only to prevent credential leakage
# Ensures the daemon can read the configuration on boot
# SSSD will refuse to start if the file is world-readable
NetworkManager interface renaming breaks Kerberos resolution. If your system uses predictable network interface names like enp3s0 but the domain controller expects eth0, DNS queries fail. Check the interface names with ip link and update your connection profiles accordingly. Fedora uses systemd udev rules for predictable naming by default. Stick to the generated names to avoid configuration drift.
Run journalctl -xeu sssd.service first. Read the actual error before guessing.
When to use this approach versus alternatives
Use realmd when you need a quick, automated integration with an existing Active Directory environment. Use manual SSSD configuration when your organization requires custom LDAP filters, complex group mappings, or offline credential caching. Use FreeIPA when you are building a Linux-native identity provider that can trust AD or operate independently. Use SSH key authentication when you are managing servers and do not need graphical desktop login integration. Use LDAP directly when your infrastructure predates Kerberos and you cannot upgrade the directory services.