OpenLDAP-Based Central Authentication Architecture (Part 3) — Client Integration and Access Policy Configuration

1. Overview

This document explains how to configure a Linux server (client) to perform centralized authentication through an OpenLDAP server.
By doing so, SSH login, sudo, and su privileges can be unified under LDAP accounts — eliminating the need for local account management on each server.

⚠️ Note:
All IPs, domain names, hostnames, and account names in this document are examples.
Replace them according to your organization’s security policy before deployment.

2. Architecture Overview

LDAP-based authentication operates as follows:

[User SSH Login]
       ↓
[PAM → NSS → SSSD/nslcd]
       ↓
[OpenLDAP Server]
       ↓
[Group Policy / sudo Privileges / ACL Mapping]
       ↓
[Auditd → Central Log Server]

The key component is the client-side configuration of PAM/SSSD, which enables SSH login, sudo rights, and group-based access control to integrate with LDAP policy.

3. Install Required Packages

CentOS / RHEL

yum install -y openldap-clients nss-pam-ldapd sssd authconfig

Ubuntu

apt install -y libnss-ldap libpam-ldap nslcd sssd

4. Connect to LDAP Server

4.1 Basic Authentication Setup (authconfig)

authconfig \
  --enableldap \
  --enableldapauth \
  --ldapserver=ldap://ldap.example.com \
  --ldapbasedn="dc=example,dc=com" \
  --enablemkhomedir \
  --update

The --enablemkhomedir option automatically creates a home directory when an LDAP user logs in for the first time.

Enable and start service:

systemctl enable nslcd
systemctl restart nslcd

5. NSS/PAM Integration Verification

5.1 /etc/nsswitch.conf

passwd:     files ldap
shadow:     files ldap
group:      files ldap

5.2 /etc/pam.d/system-auth

(Automatically configured by authconfig, but example shown for manual editing)

auth       required     pam_env.so
auth       sufficient   pam_unix.so nullok try_first_pass
auth       sufficient   pam_ldap.so use_first_pass
account    required     pam_unix.so broken_shadow
account    sufficient   pam_localuser.so
account    sufficient   pam_ldap.so
password   sufficient   pam_ldap.so use_authtok
session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077

6. LDAP DB ACL (Access Control List)

This ACL governs data-level access inside the LDAP database — not SSH or sudo permissions.
It defines which users can read/write attributes such as userPassword or group membership.

Example LDIF:

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attr=userPassword
  by dn="cn=manager,dc=example,dc=com" write
  by self write
  by * read
olcAccess: {1}to *
  by dn="cn=manager,dc=example,dc=com" write
  by * read

Meaning:

• The manager account can modify all entries.
• Users can change only their own password attribute.
• All others can read LDAP data but cannot modify it.

This strengthens LDAP database integrity and prevents unauthorized data changes.

7. Group-Based Access Policy (Client-Side)

Groups are organized under ou=Group for each department.

ou=Group,dc=example,dc=com
 ├── cn=ops
 ├── cn=dev
 └── cn=qa

Each user (e.g., uid=user01) has a memberOf attribute referencing one or more groups.
SSSD maps these LDAP groups to local OS groups, enabling unified access, sudo, and su restrictions.

8. Directory Access Example

Grant the operations team read/write access to /srv/app and developers read-only:

setfacl -R -m g:ops:rwX /srv/app
setfacl -R -m g:dev:rX /srv/app

⚠️ The uppercase X grants execute permission only to directories or files already executable, preventing unnecessary permission escalation.

9. Centralized SUDO Policy via LDAP

If the LDAP server has sudo.schema applied, sudo privileges can be centrally managed.

Client config: /etc/sudo-ldap.conf

base    dc=example,dc=com
uri     ldap://ldap.example.com
BINDDN  cn=manager,dc=example,dc=com
BINDPW  <manager_password>
SUDOERS_BASE ou=sudo,ou=people,dc=example,dc=com

Update /etc/nsswitch.conf:

sudoers: files ldap

Now, adding users to the cn=ops group under ou=sudo in LDAP automatically grants them sudo privileges.

10. Restart Services & Test

systemctl restart nslcd
getent passwd user01
su - user01

If LDAP users are correctly retrieved and login succeeds, integration is complete.

11. Troubleshooting Guide

12. Next Steps

In Part 4, we’ll cover fine-grained LDAP-based sudo roles and centralized audit logging.
Topics will include extended sudoRole structures and command history collection via auditd + rsyslog.

🛠 마지막 수정일: 2025.10.23