OpenLDAP-Based Central Authentication Architecture (Part 1) — Overview and Structure

1. Overview

OpenLDAP provides a centralized directory service that manages user accounts, groups, permissions, and audit trails across Linux servers.
This guide is based on CentOS 7, but the same configuration principles apply to Ubuntu, Rocky, or AlmaLinux, with only minor differences in package names and file paths.

⚠️ Note:
All IP addresses, account names, domain names, and hostnames used here are examples.
Replace them according to your organization’s security and network policies.

2. The Role of OpenLDAP

OpenLDAP is more than a user authentication tool — it’s the foundation for centralized account security and access governance in server environments.
With a single LDAP server, multiple systems and applications can share consistent identity and permission data.

3. LDAP Data Structure

LDAP stores information in a hierarchical tree structure,
where each entry is uniquely identified by a Distinguished Name (DN).

dc=example,dc=com
 ├── ou=People
 │   ├── uid=user01
 │   ├── uid=user02
 └── ou=Group
     ├── cn=admin
     └── cn=devops

4. Architecture Overview

 ┌──────────────────────────────┐
 │       LDAP Client (Linux)    │
 │ PAM / NSS / SSSD / nslcd     │
 └──────────────┬───────────────┘
                │ Auth Request
 ┌──────────────┴───────────────┐
 │        OpenLDAP Server       │
 │ LDIF-based User/Group DB     │
 │ ACL / sudo / host policies   │
 └──────────────┬───────────────┘
                │ Audit Logs
 ┌──────────────┴───────────────┐
 │     Auditd / Syslog Server   │
 │ Centralized activity logs    │
 └──────────────────────────────┘

This structure unifies authentication, authorization, and audit within one pipeline.
While solutions like Keycloak, Okta, and Azure AD handle web-level identity federation,
OpenLDAP governs system-level access and command-level traceability inside Linux environments.

5. Example Access Policy

These policies are managed through LDAP groups (e.g., cn=ops,ou=Group)
and enforced using ACL rules and sudo.schema definitions.

6. Audit Log Design

OpenLDAP integrates with auditd to capture detailed activity such as logins,
su or sudo transitions, and file modifications.
All logs are centralized through Syslog (typically local4).

Sample log (values anonymized):

type=USER_AUTH msg=audit(...): user pid=24821 uid=2001 auid=2001 ses=1439 msg='op=PAM:authentication acct="svcadmin" exe="/bin/su" res=success'
type=SYSCALL msg=audit(...): exe="/bin/rm" key="SEC_AUDIT" cwd="/home/app" name="temp.log" nametype=DELETE

From these logs, administrators can trace who accessed which system,
what commands were executed, and when they occurred.

7. Security and Operational Notes

1. Always sanitize and adjust IPs, hostnames, and account names to fit your own environment.
2. Never edit /etc/openldap/slapd.d files directly.
   Manage configuration via LDIF files under /etc/openldap/ldif/ and apply them with ldapmodify.
3. The legacy slapd.conf method is deprecated in OpenLDAP 2.4+. Use LDIF-based configuration only.
4. When synchronizing between multiple LDAP servers, enforce encrypted channels (ldaps://) or use VPN-secured connections.

8. Coming Next

In Part 2, we’ll walk through the OpenLDAP server installation and initial setup,
including LDIF creation, schema application, and manager account registration.
All examples are based on CentOS, but the same process works on Ubuntu
with minor path and service name adjustments.

🛠 마지막 수정일: 2025.10.23