OpenLDAP - Hardened LDAP Directory Server

What is OpenLDAP

OpenLDAP is the reference open-source implementation of the Lightweight Directory Access Protocol. Its directory server, slapd, stores users, groups, hosts and application entries in a hierarchical tree and answers LDAP queries over the network - the same protocol Linux hosts, VPN concentrators, mail servers, CI systems, wikis and hundreds of off-the-shelf applications already speak for authentication and identity lookup. Storage is LMDB, a memory-mapped transactional store built into the server, so there is no separate database process to run or tune. Configuration is live: the whole server is described by entries under cn=config and changed with ordinary LDAP operations, with no restart and no config file to edit.

Why self-host OpenLDAP

A directory is the authentication source for everything behind it, which makes it the one system organisations are least willing to place outside their own control. Self-hosting keeps every credential, group membership and personnel attribute inside your own network boundary and your own jurisdiction, which matters directly for GDPR and for sector rules on personal data. It also avoids per-seat identity pricing that scales with headcount rather than usage, and avoids a lock-in that is unusually painful to unwind: schema and DNs propagate into every application that binds to them.

What this VM image adds

Security hardening:

• Anonymous binds refused - the directory does not answer to unauthenticated clients at all, and every operation requires an identity
• No cleartext passwords on the wire - a security strength floor of 128 is enforced, so port 389 works only after StartTLS and a password bind over an unprotected connection is rejected by the server
• Salted password hashing - SSHA, the scheme the OpenLDAP project documents as the most secure it supports, applied to every password set through the directory
• Password hashes readable by nobody - the access rules grant users the right to change their own password without the right to read it, so a compromised session cannot walk away with a hash to crack offline
• Per-instance TLS - the certificate and private key are generated on your own instance at first boot and never shipped inside the image
• Per-instance administrator password - generated at first boot, written to a root-only file; no shared or default credential exists in the image
• CVE scan - every image is scanned for vulnerabilities with Trivy before release
• UFW firewall - only 22, 389 and 636 open, everything else blocked
• fail2ban - SSH brute-force protection
• AppArmor - mandatory access control

OS hardening (CIS Level 1):

• CIS Level 1 hardened - CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• auditd - system call auditing for critical paths
• SSH hardening - PasswordAuthentication disabled, key-only access
• Kernel hardening - SYN cookies, ASLR, rp_filter, TCP BBR
• /tmp as tmpfs - nosuid, nodev, noexec
• Azure IMDS endpoints - egress rules pre-configured (169.254.169.254, 168.63.129.16)

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json
• CIS Conformance Report - OpenSCAP HTML at /etc/lynxroute/cis-report.html
• Tailored CIS profile - /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md

Quick Start

1. Deploy the VM from Azure Marketplace (Standard_D2s_v3 or larger recommended)
2. SSH: ssh -i key.pem <username>@<PUBLIC_IP> (username set during VM creation, default: azureuser)
3. Read the generated credentials: sudo cat /root/openldap-credentials.txt
4. Query the directory: ldapsearch -H ldaps://localhost:636 -D "cn=admin,dc=example,dc=com" -W -b "dc=example,dc=com"
5. Change any server setting live: sudo ldapmodify -Y EXTERNAL -H ldapi:///

Port 389 requires StartTLS and port 636 is LDAPS - a plain unencrypted bind is refused by design. Restrict inbound 389 and 636 to the networks that need to bind before putting real identities in the directory.