Hi, ok we've been through all our tests and it all seems to work! Thanks Karin!
Only think that got us hung up was using the ads-pwdsafemodify=TRUE which we would like to do but could not figure out using the JNDI api how to get that to work. Is there a small code snip of how that's done? For now we have it disabled. Regards, Carlo Accorsi -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kiran Ayyagari Sent: Monday, October 08, 2012 10:01 AM To: [email protected] Subject: Re: Changing password as user does not clear pwdGraceUseTime and update pwdChangedTime Hi Carlo I have committed a big chunk of code[1] that fixes many ppolicy related issues can you verify if the below mentioned issue still exists? [1] http://svn.apache.org/viewvc?rev=1395348&view=rev On Fri, Oct 5, 2012 at 9:08 PM, <[email protected]> wrote: > Ok thanks! > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Kiran Ayyagari > Sent: Friday, October 05, 2012 10:49 AM > To: [email protected] > Subject: Re: Changing password as user does not clear pwdGraceUseTime > and update pwdChangedTime > > I will look into it this weekend and let you know > > On Fri, Oct 5, 2012 at 8:15 PM, <[email protected]> wrote: >> Hi, I started this thread a while ago but I still have the problem. I tried >> to document as much as possible the scenario in a JIRA I just created. >> In short, the password is reset, but the multi value attribute >> pwdGraceUseTime is not removed. >> >> https://issues.apache.org/jira/browse/DIRSERVER-1750 >> >> I'm running a M8 built from the trunk on 9/10 . >> >> I think in the test testGraceAuth() adding the following line might lead >> to the issue. >> >> policyConfig.setPwdMustChange(true); >> >> Let me know if you need more information. Thank you! >> >> Regards, >> Carlo Accorsi >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Kiran Ayyagari >> Sent: Tuesday, September 04, 2012 3:58 AM >> To: [email protected] >> Subject: Re: Changing password as user does not clear pwdGraceUseTime >> and update pwdChangedTime >> >> the pwdGraceUseTime attribute should get deleted if the modification >> succeeds, are you sure that the modification done by user is successful? >> >> I have added a test case testGraceAuth() in PasswordPolicyTest in core-integ >> to demonstrate that the said attribute gets deleted upon successful >> modification of userPassword attribute. >> >> On Tue, Sep 4, 2012 at 8:13 AM, <[email protected]> wrote: >>> Hi Folks - been away ApacheDS for a while.. back again.. >>> >>> We built from the trunk on Friday 8/24 and are testing the password policy >>> functionality. >>> >>> When a user has a password policy assigned via pwdPolicySubentry and >>> the policy attribute ads-pwdgraceauthnlimit is set to 5 for example, and >>> the password age has expired, a pwdGraceUseTime field (on the user) is set >>> with the timestamp of the login. This is all working great! >>> >>> We process the response controls and that event forces a user to change >>> their password, which they successfully do. >>> >>> However, even though the password is successfully changed, the: >>> pwdGraceUseTime fields are not removed and pwdChangedTime does not >>> update. >>> >>> A subsequent login by the user with the new password (just set) triggers >>> the same response controls and the process repeats, setting another >>> pwdGraceUseTime field. >>> I'm not running out of grace logins. When this happens it's understood >>> nothing can be done without an admin reset. >>> >>> If an admin changes the password, the fields are removed and the >>> pwdChangedTime field is updated as it should. >>> We need the password reset as the user because we're also using the >>> pwdReset functionality . >>> >>> >>> This is how we're changing the passwords. This operation performed with the >>> user's credentials NOT an admin. >>> >>> public void setPassword (LdapContext ctx,String strDn, String >>> strValue) >>> throws DirectoryAdapterException{ >>> >>> ModificationItem[] mods = new ModificationItem[1]; >>> mods[0] = new ModificationItem(LdapContext.REPLACE_ATTRIBUTE, >>> new BasicAttribute(PASSWORD_AT, strValue)); >>> try { >>> try { >>> // set control in here. >>> ctx.setRequestControls(new Control[]{new >>> PasswordPolicyRqControl()}); >>> ctx.modifyAttributes(strDn, mods); >>> } catch (InvalidAttributeValueException ae){ >>> throw new >>> DirectoryAdapterException(ae,DirectoryAdapterException.CANNOT_MODIFY_ENTRY); >>> } catch (NamingException ne){ >>> throw new >>> DirectoryAdapterException(ne,DirectoryAdapterException.CANNOT_MODIFY_ENTRY); >>> } >>> }catch (DirectoryAdapterException de){ >>> processControls(ctx, de); // will re-throw >>> throw de; // catch all, should not happen. >>> } >>> } >>> >>> Thank you!!! >>> >>> >>> >> >> >> >> -- >> Kiran Ayyagari >> http://keydap.com > > > > Kiran Ayyagari > http://keydap.com -- Kiran Ayyagari http://keydap.com
