Use-case 2 - PWD change by user/admin Use-case 2 - Password change by user/admin

A password change is either initiated by the user, an administrator or the system.

Consider the following cases:

  • 1.
    A password change is enforced and the new password is set by an administrator
  • 2.
    A password change is enforced by a user and the new password is set by an administrator
  • 3.
    A password change is enforced by Airlock IAM and the new password is set by the user (e.g. password expired)
  • 4.
    A user wants to change the password

Based on the use case, different password policy attributes are considered. The following password policy attributes are checked on a password change against the current password. Attributes are described in detail in the table above.

  • Case 1. - 3.
    • msDS-MinimumPasswordLength
    • msDS-PasswordComplexityEnabled
  • Case 4
    • msDS-MinimumPasswordLength
    • msDS-PasswordComplexityEnabled
    • msDS-MinimumPasswordAge

If a new password meets all requirements of the password policy, it is set on the user on the AD via the LDAP connection. 

More technically, Airlock IAM binds to the AD with the configured service account. On the resulting connection, a ModifyRequest plus the user's DN is passed to the AD to perform the password change. This way, the AD should check the password against the user's history and not the history of the technical account.

Since Airlock IAM can not store the password history (this information is kept on the AD and cannot be read), it may try to set a password on the AD that does not comply with the current policy regarding password history length. Normally, Airlock IAM can check all requirements of a password (length, complexity, etc.) before setting a new password on the AD. In case of password history, it must try to set it on the AD. Therefore, if the user sets a password that already used before and is still in the history on the AD, the operation gets rejected and a corresponding error message is shown to the user.