Red Hat Bugzilla – Bug 1044150
7-bit checking is not necessary for userPassword
Last modified: 2015-03-05 04:30:03 EST
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47363 Considering another ticket #363 - "Passsync/Winsync handles passwords with 8-th bit characters incorrectly", 7-bit checking for userPassword is outdated. Email conversation: nhosoi wrote> We are checking userPassword in 7-bit check plugin. Isn't it a good timing to eliminate userpassword from the default checking list? I was also thinking to add an upgrade script for that, but customers may not like to see the change made automatically. So, we could just advertise it is supported now and suggest to delete "userpassword" from the 7-bit checking list, if preferable? nkinder wrote> We shouldn't change the config during upgrade, but I think it would be fine to change the default for new instances as of 389-ds-base-1.3.2.
$ rpm -qa | grep 389 389-ds-base-debuginfo-1.3.3.1-10.el7.x86_64 389-ds-base-1.3.3.1-10.el7.x86_64 389-ds-base-libs-1.3.3.1-10.el7.x86_64 On a fresh install of DS there is no userpassword in pluginargs by default: $ ldapsearch -h localhost:389 -D "cn=Directory Manager" -w Secret123 -LLL -b 'cn=7-bit check,cn=plugins,cn=config' dn: cn=7-bit check,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: 7-bit check nsslapd-pluginPath: libattr-unique-plugin nsslapd-pluginInitfunc: NS7bitAttr_Init nsslapd-pluginType: betxnpreoperation nsslapd-pluginEnabled: on nsslapd-pluginarg0: uid nsslapd-pluginarg1: mail nsslapd-pluginarg2: , nsslapd-pluginarg3: dc=example,dc=com nsslapd-plugin-depends-on-type: database nsslapd-pluginId: NS7bitAttr nsslapd-pluginVersion: 1.3.3.1 nsslapd-pluginVendor: 389 Project nsslapd-pluginDescription: Enforce 7-bit clean attribute values $ ldapmodify -D 'cn=Directory Manager' -w Secret123 -H ldap://localhost:389 -a << EOF dn: uid=user1,ou=People,dc=example,dc=com objectClass: inetUser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: user1 sn: user1 uid: user1 userpassword: パスワード EOF adding new entry "uid=user1,ou=People,dc=example,dc=com" $ ldapsearch -h localhost:389 -D "uid=user1,ou=People,dc=example,dc=com" -w 'パスワード' -LLL -b 'dc=example,dc=com' uid=user1 dn: uid=user1,ou=People,dc=example,dc=com objectClass: inetUser objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: user1 sn: user1 uid: user1 Bind works with non-ascii userpassword. Marking as VERIFIED.
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://rhn.redhat.com/errata/RHSA-2015-0416.html