How We Scaled Server Authentication with OpenLDAP: A Real‑World Operations Journey

Preface

The article is divided into four parts: selection, requirement analysis, implementation, and evolution, describing how a vehicle‑networking company built a unified identity authentication platform.

1. Selection

It started with an overloaded legacy server in a 400‑node cluster. The inability to log in due to unknown passwords highlighted the need for a centralized authentication system.

2. Initial Requirement

When using only SSH/SCP, each employee had a single password for all environments. The requirement was a simple, password‑based authentication that did not expose passwords to super‑admins.

Various solutions were considered: managing /etc/shadow via a configuration tool, Kerberos, OpenLDAP, and commercial bastion hosts. Cost considerations favored open‑source; after consulting an expert, OpenLDAP was chosen.

Price: OpenLDAP can run on a single half‑server for under 20 k RMB, while a commercial bastion costs around 200 k RMB.

Architecture: CS/BS model.

Authorization: Commercial products offer richer audit features, but OpenLDAP can record operations via scripts.

3. Implementing OpenLDAP

OpenLDAP is a lightweight directory access protocol suitable for read‑heavy, write‑light scenarios. Clients install the OpenLDAP client, which integrates with PAM and NSS to authenticate users against the LDAP server.

When a user logs in, the PAM module checks local passwd/shadow, then forwards credentials to the LDAP server; a successful match allows normal login.

OpenLDAP stores user IDs, passwords, and permission definitions. The Sudoers schema is used for privilege management, enabling group‑based rights across all servers.

Installation uses

authconfig-tui

to enable LDAP, configure URI and Base, and modify key configuration files:

/etc/ldap.conf

/etc/nsswitch.conf

/etc/sysconfig/authconfig

/etc/pam.d/system-auth

4. Evolution

4.1 Fine‑grained Management

Roles are defined as system administrator, application ops, network admin, observer (read‑only), and personal.

4.2 Distributed Management

With ten data centers, a distributed LDAP deployment avoids a single point of failure; each site authenticates locally while syncing changes to a master node.

4.3 Security Enhancements

TLS certificates (prefer wildcard) protect LDAP traffic; PAM limits login attempts (e.g., lock after five failures for 600 seconds).

4.4 Service Decoupling

To reduce LDAP load from frequent permission checks, the

nss_initgroups_ignoreusers

option is added to

/etc/ldap.conf

so certain users are authenticated locally.

4.5 Host‑based Account Restrictions

The

pam_check_host_attr

parameter restricts users to specific servers.

4.6 Efficient Internal Management

A custom web portal stores account change requests and applies them to LDAP via scheduled jobs.

4.7 System Development Stages

Account/password management.

Architecture adjustments.

Security hardening and brute‑force protection.

Efficient internal management.