directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Changing password as user does not clear pwdGraceUseTime and update pwdChangedTime
Date Fri, 05 Oct 2012 14:45:37 GMT
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.

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. 


Let me know if you need more information. Thank you!

Carlo Accorsi

-----Original Message-----
From: [] On Behalf Of Kiran Ayyagari
Sent: Tuesday, September 04, 2012 3:58 AM
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,  <> 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,
>             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

View raw message