You upgraded a workstation and the login screen rejects your credentials
You joined an organization that manages users in a central directory, or you migrated a Fedora machine to your company's LDAP server. You type your username and password at the login screen, and the system spins. Or worse, it creates a local user with the same name, shadowing the remote account and locking you out of your real profile. You need Fedora to trust the directory, cache credentials for offline work, and create home directories automatically without manual intervention.
What's actually happening
Fedora does not query LDAP directly. It uses SSSD (System Security Services Daemon) as the middleman. SSSD runs locally and handles all communication with the directory. When you log in, the desktop asks SSSD, "Who is this user?" SSSD checks its local cache first. If the cache has the data, it returns the result instantly. If the cache is empty or stale, SSSD queries the LDAP server, stores the answer, and hands the result back to the desktop.
This architecture gives you three benefits. Offline access works because SSSD caches credentials. Performance improves because lookups hit the local cache instead of the network. Security tightens because SSSD manages Kerberos tickets and certificate validation in one place. Without SSSD, every login requires a network round-trip, and your laptop becomes unusable when you disconnect from Wi-Fi.
Install the required packages
Install the core components. SSSD handles the directory communication. authselect configures the system's authentication stack. oddjob-mkhomedir creates home directories on first login.
sudo dnf install -y sssd sssd-ldap authselect oddjob-mkhomedir
# sssd-ldap provides the LDAP provider plugin for SSSD
# authselect manages PAM and NSS configuration centrally
# oddjob-mkhomedir creates user home directories on first login
Configure SSSD
Create the SSSD configuration file. This file defines the domain, the provider, and how SSSD connects to your LDAP server. Edit /etc/sssd/sssd.conf. Never edit files in /usr/lib/. Configuration files in /etc/ are user-modified and survive package updates. Files in /usr/lib/ ship with packages and get overwritten on upgrade.
[sssd]
services = nss, pam
# nss provides user and group lookups for the system
# pam handles authentication and session management
domains = LDAP
[domain/LDAP]
id_provider = ldap
# tells SSSD to fetch identity information from LDAP
auth_provider = ldap
# tells SSSD to verify passwords against LDAP
ldap_uri = ldap://ldap.example.com
# replace with your actual LDAP server address
ldap_search_base = dc=example,dc=com
# base DN where user and group objects reside
ldap_tls_reqcert = demand
# requires a valid TLS certificate from the server
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
# path to the CA bundle that signed the LDAP server cert
cache_credentials = true
# allows login when the LDAP server is unreachable
enumerate = false
# lazy enumeration improves performance on large directories
Lock down the configuration file. SSSD refuses to start if the config is readable by other users. This prevents credential leakage and ensures only root can modify the connection parameters.
sudo chmod 600 /etc/sssd/sssd.conf
# restricts access to root only to prevent credential leakage
Restart SSSD after every config change. The daemon does not reload automatically.
Apply the authselect profile
Apply the authentication profile. authselect updates PAM and NSS files to route requests through SSSD. Fedora uses authselect instead of manual PAM edits. Manual edits to /etc/pam.d/system-auth drift and get lost. authselect keeps the stack consistent and warns you when you deviate.
sudo authselect select sssd with-mkhomedir --force
# sssd profile enables SSSD for authentication and lookups
# with-mkhomedir adds the home directory creation feature
# --force overwrites existing customizations if needed
Check the current profile to verify the state.
authselect current
# displays the active profile and any enabled features
Start and enable SSSD
Start the services and enable them for boot. SSSD must run for authentication to work. oddjobd runs the home directory creation helper in the background.
sudo systemctl enable --now sssd
# starts SSSD immediately and ensures it runs after reboot
sudo systemctl enable --now oddjobd
# oddjobd runs the mkhomedir helper in the background
Verify the connection
Check if the system can resolve a user from the directory. Use getent to query NSS. If the user exists in LDAP and SSSD is configured correctly, you will see the full passwd entry.
id ldapuser@example.com
# displays UID, GID, and groups for the LDAP user
getent passwd ldapuser
# queries NSS to retrieve the full passwd entry
Test authentication without logging out of your current session. pamtester simulates a login attempt using the PAM stack. This confirms that password verification works before you reboot.
sudo pamtester login ldapuser authenticate
# simulates a login attempt using the PAM stack
# prompts for the LDAP password and reports success or failure
Run getent before you reboot. If the user doesn't show up here, the login screen won't find them either.
Common pitfalls and error patterns
If getent returns nothing, check the logs. SSSD writes detailed errors to the journal. Use journalctl -xeu sSSD to see the unit logs with explanatory text. The x flag adds context, and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
sudo journalctl -xeu sssd
# -x adds explanatory text to log entries
# -e jumps to the end of the journal
# -u filters for the sssd unit only
TLS certificate failures are the most common blocker. If your LDAP server uses a self-signed certificate or a private CA, SSSD rejects the connection unless you provide the correct CA bundle. You will see this error in the journal:
sssd[ldap_child]: TLS certificate verification failed:
error 20 at 0 depth lookup: unable to get local issuer certificate
The error means SSSD cannot verify the server's certificate chain. Update ldap_tls_cacert in sssd.conf to point to the CA file that signed the LDAP server certificate. If your CA is not in /etc/pki/tls/certs/ca-bundle.crt, copy the CA certificate to /etc/pki/ca-trust/source/anchors/ and run update-ca-trust extract to merge it into the system bundle.
Firewall rules also block connections. Ensure the LDAP port is accessible. Port 389 is standard LDAP. Port 636 is LDAPS. If you use ldap:// with StartTLS, port 389 must be open. If you use ldaps://, port 636 must be open. Test connectivity with ldapsearch:
ldapsearch -x -H ldap://ldap.example.com -b dc=example,dc=com '(uid=testuser)'
# performs a raw LDAP bind and search to verify network access
# -x uses simple bind instead of SASL
# -b sets the search base DN
Enable verbose logging to trace the exact failure point. Add debug_level = 6 to the [domain/LDAP] section in sssd.conf. Level 6 provides detailed connection and protocol logs. Restart SSSD after adding the debug level.
# Add to [domain/LDAP] in sssd.conf
debug_level = 6
# level 6 provides detailed connection and protocol logs
Read the journal before you guess. The error message usually names the missing certificate or the blocked port.
When to use this vs alternatives
Use SSSD with LDAP when you need centralized identity management across multiple machines. Use SSSD with Active Directory when your directory runs on Windows Server and you need Kerberos integration. Use local authentication when the machine is a standalone server with no directory access. Use authselect profiles when you want to switch authentication backends without editing PAM files manually. Stay on sssd-ldap when your directory is OpenLDAP or a non-AD LDAP server.