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 Mon, 08 Oct 2012 14:22:01 GMT
Awesome!!  I will check out and try.  Thanks Karin!



-----Original Message-----
From: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] On Behalf Of Kiran Ayyagari
Sent: Monday, October 08, 2012 10:01 AM
To: users@directory.apache.org
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,  <Carlo.Accorsi@ibs-ag.com> wrote:
> 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



--
Kiran Ayyagari
http://keydap.com

Mime
View raw message