On Tue, Oct 16, 2012 at 3:13 AM, <[email protected]> wrote: > 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. > currently there is no support for password safe modification > 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
-- Kiran Ayyagari http://keydap.com
