Setting up centralized authentication with LDAP on RHEL
Centralising credentials gives RHEL hosts one identity source, consistent groups and rapid account removal. It also creates a shared failure point: weak trust settings or an unavailable directory can break login and sudo access across multiple systems.
This guide uses 389 Directory Server over LDAPS, with RHEL 9’s authselect and SSSD on clients. Apply the design to CentOS Stream or derivative rebuilds only after checking package, service and default differences.
Define the trust boundary and naming
Use a stable DNS name such as id1.example.com.au, a suffix such as dc=example,dc=com,dc=au, and separate branches for people, groups and services. Assign explicit ownership for directory operation, certificates, break-glass access and backup recovery. Record base and bind DNs in configuration management, but never their passwords.
Australian teams may support staff across Sydney, Melbourne, Brisbane and Perth, from city offices, suburban sites or homes. Perth is normally two hours behind the eastern states, affecting maintenance and account-expiry windows. Many local estates combine RHEL with VMware, Microsoft Active Directory and hosted directories, so settle any AD synchronisation requirement before schema work.
For organisations covered by the Privacy Act 1988, account records and logs can contain personal information. The Australian Privacy Principles govern their use, while the Notifiable Data Breaches scheme may apply after an eligible breach. Define purpose, access and retention rather than retaining trails indefinitely. Pin commands to a RHEL stream; RHEL administration notes can support the wider maintenance runbook.
Install and protect the directory
On RHEL 9, install 389 Directory Server and the OpenLDAP utilities. Build the instance file from the supplied template, set the DNS name, suffix, instance_name=corp and production TLS details, then start the service locally. Keep Directory Manager and bind passwords out of command history and shared scripts.
sudo dnf install -y 389-ds-base openldap-clients
sudo dscreate from-file /root/dir-instance.inf
sudo systemctl enable --now dirsrv@corp.service
Install the CA certificate under /etc/pki/ca-trust/source/anchors/ and expose only port 636. Never disable certificate-name checks or use plaintext LDAP. Replace any temporary self-signed certificate before opening the firewall, then remove the protected instance input.
sudo update-ca-trust
sudo firewall-cmd --permanent --add-service=ldaps
sudo firewall-cmd --reload
ldapsearch -x -H ldaps://id1.example.com.au -b "" -s base namingContexts
Choose the directory according to the identity authority that already owns the environment:
| Directory | Best fit | RHEL integration | Main consideration |
|---|---|---|---|
| 389 Directory Server | Linux-first LDAP with selective Kerberos | SSSD with LDAP or Kerberos | Replication and AD synchronisation need separate design |
| FreeIPA | Combined identity, Kerberos, CA and DNS | ipa-client-install |
More services and upgrade dependencies |
| Microsoft Active Directory | Existing Microsoft-centred identity | SSSD with the AD provider | Trust paths, certificates and group synchronisation require testing |
Store identities and groups safely
Create a restricted service bind DN before adding users. Its ACL should permit only the searches SSSD needs, and its generated password should be rotated independently of human credentials. Give service identities no shell access and review their privileges regularly.
Add people and authorisation groups through reviewed LDIF rather than general-purpose administration interfaces:
dn: uid=amorgan,ou=People,dc=example,dc=com,dc=au
objectClass: inetOrgPerson
uid: amorgan
cn: Alex Morgan
sn: Morgan
mail: alex.morgan@example.com.au
dn: cn=linux-admins,ou=Groups,dc=example,dc=com,dc=au
objectClass: groupOfNames
member: uid=amorgan,ou=People,dc=example,dc=com,dc=au
Keep authorisation data separate from job titles, and restrict membership of break-glass groups. Set the new user’s password through the secure administrative channel, then verify the LDAPS bind; successful searches alone do not prove that authentication works.
sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /root/accounts.ldif
sudo ldappasswd -Y EXTERNAL -H ldapi:/// \
"uid=amorgan,ou=People,dc=example,dc=com,dc=au"
ldapwhoami -x -H ldaps://id1.example.com.au \
-D "uid=amorgan,ou=People,dc=example,dc=com,dc=au" -W
Connect RHEL and application users
Install SSSD, select the sssd authselect profile and define an LDAP domain. This configuration uses a dedicated bind identity, disables broad enumeration and keeps credential caching off by default.
sudo dnf install -y sssd sssd-tools
sudo authselect select sssd
sudo authselect apply
[sssd]
services = nss, pam
domains = example
[domain/example]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://id1.example.com.au
base_dn = dc=example,dc=com,dc=au
ldap_search_base = ou=People,dc=example,dc=com,dc=au
ldap_search_group = ou=Groups,dc=example,dc=com,dc=au
ldap_default_bind_dn = uid=svc-bind,ou=Services,dc=example,dc=com,dc=au
ldap_default_authtok = REPLACE_WITH_SERVICE_SECRET
cache_credentials = false
enumerate = false
Protect /etc/sssd/sssd.conf with mode 0600, or connect SSSD to an approved secrets provider. Insert the service secret without committing it to version control, then check NSS, group and PAM resolution. If staff need home directories, provide them through the approved file service rather than storing personal files in LDAP.
sudo chmod 600 /etc/sssd/sssd.conf
sudo sssctl config-check
sudo systemctl enable --now sssd
sudo sssctl user-checks amorgan
getent passwd amorgan
getent group linux-admins
Android apps should not bind directly to LDAP. Application code can use Retrofit network calls to reach an HTTPS API, while an approved identity provider or Android system account handles authentication. The directory bind secret must never ship inside an APK. This separation suits Australian on-call staff who commonly use Android phones for MFA while travelling.
Maintain authentication through failures
Monitor daemon state, replication, disk capacity, certificate expiry, clock skew, failed-bind rates and lockouts. Collect focused logs from dirsrv and sss_be, restrict access and alert on sudden group changes. Account reviews and certificate checks belong in versioned systemd services driven by timers; scheduled Linux tasks explains how timers and cron jobs fit together.
Back up the directory database, configuration, ACLs and certificates, then restore them into an isolated RHEL environment on a schedule. A backup that has never been restored is only an assumption. Store recovery credentials separately, test failover and maintain audited break-glass accounts outside ordinary access paths.
For branch sites and laptops, decide whether credential caching is acceptable and for how long; a failed WAN link should not silently create stale access. Rehearse failures involving certificates, replicas, service accounts and mistaken group grants. One accountable directory owner, TLS on every connection, least-privilege bind accounts, tested restores and a verified SSSD path keep authentication predictable when routine administration becomes an incident.