Bug 1465600 - PasswordCheckSyntax attribute fails to validate cn, sn, uid and mail attributes
PasswordCheckSyntax attribute fails to validate cn, sn, uid and mail attributes
Status: ON_QA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.4
x86_64 Linux
urgent Severity urgent
: rc
: ---
Assigned To: mreynolds
Viktor Ashirov
: ZStream
Depends On:
Blocks: 1489693
  Show dependency treegraph
 
Reported: 2017-06-27 13:46 EDT by Sankar Ramalingam
Modified: 2017-10-04 09:58 EDT (History)
4 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.7.5-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1489693 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sankar Ramalingam 2017-06-27 13:46:50 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-1.3.6.1-16

How reproducible: Consistently

Steps to Reproduce:
1. Install latest of 389-ds-base-1.3.6.1-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.
Comment 3 Sankar Ramalingam 2017-08-08 06:57:46 EDT
Automated in pytest ./suites/password/regression_test.py
Comment 4 Nathan Kinder 2017-08-29 16:13:35 EDT
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?
Comment 5 mreynolds 2017-09-01 09:29:25 EDT
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:

https://pagure.io/389-ds-base/issue/49370
Comment 7 Sankar Ramalingam 2017-09-11 08:19:31 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.