Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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.
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?
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.