Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/458 https://bugzilla.redhat.com/show_bug.cgi?id=856577 (''Red Hat Directory Server'') {{{ 3. What is the nature and description of the request? For automated password reset procedures the hashed password has to be imported via ldif file into LDAP server. If password syntax check is enabled only the cn=directory manager is allowed to do it. but due to permission separation the import user should only have access to a certain tree in LDAP. 4. Why does the customer need this? (List the business requirements here) To support the following scenario: a) A password reset is triggered from another server. b) No interactive access is granted to the support personnel. They have to create an ldif file which is loaded into LDAP. c) LDAP is also used for the authentication of non-user sessions and all changes have to be done via ldif files. d) Due to security restrictions only hashed passwords are allowed in ldif files. 5. How would the customer like to achieve this? (List the functional requirements here) Add a special role for the admin user of LDAP subtree which allows them to bypass the hashed password check when loading an ldif file with hashed passwords. 6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. a) setup LDAP subtree b) create admin user c) activate password sytax check on subtree d) import ldif file with hashed passord by admin user -> should fail e) add special role to admin user d) import ldif file with hashed passord by admin user -> should work 7. Is there already an existing RFE upstream or in Red Hat bugzilla? Bug 843576, "RFE - forcing passwordmustchange attribute by non-cn=directory manager" / upstream <https://fedorahosted.org/389/ticket/417> is in a closely related are; perhaps this RFE can be merged with it. 8. Does the customer have any specific timeline dependencies? No. 9. Is the sales team involved in this request and do they have any additional input? The sales team is actively involved in this account, but not in this request specifically. 10. List any affected packages or components. 389-ds-base 11. Would the customer be able to assist in testing this functionality if implemented? Yes. }}}
I will refer design doc http://www.port389.org/docs/389ds/design/password-administrator.html and steps :: a) setup LDAP subtree b) create admin user c) activate password sytax check on subtree d) import ldif file with hashed passord by admin user -> should fail e) add special role to admin user d) import ldif file with hashed passord by admin user -> should work Removing needinfo flag.
Using normal user ==================== [root@dhcp201-126 slapd-dhcp201-126]# ldapmodify -h localhost -p 389 -D "uid=test1,dc=example,dc=com" -w Secret123 -a -f /export/users.ldif adding new entry "uid=sghai,dc=example,dc=com" ldap_add: Constraint violation (19) additional info: invalid password syntax - passwords with storage scheme are not allowed Using password admin user ============================== [root@dhcp201-126 slapd-dhcp201-126]# ldapmodify -h localhost -p 389 -D "uid=ami,dc=example,dc=com" -w Secret123 -a -f /export/users.ldif adding new entry "uid=sghai,dc=example,dc=com" adding new entry "uid=sghai1,dc=example,dc=com" adding new entry "uid=sghai2,dc=example,dc=com" adding new entry "uid=sghai3,dc=example,dc=com" adding new entry "uid=sghai4,dc=example,dc=com" adding new entry "uid=sghai5,dc=example,dc=com" [root@dhcp201-126 slapd-dhcp201-126]# cat /export/users.ldif # entry-id: 10 dn: uid=sghai,dc=example,dc=com cn: sghai sn: sghai givenName: sghai objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: sghai mail: sghai@example.com userPassword:: e1NTSEF9Ty9EZVdmdlIzU0JNOEUybVl3S2o4TG9zUG1XTGhqeGFyRks0OWc9PQ= = creatorsName: cn=directory manager modifiersName: cn=directory manager createTimestamp: 20141120130928Z modifyTimestamp: 20141120130928Z nsUniqueId: 6e02e684-70b611e4-b9bd8042-4ccbdcdd . . . . Hence 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