Enhanced password policy behavior with one-way encryption method

Edit online

The pwdCheckSyntax attribute indicates whether the password is checked for syntax.

The values of the pwdCheckSyntax attribute indicate the following options:
  • The value 0 indicates that syntax checking is not enforced
  • The value 1 indicates that the server checks the syntax, and takes the following actions:
    • If all password policy syntax or constraint checks can be verified by the server:
      • If the password policy checks fail, the new password is rejected
      • If the password policy checks pass, the new password is accepted.
    • If all password policy syntax or constraint checks cannot be verified by the server, (due to other reasons such as current password not available as part of modification), the new password is accepted.
  • The value 2 indicates that the server checks the syntax, and takes the following actions:
    • If all password policy syntax and constraint checks can be verified by the server:
      • If the password policy checks fail, the new password is rejected.
      • If the password policy checks pass, new password is accepted.
    • If all password policy syntax and constraint checks cannot be verified by the server (due to other reasons), the new password is rejected.
You can use one-way encryption method and specify pwdCheckSyntax=1, for example:
  1. Set the one-way encryption sha 2.
  2. Enable password policy and set pwdCheckSyntax=1

The following scenarios for user modification on userpassword attribute describe the behavior of IBM® Security Directory Server with these settings.

Scenario 1
ldapmodify -D cn=test,o=sample -w test123
dn: cn=test,o=sample
changetype: modify
delete: userpassword
userpassword: test123

add: userpassword
userpassword: test1234

Operation 0 modifying entry cn=test,o=sample
ldap_modify: Constraint violation --- Error, Invalid
password syntax
ldap_modify: additional info: Failed passwordMinDiffChars policy
Scenario 2
ldapmodify -D cn=test,o=sample -w test123
dn: cn=test,o=sample
changetype: modify
replace: userpassword
userpassword: test1234

Operation 0 modifying entry cn=test,o=sample

The first modify operation in Scenario 1 fails as expected because it fails the password policy constraints, while the second modify operation in Scenario 2 works.

The ldapmodify commands in both scenarios consist of one LDAP bind operation and one LDAP modify operation.

However, the two scenarios are different because:

In Scenario 1, the current password is repeated twice: Current® password (first time) in the command itself (-w test123), which is used only for the bind operation. This password can be used only for bind purposes and cannot be saved internally for later use. On an LDAP connection:
  • The bind can happen at any time
  • The bound connection can be used for any operation later
  • The server must not store and depend on the password that is provided during the bind operation.
Hence, after bind verification, this password gets discarded. By using this bound connection, the client can run any operation that the server is not aware of currently during the bind process.
The current password (second time) is provided in the ldif for modification (with the delete part). By using the password that is provided in the delete part of modification in clear text, the LDAP server code can check whether it is an existing password in the database. This process is similar to a bind or compare.
  • If the current password that is provided in modification is an existing password, it can be used to cross-check against the new password that is provided as part of the add part of the modification. If this new password meets all the password policy criteria, then the entire modification succeeds.
  • If the current password provided in modification is not an existing password, then the modification fails automatically since it cannot delete that password.
Note: ldapchangepwd also emulates this behavior of providing both old and new passwords on modify operation.

In Scenario 2, the current password is provided only once and that too as part of bind operation. The bind operation succeeds if the current password is provided with -w.

After successful bind, an LDAP modify operation follows.
  • This LDAP modification is not aware of the password that was used in the bind operation.
  • The modification does not contain the current password.
  • The server cannot decrypt any passwords from database since they are all one way encrypted.

Now if the rule for pwdCheckSyntax takes effect, and if pwdCheckSyntax is set to 1, the password change gets accepted. If pwdCheckSyntax is set to 2, the password change gets rejected.