Cannot lock users in FD with the pwd check module enabled and not using rootDN
Description
Context: FusionDirectory is using a regular DSA account with write privileges to connect to OpenLDAP, and not using the directory rootDN.
When a FD user wants to lock an account that has a password policy with a pwdCheckModule enabled and quality set to 2, he gets this error:
LDAP modify operation failed!
Object: uid=tpolicy,ou=users,dc=my-domain,dc=com
Error: Constraint violation (Password fails quality checking policy, while operating on 'uid=tpolicy,ou=users,dc=my-domain,dc=com' using LDAP server 'ldap://localhost:2389')
Distribution Name and Version
Debian stretch
FusionDirectory Version
1.3-1
PHP version used
PHP 7.0.33-0+deb9u3
Origin of php packages
debian
Steps to Reproduce
- Configure FD to connect to OpenLDAP using a DSA account with write privileges on your branch instead of rootDN
- Activate ppolicy module in OpenLDAP and ppolicy plugin in FD
- Activate a check module on a password policy (in our case, we used LTB's PPM https://github.com/ltb-project/ppm) :
objectClass: pwdPolicyChecker
pwdCheckModule: /usr/local/openldap/lib64/ppm.so
pwdCheckQuality: 2
- Add this password policy to a user
- Try to lock / unlock the user: the action will fail as FD is trying to edit the password by adding à "!" between the password method and encrypted password, which is rejected by the pwd quality checker as it cannot checks quality on encoded password and is set to reject password on module failure.
- Trying to change the user password using any other method than "clear" will also result in an error message: the password is rejected by the pwd quality checker for same reason than above.
Expected behavior:
When pwdCheckQuality is set to 2 and a policy checker is set, password should only be updated using clear/plain text method so the password policy can check. It would be nice to be able to deactivate the password method choice from user edition page depending on the current ppolicy.
Also, the lock/unlock could set the pwdAccountLockedTime attribute at value '000001010000Z' which will result in permanent locking, instead of manipulating the encoded value of the user password.
Actual behavior:
Managers cannot lock account using FD functionality and have errors when changing password using another password method than "clear" if FD is not using the RootDN account that do not trigger password quality checks.
Reproduces how often: 100%