Learn LDAP - Password Policies

#Introduction

In episode 11 you learned about overlays as OpenLDAP's modular mechanism, including a glimpse of ppolicy and syncprov. Episode 12 turns that concept into real practice: a complete password policy that governs length, age, history, and account lockout. This is one of the features most often requested once an organization starts treating LDAP as the source of truth for authentication — because without a policy, userPassword is just a password with no rules.

#Password Policy Overlay

ppolicy is the overlay that brings password policy attributes into the directory. The module enforces quality, age, history, and lockout rules on every bind and password change operation, without changing a single line of client application code.

Quality requirements are measured through pwdCheckQuality and pwdMinLength: the quality level determines how strictly new passwords are tested, while the minimum length serves as the security baseline. Policy application is done per-entry via pwdPolicySubentry, or globally via the default policy mounted in the overlay configuration.

On Debian and Ubuntu, overlay modules live in /usr/lib/ldap and are loaded with olcModuleLoad: ppolicy.la. If you recompile a module (for example after building from source), don't forget to run slaptest -u to make sure the configuration is valid.

#Password Policy Attributes

A policy is defined as an entry with the pwdPolicy object class. Its attributes work in pairs to form a complete rule set:

Attribute	Function
`pwdMinLength`	Minimum password length
`pwdMaxLength`	Maximum password length
`pwdMinAge`	Minimum age before a password may be changed (seconds)
`pwdMaxAge`	Maximum age before a password expires (seconds)
`pwdInHistory`	Number of old passwords that can't be reused
`pwdCheckQuality`	Quality checking level (0, 1, or 2)
`pwdMaxFailure`	Bind failure limit before the account locks
`pwdLockout`	Enable or disable account lockout
`pwdLockoutDuration`	Lockout duration in seconds
`pwdGraceAuthNLimit`	Number of grace logins after a password expires

Two operational attributes accompany this mechanism: pwdChangedTime records when the password was last changed, and pwdFailureTime records each bind failure time — both are filled automatically by the overlay, no manual setup needed. pwdMaxAge and pwdMinAge are in seconds, so 90 days equals 7776000.

#Creating a Policy Entry

A policy entry is created like any other entry, but with the pwdPolicy and person object classes (for the cn and sn attributes):

Default policy under ou=policies

dn: cn=default,ou=policies,dc=example,dc=com
objectClass: pwdPolicy
objectClass: person
cn: default
sn: default policy
pwdAttribute: userPassword
pwdMinLength: 12
pwdMaxLength: 64
pwdMinAge: 1
pwdMaxAge: 7776000
pwdInHistory: 5
pwdCheckQuality: 2
pwdMaxFailure: 5
pwdLockout: TRUE
pwdLockoutDuration: 900
pwdGraceAuthNLimit: 3

Add it with ldapadd -x -D cn=admin,dc=example,dc=com -W from this LDIF file. pwdCheckQuality: 2 means quality is checked when the password is set and on the first bind; pwdLockout: TRUE with pwdMaxFailure: 5 and pwdLockoutDuration: 900 locks an account for 15 minutes after five failures.

#Connecting the Policy to the Database

So the overlay knows which policy is the default, set olcPPolicyDefault in the overlay configuration in cn=config:

The effective policy follows these rules:

If a user entry has a pwdPolicySubentry, that policy applies (per-user policy).
Otherwise, olcPPolicyDefault is the fallback for the entire database.
If neither exists, no policy is applied.

A per-user policy is mounted directly on the person's entry — for example, pwdPolicySubentry: cn=strict,ou=policies,dc=example,dc=com added to uid=budi,ou=people,dc=example,dc=com. This is useful for sensitive accounts like admins or service accounts that need stricter rules.

#Password Hashing

How a password is stored in userPassword determines how much effort an attacker needs to reverse it. OpenLDAP stores password values together with a hash scheme label:

Scheme	Strength	Notes
`{SSHA}`	Moderate	Salted SHA-1, the old default standard
`{SSHA256}`	Good	Salted SHA-256
`{SSHA512}`	Good	Salted SHA-512, the modern recommendation
`{CRYPT}`	Depends	Uses the system crypt, usable with shadow
`{MD5}`	Weak	Unsalted, deprecated
`{ARGON2}`	Strong	Argon2, modern, requires slapd build support

The default hash is set in cn=config with olcPasswordHash. For a more secure value than the built-in {SSHA}, change it to {SSHA512}:

Keep in mind: changing the default only affects passwords hashed afterward. Existing passwords keep their old scheme until the user changes the password.

#External Password Validation

pwdMinLength and pwdCheckQuality only check basic form. For smarter rules — for example, forbidding dictionary words or keyboard patterns — ppolicy supports external validation through pwdCheckModule on the policy entry:

Enabling an external checker module

dn: cn=default,ou=policies,dc=example,dc=com
changetype: modify
replace: pwdCheckModule
pwdCheckModule: check_password.so

This module can integrate cracklib, the same library as the cracklib-unix used by pam_cracklib on Linux systems, or a custom validator you write yourself and compile as a shared library. On Debian and Ubuntu, make sure the module's supporting packages are installed and the module sits in a directory slapd can read. This layer is optional — many deployments stay with pwdCheckQuality for simplicity.

#Testing the Policy

Each part of the policy must be tested separately, and all the tests can be done with standard clients:

Testing password changes and lockout

ldapmodify -x -D uid=budi,ou=people,dc=example,dc=com -W
ldapwhoami -x -D uid=budi,ou=people,dc=example,dc=com -w wrong
ldapsearch -x -D cn=admin,dc=example,dc=com -W \
  -b uid=budi,ou=people,dc=example,dc=com pwdAccountLockedTime

Password change testing — change the user's password, then check that pwdChangedTime updates.
Lockout testing — bind with the wrong password five times; the sixth bind fails and pwdAccountLockedTime appears.
Expiration testing — set a small pwdMaxAge, wait for it to pass, then bind; the server rejects with result code 49 and the message password expired.
Grace login testing — after expiration, the user can still bind up to pwdGraceAuthNLimit times, and an expiration warning message appears in the bind result.

Important

Watch out for one common trap: testing lockout against the admin account. If cn=admin follows the default policy and gets locked, the main gateway into the directory locks too. In the lab, give admin a pwdPolicySubentry pointing to a loose policy, or test lockout on a regular user account first.

#Closing

In this episode 12 you applied the ppolicy overlay: loading the module, understanding the attributes from pwdMinLength to pwdGraceAuthNLimit, creating default and per-user policy entries, choosing hash schemes from {SSHA} to {ARGON2}, enabling external validation via pwdCheckModule, and testing password changes, lockout, expiration, and grace logins.

Key takeaways:

A policy is inert without the overlay — load ppolicy.la, set olcPPolicyDefault, and create a pwdPolicy entry.
Inheritance is ordered — pwdPolicySubentry beats the default policy, the default policy beats no policy.
The hash determines attack cost — move up to {SSHA512} and avoid the deprecated {MD5}.
Test every path — lockout, expiration, and grace logins must be verified before production use.

In the next episode, episode 13, we cover LDAP replication — how a single provider distributes its data to consumers with syncrepl, from refreshOnly to multi-master. The password policies you created here will be replicated too and must behave identically across all servers.