ou can use the below command to find out the values of Ldap attributes – pwdMaxAge, pwdMaxFailure

ldapsearch -H ldap://localhost:10389 -x -D "cn=manager,dc=apigee,dc=com" -W -b "cn=default,ou=pwpolicies,dc=apigee,dc=com"

Here’s the sample output for the above command:

# extended LDIF
#
# LDAPv3
# base <cn=default,ou=pwpolicies,dc=apigee,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# default, pwpolicies, apigee.com
dn: cn=default,ou=pwpolicies,dc=apigee,dc=com
objectClass: person
objectClass: pwdPolicy
objectClass: top
cn: default
pwdAttribute: userPassword
sn: dummy value
pwdExpireWarning: 604800
pwdInHistory: 3
pwdLockoutDuration: 300
pwdFailureCountInterval: 300
pwdMaxFailure: 3
pwdMinLength: 8
pwdMaxAge: 0
pwdLockout: FALSE
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

Source: How can we get the Password attributes such as pwdMaxAge, pwdMaxFailure etc for LDAP server in Apigee ?

Account expiration mail warning

Presentation

Usage

sh checkLdapPwdExpiration.sh

sh checkLdapPwdExpiration.sh 1>result.log 2>audit.log

--- Statistics ---
Users checked: 5
Account expired: 1
Account in warning: 1

No password policy for coudot
Password expired for sbahloul
No password change date for tchemineau
No password change date for rouazana
Mail sent to user farmand (farmand@example.com)

Configuration

export LC_ALL=en_US.UTF-8

Source: Account expiration mail warning [LDAP Tool Box (LTB)]

12.10.2. Password Policy Configuration

Instantiate the module in the database where it will be used, after adding the new ppolicy schema and loading the ppolicy module. The following example shows the ppolicy module being added to the database that handles the naming context “dc=example,dc=com”. In this example we are also specifying the DN of a policy object to use if none other is specified in a user’s object.

       database mdb
       suffix "dc=example,dc=com"
       [...additional database configuration directives go here...]

       overlay ppolicy
       ppolicy_default "cn=default,ou=policies,dc=example,dc=com"

Now we need a container for the policy objects. In our example the password policy objects are going to be placed in a section of the tree called “ou=policies,dc=example,dc=com”:

       dn: ou=policies,dc=example,dc=com
       objectClass: organizationalUnit
       objectClass: top
       ou: policies

The default policy object that we are creating defines the following policies:

• The user is allowed to change his own password. Note that the directory ACLs for this attribute can also affect this ability (pwdAllowUserChange: TRUE).
• The name of the password attribute is “userPassword” (pwdAttribute: userPassword). Note that this is the only value that is accepted by OpenLDAP for this attribute.
• The server will check the syntax of the password. If the server is unable to check the syntax (i.e., it was hashed or otherwise encoded by the client) it will return an error refusing the password (pwdCheckQuality: 2).
• When a client includes the Password Policy Request control with a bind request, the server will respond with a password expiration warning if it is going to expire in ten minutes or less (pwdExpireWarning: 600). The warnings themselves are returned in a Password Policy Response control.
• When the password for a DN has expired, the server will allow five additional “grace” logins (pwdGraceAuthNLimit: 5).
• The server will maintain a history of the last five passwords that were used for a DN (pwdInHistory: 5).
• The server will lock the account after the maximum number of failed bind attempts has been exceeded (pwdLockout: TRUE).
• When the server has locked an account, the server will keep it locked until an administrator unlocks it (pwdLockoutDuration: 0)
• The server will reset its failed bind count after a period of 30 seconds.
• Passwords will not expire (pwdMaxAge: 0).
• Passwords can be changed as often as desired (pwdMinAge: 0).
• Passwords must be at least 5 characters in length (pwdMinLength: 5).
• The password does not need to be changed at the first bind or when the administrator has reset the password (pwdMustChange: FALSE)
• The current password does not need to be included with password change requests (pwdSafeModify: FALSE)
• The server will only allow five failed binds in a row for a particular DN (pwdMaxFailure: 5).

The actual policy would be:

       dn: cn=default,ou=policies,dc=example,dc=com
       cn: default
       objectClass: pwdPolicy
       objectClass: person
       objectClass: top
       pwdAllowUserChange: TRUE
       pwdAttribute: userPassword
       pwdCheckQuality: 2
       pwdExpireWarning: 600
       pwdFailureCountInterval: 30
       pwdGraceAuthNLimit: 5
       pwdInHistory: 5
       pwdLockout: TRUE
       pwdLockoutDuration: 0
       pwdMaxAge: 0
       pwdMaxFailure: 5
       pwdMinAge: 0
       pwdMinLength: 5
       pwdMustChange: FALSE
       pwdSafeModify: FALSE
       sn: dummy value

You can create additional policy objects as needed.

There are two ways password policy can be applied to individual objects:

1. The pwdPolicySubentry in a user’s object – If a user’s object has a pwdPolicySubEntry attribute specifying the DN of a policy object, then the policy defined by that object is applied.

2. Default password policy – If there is no specific pwdPolicySubentry set for an object, and the password policy module was configured with the DN of a default policy object and if that object exists, then the policy defined in that object is applied.

Please see slapo-ppolicy(5) for complete explanations of features and discussion of “Password Management Issues” at http://www.symas.com/blog/?page_id=66

12.10.3. Further Information

slapo-ppolicy(5)

Source: OpenLDAP Software 2.4 Administrator’s Guide: Overlays

OpenLDAP has a dynamically loadable module which can enforce password policies. It allows to define policies for the userPassword attribute. Policies can define the maximum login attempts with the wrong password, maximum age of a password and many more.

Here is a short introduction into this module. If you want to read about it in detail, see the link collection at the end of this page.

Note: The connection parameters and DN parameters deeply depend on your setup, the examples here need to be adjusted to your setup.

Configuration of the ppolicy overlay

The basic configuration depends on your OpenLDAP version. Newer versions store their configuration in a so-called Online Configuration Database (OLC), older ones use a configuration file called slapd.conf

OpenLDAP with OLC

• Load the ppolicy schema into OLC: ldapmodify -D "cn=root,cn=config" -W -a -f /etc/openldap/schema/ppolicy.ldif
• Load the module: ldapmodify -D "cn=root,cn=config" -W -a -f ppolicymodule.ldif

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: ppolicy.la

• Configure ppolicy overlay: ldapmodify -D "cn=root,cn=config" -W -a -f ppolicyoverlay.ldif

dn: olcOverlay=ppolicy,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=passwordDefault,ou=Policies,dc=mydomain,dc=tld
olcPPolicyHashCleartext: FALSE
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE

OpenLDAP with slapd.conf

If you have an older version of OpenLDAP, the configuration goes into slapd.conf:

#-- Load schema
include         /etc/openldap/schema/ppolicy.schema

#-- Load module
moduleload ppolicy.la

The next snippet should come somewhere after the database definition:

#-- Load overlay
overlay ppolicy
ppolicy_default "cn=passwordDefault,ou=Policies,dc=mydomain,dc=tld"

This means the default policy is located under cn=passwordDefault,ou=Policies,dc=mydomain,dc=tld

Definition of a password policy

In the overlay configuration we specified the default policy, so we add it now using the following LDIF:

dn: ou=Policies,dc=mydomain,dc=tld
ou: Policies
objectClass: organizationalUnit

dn: cn=passwordDefault,ou=Policies,dc=mydomain,dc=tld
objectClass: pwdPolicy
objectClass: person
objectClass: top
cn: passwordDefault
sn: passwordDefault
pwdAttribute: userPassword
pwdCheckQuality: 0
pwdMinAge: 0
pwdMaxAge: 0
pwdMinLength: 8
pwdInHistory: 5
pwdMaxFailure: 3
pwdFailureCountInterval: 0
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdAllowUserChange: TRUE
pwdExpireWarning: 0
pwdGraceAuthNLimit: 0
pwdMustChange: FALSE
pwdSafeModify: FALSE

All these parameters are described in detail at Chapter 6 OpenLDAP password policy overlay / pwdPolicy ObjectClass and Attributes.

This policy applies to all userPassword attributes. If an object needs a different policy, just define the differing policy under another name and reference the policy with the pwdPolicySubentry attribute. Example:

dn: cn=My User,ou=People,dc=mydomain,dc=tld
changetype: modify
add: pwdPolicySubentry
pwdPolicySubentry: cn=passwordSpecial,ou=Policies,dc=mydomain,dc=tld

Usage and behaviour

Query all locked accounts

If an object has the pwdAccountLockedTime attribute: it is locked since then. Simply issue the following query:
ldapsearch <MYCONNECTIONPARAMS> -b "ou=People,dc=mydomain,dc=tld" "pwdAccountLockedTime=*" pwdAccountLockedTime

Unlock an account

There are two variants. For the first one you simply delete the pwdAccountLockedTime attribute which unlocks the account immediately:

dn: cn=My User,ou=People,dc=mydomain,dc=tld
changetype: modify
delete: pwdAccountLockedTime

The second variant adds the attribute pwdReset which basically means: The user can only login again after changing it’s password:

dn: cn=My User,ou=People,dc=mydomain,dc=tld
changetype: modify
add: pwdReset
pwdReset: TRUE

If the user tries other operations than changing its password, the OpenLDAP server responds with bind: Operations are restricted to bind/unbind/abandon/StartTLS/modify password Changing an LDAP password can be done f.e. with the ldappasswd tool:

ldappasswd <MYCONNECTIONPARAMS> -D "cn=My User,ou=People,dc=mydomain,dc=tld" -W -S "cn=My User,ou=People,dc=mydomain,dc=tld"

Behaviour of some policy settings

A short overview of how some of the policies behave (not all covered here):

pwdMinAge

Result: Constraint violation (19)
Additional info: Password is too young to change

pwdMaxAge

ldap_bind: Invalid credentials (49)
in the logfile: ppolicy_bind: Entry cn=My User,ou=People,dc=mydomain,dc=tld has an expired password: 0 grace logins

pwdGraceAuthNLimit

in the log: ppolicy_bind: Entry cn=My User,ou=People,dc=mydomain,dc=tld has an expired password: 1 grace logins

pwdInHistory

Result: Constraint violation (19)
Additional info: Password is in history of old passwords

pwdAllowUserChange

Result: Insufficient access (50)
Additional info: User alteration of password is not allowed

Storage location of the policy data

Policy data (f.e. number of failed login attempts) is stored as Operational Attributes on each object. In a normal ldapsearch query operational attributes are not returned. To make them visible, add a “+” to the end of the query. Example: ldapsearch <MYCONNECTIONPARAMS> -b "ou=People,dc=mydomain,dc=tld" "+"

Considerations when using LDAP replication

If you replicate from an LDAP master to LDAP slave(s) and your users are authenticating against slaves, take into consideration that the policy data needs to be synced somehow back to the master (f.e. number of failed login attempts).

The ppolicy module already knows about it. You basically need to set the
configuration value olcPPolicyForwardUpdates (OLC style) / ppolicy_forward_updates (slapd.conf). Furthermore chaining must be configured, including syncrepl. This is very well documented at Linuxtopia.

Source: OpenLDAP Password Policy overlay (ppolicy)