Bug 1517788
Summary: | password policy: minimum token length fails when the token lenght is equal to attribute length. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | German Parente <gparente> |
Component: | 389-ds-base | Assignee: | mreynolds |
Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
Severity: | unspecified | Docs Contact: | Marc Muehlfeld <mmuehlfe> |
Priority: | unspecified | ||
Version: | 7.4 | CC: | aadhikar, enewland, gparente, mreynolds, nkinder, rmeggins |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.3.7.5-12 | Doc Type: | Bug Fix |
Doc Text: |
The Directory Server trivial word check password policy now works as expected
Previously, when you set a "userPassword" attribute to exactly the same value as an attribute restricted by the "passwordTokenMin" setting with the same length, Directory Server incorrectly allowed the password update operation. With this update, the trivial word check password policy feature now correctly verifies the entire user attribute value as a whole, and the described problem no longer occurs.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2018-04-10 14:22:34 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
German Parente
2017-11-27 13:19:02 UTC
Investigating, but German you told me in a meeting that would found another issue when the token length is set higher than 6 (or something like that). Can you elaborate on this other issue you found? Upstream ticket: https://pagure.io/389-ds-base/issue/49524 Fixed upstream ============================================================================ test session starts ============================================================================ platform linux -- Python 3.6.3, pytest-3.4.0, py-1.5.2, pluggy-0.6.0 -- /opt/rh/rh-python36/root/usr/bin/python3 cachedir: .pytest_cache metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-845.el7.x86_64-x86_64-with-redhat-7.5-Maipo', 'Packages': {'pytest': '3.4.0', 'py': '1.5.2', 'pluggy': '0.6.0'}, 'Plugins': {'metadata': '1.5.1', 'html': '1.16.1'}} 389-ds-base: 1.3.7.5-18.el7 nss: 3.34.0-4.el7 nspr: 4.17.0-1.el7 openldap: 2.4.44-13.el7 svrcore: 4.1.3-2.el7 rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/suites/password, inifile: plugins: metadata-1.5.1, html-1.16.1 collected 1 item pwdPolicy_token_test.py::test_token_lengths OK group dirsrv exists OK user dirsrv exists INFO:lib389.topologies:Instance with parameters {'ldap-port': 38901, 'ldap-secureport': 63601, 'server-id': 'standalone1', 'suffix': 'dc=example,dc=com'} was created. INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Testing password len 4 token (test) INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Password correctly rejected: {'desc': 'Constraint violation', 'info': 'invalid password syntax - password based off of user entry'} INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Testing password len 6 token (test_u) INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Password correctly rejected: {'desc': 'Constraint violation', 'info': 'invalid password syntax - password based off of user entry'} INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Testing password len 10 token (test_user1) INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Password correctly rejected: {'desc': 'Constraint violation', 'info': 'invalid password syntax - password based off of user entry'} PASSEDInstance slapd-standalone1 removed. ========================================================================= 1 passed in 12.40 seconds ========================================================================= 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. https://access.redhat.com/errata/RHBA-2018:0811 |