From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070508 Iceweasel/2.0.0.4 (Debian-2.0.0.4-1) Description of problem: The current implementation of fedora-ds doesn't accept the Password Modify Extended Operation for chainging her or his own password in the case of 'Change After Reset' defined in Password Policy Management, but I think it should support this case because clients using only password mofiy extension doesn't work well when directory administrators require the policy that any password must be changed after reset. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Set the passwordMustChange flag on in dse.ldif: 2. /etc/init.d/fedora-ds restart 3. Create a user with initial password by administrator. 4. Try to change the password by the user itself by using Password Mofity Extension. Actual Results: UNWILING_TO_ERFORM would return Expected Results: should success Additional info:
Created attachment 159596 [details] Enable to operate password modify extension and start_tls in chage after reset case I wrote a simple and little ad-hoc patch to support to change the password in the case of 'change after reset' by using password mofify extension. I also had to handle start tls extension because the current implementation requires secure connection for password modify extension. By the way, I guess that fedora-ds should also support open standard policy handling such as: https://opends.dev.java.net/public/standards/draft-behera-ldap-password-policy.txt It's been just an internet draft, but at least openldap support this draft.
(In reply to comment #1) > Created an attachment (id=159596) [edit] > Enable to operate password modify extension and start_tls in chage after reset > case Thanks! > > I wrote a simple and little ad-hoc patch to support > to change the password in the case of 'change after reset' > by using password mofify extension. I also had to handle > start tls extension because the current implementation > requires secure connection for password modify extension. > > By the way, I guess that fedora-ds should also support open > standard policy handling such as: > > https://opends.dev.java.net/public/standards/draft-behera-ldap-password-policy.txt > > > It's been just an internet draft, but at least openldap support > this draft. So does Fedora DS.
(In reply to comment #2) > > I wrote a simple and little ad-hoc patch to support > > to change the password in the case of 'change after reset' > > by using password mofify extension. I also had to handle > > start tls extension because the current implementation > > requires secure connection for password modify extension. > > > > By the way, I guess that fedora-ds should also support open > > standard policy handling such as: > > > > https://opends.dev.java.net/public/standards/draft-behera-ldap-password-policy.txt > > > > > > It's been just an internet draft, but at least openldap support > > this draft. > > So does Fedora DS. Yeah, but unlike the above simple patch, the latest password policy may affect the compatibility to the current policy specification. You have to implement this carefully which may cause to take a long time to release this feature. BTW, I'm now writing a client which uses password modify extension and faced in this problem. So I hope that at least the above simple patch would be applied to the next fedora-ds release so that the client can only work on the release version of fedora-ds. Thanks
Ah, sorry. This patch doesn't work correctly because passwd_extop uses slapi_modify_internal_pb which always accesses as root. This means update_pw_info() always recognizes all the modify operations as password reset.
Created attachment 159641 [details] Using connection's c_dn for checking for rootdn How about this patch? This patch propagates the original connection to the update_pw_info() so that it can recognize password reset case correctly.
The behavior with the current DS code is a bit different than originally reported. I am able to reset the userPassword using the password modify extended operation, but it doesn't unlock the account. It seems to be treating it as if the "cn=Directory Manager" account reset the user's password instead of the user themselves. This is likely due to the fact that an internal modify operation is used to perform the actual userPassword modification.
Created attachment 329152 [details] CVS Diffs This patch takes the same approach as Taruishi-san's second patch, but I made a few modifications. The fix is to copy a reference to the connection object from the original pblock into the pblock used for the internal modify operation. This allows the password policy code to determine who initiated the password change for an internal operation. The things I changed from the original patch were to clear out the reference to the connection object from the pblock once we're done with the internal modify operation. I also changed the condition checking in the password policy code so internal operations without a connection object (which should be the norm) are still assumed to be initiated by the root DN.
Checked into ldapserver (HEAD). Thanks to Rich for his review! Checking in ldap/servers/slapd/passwd_extop.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/passwd_extop.c,v <-- passwd_extop.c new revision: 1.20; previous revision: 1.19 done Checking in ldap/servers/slapd/pw.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/pw.c,v <-- pw.c new revision: 1.20; previous revision: 1.19 done
steps used to verify: 1. ssl secure directory server 2. set global password policy on and passwordMustChange on passwordInHistory: 6 passwordUnlock: on passwordGraceLimit: 0 passwordMustChange: on passwordWarning: 86400 passwordLockout: off passwordMinLength: 8 passwordMinDigits: 0 passwordMinAlphas: 0 passwordMinUppers: 0 passwordMinLowers: 0 passwordMinSpecials: 0 passwordMin8bit: 0 passwordMaxRepeats: 0 passwordMinCategories: 3 passwordMinTokenLength: 3 passwordMaxFailure: 3 passwordMaxAge: 8640000 passwordResetFailureCount: 600 passwordisglobalpolicy: off passwordChange: on passwordExp: off passwordLockoutDuration: 3600 passwordCheckSyntax: off passwordMinAge: 0 passwordStorageScheme: SSHA 3. add new user and set user password 4. root@jennyv2 slapd-jennyv2]# /usr/lib/mozldap/ldappasswd -Z -p 636 -D "uid=dduck,ou=people,dc=example,dc=com" -w redhat ldappasswd: Password has been reset by an administrator; you must change it. ldappasswd: password successfully changed New password: @0A4EDpH Why is the password being changed for me? passwordChange is on
The (In reply to comment #12) > > Why is the password being changed for me? The server will generate a new password for you if you don't send a new password with the password modify extended operation. You can use the following options with the mozldap ldappasswd tool to specify the new password: -s passwd new password -S prompt for new password -T file read new password from 'file'
fix verified DS 8.1 RHEL 5 [root@jennyv2 slapd-jennyv2]# /usr/lib/mozldap/ldappasswd -Z -p 636 -D "uid=dduck,ou=people,dc=example,dc=com" -w redhat -S New Password: Re-enter new Password: ldappasswd: Password has been reset by an administrator; you must change it. ldappasswd: password successfully changed
*** Bug 235532 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html