| 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: | --- | ||
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 |
Description of problem: the function check_trivial_words is failing to recongnize a token that is exactly same size as the token length. Example: dn: uid=Dord,ou=People,dc=parente,dc=local sn: David objectClass: top objectClass: account objectClass: posixaccount objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person uid: Dord cn: David loginShell: /bin/bash homeDirectory: /home/dorda uidNumber: 501003 gidNumber: 510003 passwordMinTokenLength: 4 ldapmodify -D "uid=Dord,ou=People,dc=parente,dc=local" -w secret12 dn: uid=Dord,ou=People,dc=parente,dc=local changetype: modify replace: userpassword userPassword: dord modifying entry "uid=Dord,ou=People,dc=parente,dc=local" Actual results the password including a token of 4 length is accepted (it's the exact length of the attribute). Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-21 How reproducible: always Actual results: password is not refused. Expected results: password refused when the token length is same length than the attribute. Additional info: After some debugging, the function: check_trivial_words calls ldap_utf8prevn(sp, ep, toklen); This function returns NULL when the token length is same length than the attribute value in "sp". IMHO, this should be the fix: char ldap_utf8prevn(char s, char from, int n) { char prev = from; if (!s || !from || (s > from)) { return NULL; } for (; n > 0; --n) { prev = ldap_utf8prev(prev); if ((prev <= s) && (n > 0)) { <============= should be (prev < s) return NULL; } } return prev; } For instance, in the previous example, ldap_utf8prevn("dord", char *from,4) will loop to find the postfix d, rd, ord, and will return NULL for dord. So check_trivial_words will fail to refuse the password.