Bug 248924 - should support to change the password after reset by using password modify extension
should support to change the password after reset by using password modify ex...
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.0.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
: 235532 (view as bug list)
Depends On:
Blocks: 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2007-07-19 13:00 EDT by Masato Taruishi
Modified: 2015-01-04 18:27 EST (History)
6 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:00:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Enable to operate password modify extension and start_tls in chage after reset case (1.79 KB, patch)
2007-07-19 13:11 EDT, Masato Taruishi
no flags Details | Diff
Using connection's c_dn for checking for rootdn (2.32 KB, patch)
2007-07-20 06:43 EDT, Masato Taruishi
no flags Details | Diff
CVS Diffs (5.84 KB, patch)
2009-01-15 18:39 EST, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Masato Taruishi 2007-07-19 13:00:36 EDT
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:
Comment 1 Masato Taruishi 2007-07-19 13:11:18 EDT
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.
Comment 2 Rich Megginson 2007-07-19 13:32:56 EDT
(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.

Comment 3 Masato Taruishi 2007-07-19 23:05:52 EDT
(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
Comment 4 Masato Taruishi 2007-07-20 05:55:00 EDT
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. 
Comment 5 Masato Taruishi 2007-07-20 06:43:36 EDT
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.
Comment 9 Nathan Kinder 2009-01-15 14:56:50 EST
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.
Comment 10 Nathan Kinder 2009-01-15 18:39:28 EST
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.
Comment 11 Nathan Kinder 2009-01-16 00:27:29 EST
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
Comment 12 Jenny Galipeau 2009-04-06 10:21:27 EDT
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
Comment 13 Nathan Kinder 2009-04-06 11:44:29 EDT
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'
Comment 14 Jenny Galipeau 2009-04-06 12:27:27 EDT
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
Comment 15 Rich Megginson 2009-04-09 13:19:34 EDT
*** Bug 235532 has been marked as a duplicate of this bug. ***
Comment 17 Chandrasekar Kannan 2009-04-29 19:00:39 EDT
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

Note You need to log in before you can comment on or make changes to this bug.