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

Reply via email to