LDAP provides centralized authentication by storing user data on a server that clients query during login. 2. Set up an LDAP server like OpenLDAP with proper schema and user entries, ensuring TLS for security. 3. On Linux clients, install SSSD and configure it to connect to the LDAP server using ldap_uri and ldap_search_base in /etc/sssd/sssd.conf. 4. Update /etc/nsswitch.conf to include "sss" for passwd, group, and shadow, then enable PAM integration via pam-auth-update or authselect. 5. Test with getent passwd and SSH login, checking logs and network connectivity if issues arise; ensure correct LDAP attributes, TLS settings, and firewall rules. Once configured, LDAP enables scalable, consistent user management across multiple Linux systems with SSSD caching for reliability.

Setting up centralized authentication on Linux using LDAP is a practical way to manage user access across multiple systems from a single directory. Instead of managing local user accounts on each machine, LDAP allows you to authenticate users against a central server—ideal for environments with many Linux hosts, like offices, labs, or data centers.

Here’s how to set it up in a straightforward, real-world way.

1. Understanding LDAP and Its Role in Central Authentication

LDAP (Lightweight Directory Access Protocol) isn’t an authentication mechanism by itself—it’s a protocol for accessing and managing directory information. When used for authentication, user credentials (like usernames and passwords) are checked against entries stored in an LDAP directory.

In a typical Linux setup:

• The LDAP server (e.g., OpenLDAP or 389 Directory Server) stores user data (UIDs, home directories, shell, etc.) in a hierarchical structure.
• Client machines query the server to authenticate users and retrieve user attributes during login.

This centralization means you can:

• Add, modify, or disable users from one place.
• Enforce consistent UID/GID assignments.
• Reduce the risk of account sprawl.

2. Setting Up the LDAP Server (Brief Overview)

While this guide focuses on client-side configuration, you need a working LDAP server. Here's a quick outline:

• Install OpenLDAP:

  sudo apt install slapd ldap-utils

• Reconfigure it with dpkg-reconfigure slapd to set your domain (e.g., dc=example,dc=com) and admin password.
• Add basic schema (e.g., cosine, nis) for Unix user support.
• Populate it with user entries using LDIF files or tools like ldapadd.

You’ll need at least one user entry with attributes like:

dn: uid=jdoe,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
uid: jdoe
cn: John Doe
uidNumber: 10000
gidNumber: 10000
homeDirectory: /home/jdoe
loginShell: /bin/bash
userPassword: {SSHA}encryptedpassword

Make sure TLS is configured for secure password transmission.

3. Configuring Linux Clients to Use LDAP

Now, make client machines authenticate against the LDAP server using SSSD (System Security Services Daemon), which is the modern, flexible way.

Install Required Packages

On Debian/Ubuntu:

sudo apt install sssd sssd-tools libnss-sss libpam-sss ldap-utils

On RHEL/CentOS/Fedora:

sudo dnf install sssd sssd-ldap openldap-clients

Configure SSSD

Create or edit /etc/sssd/sssd.conf:

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

[domain/example.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_schema = rfc2307
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

# User settings
cache_credentials = true
enumerate = false

? Security Tip: Set ldap_tls_reqcert = demand in production and ensure your CA cert is trusted. Avoid never unless testing.

Then secure the config:

sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf

Update NSS (Name Service Switch)

Edit /etc/nsswitch.conf to include sss for relevant services:

passwd: files sss
group: files sss
shadow: files sss

This tells the system to check LDAP (via SSSD) when looking up users.

Enable PAM for LDAP Authentication

Running pam-auth-update on Debian/Ubuntu will automatically add SSSD to PAM stacks:

sudo pam-auth-update

Ensure "SSSD authentication" is selected.

On RHEL-based systems, use:

sudo authselect select sssd with-mkhomedir

This ensures home directories are created on first login.

4. Testing and Troubleshooting

After restarting SSSD:

sudo systemctl restart sssd

Test that users are visible:

getent passwd jdoe

If this returns the user’s full entry, NSS integration is working.

Try logging in via SSH or console. If it fails:

• Check logs: tail -f /var/log/sssd/*.log
• Verify network connectivity to the LDAP server on port 389 (or 636 for LDAPS).
• Confirm the LDAP search base and user DN structure.
• Test bind manually with ldapsearch:

  ldapsearch -x -H ldap://ldap.example.com -b "dc=example,dc=com" "(uid=jdoe)"

Common issues:

• Incorrect ldap_search_base
• TLS/SSL certificate mismatches
• Missing posixAccount attributes in LDAP
• Firewall blocking port 389/636

Final Notes

Once working, you can scale this to hundreds of machines. Combine it with NFS for shared home directories, and you’ve got a full centralized login environment.

SSSD also supports caching, so users can log in even if the LDAP server is temporarily unreachable.

It’s not magic—but with careful setup, LDAP authentication is reliable, secure, and far easier to manage than local accounts.

Basically: get the server right, configure SSSD cleanly, and test step by step.

The above is the detailed content of A Guide to Centralized Authentication on Linux with LDAP. For more information, please follow other related articles on the PHP Chinese website!