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
