Question & Answer
Question
Password policy behavior with one way encryption method and pwdCheckSyntax=1
Cause
The following fix levels with associated APARs enhanced the pwdCheckSyntax behavior with one-way encrypted passwords:
6.3.1.0 - Base/GA level
6.3.0.12 or later fix levels - IO16373
6.2.0.23 or later fix levels - IO16372
6.1.0.49 or later fix levels - IO15809
6.0.0.70 or later fix levels - IO16645
Original pwdCheckSyntax behaviour as per Administration guide:
The pwdCheckSynatx attribute indicates whether the password will be checked for syntax. The values of the pwdCheckSynatx attribute indicates the following:
'0' means syntax checking will not be enforced
'1' means the server will check the syntax, and if the server is unable to check the syntax (due to a hashed password or other reasons) it will be accepted
'2' means the server will check the syntax, and if the server is unable to check the syntax it returns an error refusing the password
With the above mentioned fix levels / APARs the enhanced pwdCheckSyntax behaviour:
'0' means syntax checking will not be enforced
'1' means the server will try to check the syntax.
- 1.a. If all password policy syntax/constraint checks can be verified by the server
- 1.a.i. If the password policy checks fail, new password is rejected
1.a.ii. If the password policy checks pass, new password is accepted.
- 1.b. If all password policy syntax/constraint checks can not be verified by the server (due to other reasons such as current password not available as part of modification)
- The new password will be accepted.
'2' means the server will try to check the syntax.
- 2.a. If all password policy syntax/constraint checks can be verified by the server
- 2.a.i. If the password policy checks fail, new password is rejected
2.a.ii. If the password policy checks pass, new password is accepted.
- 2.b. If all password policy syntax/constraint checks can not be verified by the server (due to other reasons)
- The new password will be rejected.
Answer
The following documentation explains the Directory Server behavior when using the one way encryption method and pwdCheckSyntax=1.
1. Set the one-way encryption sha
2. Enable password policy and Set pwdCheckSyntax=1
3. Below are the two different scenarios for user modification on userpassword attribute.
=================================================================================
A) 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
B) 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
First modify operation in case A is failing as expected because its failing the password policy contraints, and second modify operation in case B is working.
===================================================================================
In the above two ldapmodify commands, each of them consists of one ldap bind operation and one ldap modify operation under the covers of the ldapmodify command.
Both cases A and B given above are completely different and here is why:
In case A, the current password is repeated twice. Current password (first time) in the command itself (-w test123), which is only used for bind operation. This password can only be used for bind purposes and can not be saved internally for later use. Note that on an ldap connection, the bind can happen any time and that bound connection can be used for any operation at a later time and the server should not store & depend on the password provided on bind operation. Hence after bind verification, this password gets discarded. Then using this bound connection client may perform any operation which server is completely not aware of at this time of bind process.
Importantly, the current password (second time) is provided in the ldif for modification (with delete part)
Using the password provided in the delete part of modification in clear text, the ldap server code
can check if thats an existing password in the db. [similar to a bind or compare]
i. If the current password provided in modification is an existing password, it can used to cross check against the new password provided as part of add part of modification. If this new password meets all the password policy criteria, then the entire modification succeeds.
ii. If the current password provided in modification is not an existing password, then the modification fails automatically since it can not delete that password.
Note: ldapchangepwd also emulates this behavior of providing both old and new passwords on modify operation.
In case B, 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, a ldap modify operation follows. Again note that this ldap modification is not aware of the password used in bind operation.
The modification does not contain the current password. The server can not decrypt any passwords from database since they are all one way encrypted.
Now if the rule for pwdCheckSyntax takes effect, if pwdCheckSyntax is set to 1, the password change gets accepted and if pwdCheckSyntax is set to 2, the password change gets rejected.
Product Synonym
TDS; IDS; DS; ITDS
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21676569