LDAP authentication module is not correctly respecting grace login limit password policy

[pavelhoral]

Just stumbled on inconsistency in LDAP authentication module.

The problem:

We support password policies that can limit number of uses for expired password (grace-login-count in Wren:DS, pwdGraceAuthnLimit in OpenLDAP, pwdGraceLoginLimit in IBM DS, ...).

The current authentication module is using one LDAP connection for the initial BIND request and a another LDAP connection for the password change. This means that we can send users to password change screen with already depleted authentication limit.

Possible solutions:

• We should investigate possibilities to workaround the limit imposed by password policies; i.e. is there some LDAP control that we can send to allow additional connection when changing the password (I doubt that, but you never know)?
• We should investigate possibility of sharing the same LDAP connection between the initial authentication request and the password change request (there can be more than one change request if the new password is rejected by the policy) . This needs a thorough consideration because such approach will take out one LDAP connection from connection pool for extended time period.
• We should simply document this behavior so that administrators can adjust LDAP configuration accordingly (i.e. set higher limit). We might want to update LDAP module so that it is able to recoginze the limit has been depleted when on "password change" screen.

[pavelhoral]

I think that reserving LDAP connections for the whole user interaction is not feasible. This means that ideally we should try to update passwords via admin connection. This should not pose any security risk because we are already past the first authentication stage.

When changing password via admin connection we need to make sure the LDAP server honors password policies, including password history restrictions. This might be vendor specific (e.g. LDAP_SERVER_POLICY_HINTS_OID in AD).

Also changing password under admin connection means we will be using REPLACE attribute operation instead of DELETE/ADD combo. We have to make sure Wren:AM is responsible for verifying the current password in that case (i.e. we need to store password entered during the initial verification phase).