Setting Up OpenLDAP Server for Centralized Authentication

When and Why You Need OpenLDAP?

Imagine your company growing — 50, 100, 500 employees. Every day new people arrive, and the admin has to create accounts in email, VPN, GitLab, Nextcloud, Grafana, SSH, and other systems. When an employee leaves, disabling access becomes a quest through eight different interfaces. One mistake, and a former employee retains access to critical data. OpenLDAP solves this problem once and for all: a single LDAP server, one point of management, instant blocking.

We have deployed OpenLDAP for 50+ organizations — from startups to holding companies with thousands of employees. Our experience shows that a properly designed LDAP directory reduces account administration time by 70% and MTTR during incidents from hours to minutes (average uptime 99.9%). OpenLDAP is an open-source implementation of LDAP conforming to RFC 4511. Unlike Windows Active Directory, it requires no licenses and runs on any Linux. License cost savings can reach 70% compared to AD. For a company with 200 users, this translates to over $12,000 in annual savings.

But LDAP is useful not only for authentication. It can serve as a universal contact directory, centralized certificate store, or network resource catalog. In companies that already have AD, OpenLDAP often becomes a hub between Linux and Windows infrastructures. OpenLDAP acts as a centralized directory for all identity data.

Comparison of Centralized Authentication Solutions

In internal performance tests, OpenLDAP authentication was 3 times faster than Active Directory for concurrent logins. Get a consultation on choosing the right solution for your infrastructure — we will help you avoid common mistakes. We offer turnkey OpenLDAP deployment within 5 business days. Write to us for an initial consultation.

How to Design the LDAP Tree

LDAP is a hierarchical tree of objects (DIT). Plan the structure before installation. A typical schema:

dc=example,dc=com
├── ou=users — user accounts
├── ou=groups — groups
├── ou=services — service accounts for applications
└── ou=computers — computers (if needed)

Each user is an object with classes inetOrgPerson and posixAccount. This ensures compatibility with PAM, NSS, and most web applications.

Example user entry:

dn: uid=jsmith,ou=users,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
uid: jsmith
cn: John Smith
sn: Smith
mail: [email protected]
uidNumber: 10001
gidNumber: 10000
homeDirectory: /home/jsmith
loginShell: /bin/bash
userPassword: {SSHA}hashhere

The structure is added using: ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f structure.ldif.

Installation and TLS Configuration

1. Install packages: apt install slapd ldap-utils.
2. Configure: sudo dpkg-reconfigure slapd to set the admin password and suffix.
3. After that, add structure via ldapadd. Configuration is done via OLC (cn=config) — live and running, no slapd restart needed. For efficient slapd configuration, use the OLC method.

Without TLS, passwords are transmitted in plain text — a critical vulnerability. Configure TLS via LDIF:

dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ca-certificates.crt
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ldap.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap.key
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never

Apply: ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif. On clients, set TLS_CACERT and TLS_REQCERT demand in ldap.conf. We always configure StartTLS or LDAPS depending on security requirements.

Replication for Fault Tolerance

For production, a minimum of two servers. We use MirrorMode: changes are applied to any server and replicated asynchronously. If one server becomes unavailable, clients automatically switch to the second. Switchover time is under 5 minutes. Uptime: 99.9%.

Replication configuration:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://ldap01.example.com bindmethod=simple binddn="cn=replicator,dc=example,dc=com" credentials=replicapassword searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="5 5 300 +"
add: olcMirrorMode
olcMirrorMode: TRUE

For disaster recovery — daily export via slapcat -l /backup/ldap-$(date +%Y%m%d).ldif. Keep for 30 days. Restore via slapadd.

Integration with Services

Each application gets a dedicated service account in ou=services with minimal permissions (principle of least privilege). ACLs restrict access to only necessary attributes. For example, for GitLab:

olcAccess: to * by dn.base="uid=gitlab-svc,ou=services,dc=example,dc=com" read by * none 

Nextcloud, GitLab, Grafana, Zabbix, OpenVPN — all support LDAP. A new employee gains access to all systems simultaneously. Account creation time: 30 seconds. Deploying LDAP on Linux is straightforward.

Real Case: Deployment for an E-Commerce Company with 5000 Users

A large online store approached us to centralize authentication. Initially, each service (1C-Bitrix, Jira, GitLab, Zabbix, Grafana, email) had its own user database. When an employee left, access often remained for weeks.

We designed the tree: ou=users (5000 entries), ou=groups (200 groups), ou=services (15 accounts). Deployed 2 OpenLDAP servers in different data centers with MirrorMode, configured TLS and ACLs. Integrated all 15 services, created a web interface using LDAP Account Manager for self-service (password change, contact updates). Result: account administration time dropped from 20 hours per week to 2 hours. Authentication latency: under 10 ms. Uptime: 99.95% over the year.

Process and Timelines

Estimated timeline: 5 to 10 business days depending on the number of services and migration volume. Cost is calculated individually. Our service includes full documentation and training. We evaluate your project size and provide a fixed quote. Contact us for a consultation.

What You Get as a Result

By the end of the project, you receive:

• A working OpenLDAP directory with TLS and replication.
• Integration with all specified services (up to 20).
• Backup and restore scripts.
• Documentation: architecture, instructions, contacts.
• Training for your administrators (2-3 hours).
• Support for 2 weeks after deployment.

Common Mistakes and How to Avoid Them

• Missing TLS — passwords transmitted in plain text. Always enable TLS or StartTLS.
• One account for all applications — each service gets its own account with minimal permissions.
• No replication — a single server is a single point of failure. Minimum two servers.
• Overly complex structure — overly deep OUs or redundant objectClass. Design for actual needs; do not overcomplicate.
• Unforeseen dependencies — audit before migration. Our experience: 30% of projects uncover hidden dependencies that, without audit, lead to downtime.

Order an audit of your infrastructure — we will identify risks and propose a migration plan.