Bug 190862

Summary: [RFE] Default password syntax settings don't work with fine-grained policies
Product: Red Hat Enterprise Linux 7 Reporter: Nathan Kinder <nkinder>
Component: 389-ds-baseAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: low    
Version: 7.0CC: bugzilla-redhat, cstpierr, jgalipea, nhosoi, nkinder, rmeggins, spichugi
Target Milestone: rcKeywords: FutureFeature, Reopened
Target Release: 7.3   
Hardware: All   
OS: Linux   
Fixed In Version: 389-ds-base- Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1333946 (view as bug list) Environment:
Last Closed: 2016-11-03 20:33:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 495079, 512820, 690319, 1333946    

Description Nathan Kinder 2006-05-05 19:27:21 UTC
When using a global password policy for syntax checking, there are some default
settings that will be used (such as a minimum length of 8) if the config
attributes don't exist in cn=config.  This doesn't seem to work with the
fine-grained policies.

Here are some steps to reproduce the problem:

 1. - Enable global syntax checking, setting the minLength to 6.
 2. - Enable fine-grained password policies.
 3. - Create a subtree-level policy on "ou=People", enabling syntax checking
      with the default values (minLength will be displayed as 8 in Console).
 4. - Attempt to change a password of a user outside of "ou=People" with a
      password of 5 characters long.  This should be rejected with an err=19.
 5. - Try step 4 again, but with a password length of 6 characters.  This
      should work.
 6. - Try step 4 again, but with a user inside of "ou=People".  This should
      fail with an err=19, but it will succeed!

To work around the problem, you can add the password syntax attributes to the
fine-grained policy entry explicitly.  This can be done via the Console UI by
setting each of the syntax settings to a non-default value, saving it, then
setting them to what you want (even if you want the defaults) and saving again.

Comment 2 Rich Megginson 2009-04-09 16:54:20 UTC
Once this is documented, we either need to move this bug to DS9.0 and FDS1.3.0 or close this and open a new bug.  This falls under the category of "expose password policy to plug-ins"

Comment 4 Deon Ballard 2009-05-01 22:33:28 UTC

Comment 5 Deon Ballard 2010-04-15 15:18:19 UTC
I'm not certain I should have closed this bug; I think I should have reassigned it to engineering.


Comment 6 Rich Megginson 2010-09-27 15:31:46 UTC
*** Bug 553736 has been marked as a duplicate of this bug. ***

Comment 9 Martin Kosek 2012-01-04 13:48:51 UTC
Upstream ticket:

Comment 12 Mike McCune 2016-03-28 23:11:51 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions

Comment 14 Noriko Hosoi 2016-05-06 18:30:26 UTC
Note: doc bug 1333946

Comment 15 Simon Pichugin 2016-09-05 06:33:14 UTC
============================= test session starts =============================
platform linux2 -- Python 2.7.5, pytest-3.0.2, py-1.4.31, pluggy-0.3.1 -- /usr/bin/python
cachedir: .cache
DS build: B2016.245.1935
nss: 3.21.0-17.el7
nspr: 4.11.0-1.el7_2
openldap: 2.4.40-13.el7
svrcore: 4.1.2-1.el7

rootdir: /mnt/tests/rhds/tests/upstream/ds, inifile:
plugins: beakerlib-0.6, html-1.10.0, cov-2.3.1
collected 5 items

dirsrvtests/tests/suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[off-off] PASSED
dirsrvtests/tests/suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[on-off] PASSED
dirsrvtests/tests/suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_no_restrictions[off-on] PASSED
dirsrvtests/tests/suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_restrictions[cn=config] PASSED
dirsrvtests/tests/suites/password/pwdPolicy_inherit_global_test.py::test_entry_has_restrictions[cn="cn=nsPwPolicyEntry,ou=People,dc=example,dc=com",cn=nsPwPolicyContainer,ou=People,dc=example,dc=com] PASSED

========================== 5 passed in 28.57 seconds ==========================

Marking as verified.

Comment 17 errata-xmlrpc 2016-11-03 20:33:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.