Password policy tips

 

Password policy may not always behave as expected.

There are two areas where the implementation of password policy may not behave as expected:

1. If the pwdReset attribute has been set for an entry, a client can bind indefinitely using the entry DN and the reset password. With the Password Policy Request Control present, this results in a successful bind with a warning in the response control. But if the client does not specify the request control, this "non-password policy aware" client sees a successful bind with no indication that the password must be changed. Subsequent operations under that DN will still fail with an "unwilling to perform" error; only the initial bind result might seem misleading. This could be an issue if the bind was done only for authentication, as might be the case with a web application using the directory for authentication.

2. The pwdSafeModify and pwdMustChange policies do not behave as you might expect with an application that changes passwords under an identity other than the DN of the entry for which the password is being changed. In this scenario, a safe password change done under an administrative identity, for example, will result in the pwdReset attribute being set. The application changing the password can use an administrator account and remove the pwdReset attribute as described earlier.

 

Parent topic:

Directory Server security