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 Tue, 04 Sep 2012 12:42:55 GMT
Yes, I'm sure it's changed because we login immediately afterwards with the new password. Also,
I've gone into Directory Studio and validated it there. 
I'm using JNDI LdapContext.modifyAttributes(strDn, mods); to change it. Does that or could
that matter? I'll try the test. Thanks. 

-----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