Expired LDAP password handling

In order that only an end user knows their password, whenever a password is administratively set, it is marked as expired. This is the nexus of a long standing request to deny LDAP binds for expired passwords.

This is a bit of a chicken-and-egg problem. All password changes eventually pass through LDAP so if it denies a BIND on expired password there is no way to reset it.

This is not to say that without denying expired LDAP passwords that the server is completely open to brute-force attacks. There are password policies that can limit the number of failed authentications and lock the account for a time period, or permanently.

But we recognized that it is unexpected behavior. Several attempts were made over the years to invent a mechanism to allow some operations for expired passwords and denied others but we would eventually run into corner cases and the changes were abandoned.

A new approach was taken based on an expired LDAP draft, https://tools.ietf.org/id/draft-behera-ldap-password-policy-10.html

This draft includes a proposal to limit the number of LDAP authentications based on a maximum number, a time limit, or both. I chose to implement a count-based approach which we’re calling “grace limit.”

The basic idea is that a password policy can contain a maximum count for use of the LDAP password. This can vary by policy and by default is -1, which is disabled in order to maintain backwards compatibility. A value of 0 disables all grace and any LDAP bind with an expired password is immediately denied.

For values above 0 that many authentications are allow for which any and all operations are allowed: searches, adds, deletes, modifies, etc per the permissions that the user has. Once the number of BIND has exceeded the grace limit the user is no longer to BIND.

To set a grace limit in a password policy on the command-line (not yet supported in the web UI):

pwpolicy-mod --gracelimit=[-1 to MAXINT]

A password policy control, if requested, is returned including the remaining number of BIND attempts. It will look something like this when the grace limit is set to 5 on the first BIND attempt:

$ ldapsearch -LLL -x -D 'uid=tuser,cn=users,cn=accounts,dc=example,dc=test' -W -e ppolicy -b uid=tuser,cn=users,cn=accounts,dc=example,dc=test dn
# PasswordExpired control
ldap_bind: Success (0) (Password expired, 4 grace logins remain)
dn: uid=tuser,cn=users,cn=accounts,dc=example,dc=test

Any password change on the account, by an administrator or the user will reset the grace period count back to 0.

In summary, to restrict LDAP binds post expiration the password policy needs to be updated to include a grace limit. The possible values are:

Grace Period ValueDescription
-1Grace limit handling is disabled (default)
0All LDAP BIND on expired passwords are denied
1-MAXINTThe number of LDAP binds allowed post-expiration

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s