directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Carlo.Acco...@ibs-ag.com>
Subject RE: Changing password as user does not clear pwdGraceUseTime and update pwdChangedTime
Date Fri, 05 Oct 2012 15:38:56 GMT
Ok thanks!	

-----Original Message-----
From: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] On Behalf Of Kiran Ayyagari
Sent: Friday, October 05, 2012 10:49 AM
To: users@directory.apache.org
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,  <Carlo.Accorsi@ibs-ag.com> 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: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] On 
> Behalf Of Kiran Ayyagari
> Sent: Tuesday, September 04, 2012 3:58 AM
> To: users@directory.apache.org
> 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,  <Carlo.Accorsi@ibs-ag.com> 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

Mime
View raw message