Red Hat Bugzilla – Bug 1465600
PasswordCheckSyntax attribute fails to validate cn, sn, uid and mail attributes
Last modified: 2017-10-04 09:58:31 EDT
Description of problem: Password policy's PasswordCheckSyntax attribute allows the user to set the password(trivial) which contains cn, sn, mail and uid attributes. This fails for both Global and Fine grain password policy.
Version-Release number of selected component (if applicable): 389-ds-base-18.104.22.168-16
How reproducible: Consistently
Steps to Reproduce:
1. Install latest of 389-ds-base-22.214.171.124-16 on RHEL-7.4.
2. Create an instance and configure password policy with PasswordCheckSyntax attribute set to on.
3. Add users with cn, sn, uid, mail and userPassword attributes.
4. Run ldapmodify as normal user and replace userPassword with sn, cn, mail or uid attributes of the same user.
5. Trivial value of sn, cn, mail and uid attributes accepted for userPassword.
Actual results: cn, sn,uid and mail attribute values accepted as userPassword when PasswordCheckSyntax is set to on.
Expected results: It should reject the passwords with error 19. Constraint violation
Additional info: Observed from TET Password Policy tests. So, to verify this, we can run password policy tests(select PasswordRunIt) from TET.
Failed tests: pwp_34 only. But, the following test cases
pwp_36, pwp_37, pwp_38, pwp_104, pwp_105, pwdp_01 and pwdp_02 fail due
to pwp_34 failure.
Automated in pytest ./suites/password/regression_test.py
Your examples show that the trivial words check is working with a global policy, but not with a local (fine-grained) policy. Were you actually defining a local password policy when you enabled nsslapd-policy-local? If so, did you enable password syntax checking in the local password policy for your tests?
The issue is that when we use local password policies we do not use the same defaults as the global policy. In this particular case the token length was 0 by default (the global policy is 3), this basically disabled the trivial password check.
This is now fixed upstream via:
(In reply to Nathan Kinder from comment #4)
> Your examples show that the trivial words check is working with a global
> policy, but not with a local (fine-grained) policy. Were you actually
> defining a local password policy when you enabled nsslapd-policy-local? If
> so, did you enable password syntax checking in the local password policy for
> your tests?
Yes, when I enabled nsslapd-policy-local, I set the value 'PasswordCheckSyntax: on' for the subtree password policy.