directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: pwdMustChange not working
Date Tue, 10 Mar 2015 01:28:12 GMT
Thanks for your responses. Our logic assigns the pwdPolicySubEntry attribute value for a user
from one of many policies. 
Please don't take away the ability to write to it :) 

-----Original Message-----
From: Kiran Ayyagari [] 
Sent: Monday, March 09, 2015 6:06 PM
Subject: Re: pwdMustChange not working

On Tue, Mar 10, 2015 at 5:11 AM, Emmanuel Lécharny <>

> Le 08/03/15 05:33, brock samson a écrit :
> > Carlo,
> >
> > you are correct. pwdSafeModify value was TRUE. so after resetting it
> back to FALSE and restarting, everything is working as you described 
> in your last post, thank you!
> >
> > however, the question remains to everyone else about pwdSafeModify
> attribute's value being TRUE and an admin changing some user's 
> password via apache studio. as i stated in previous post, such action 
> results in an error where apache studio asks for user's original 
> password. my question is how to disclose this original password in apache studio?
> I strongly suspect that the implemented logic is that it's seen as a 
> Modify, thus it expect to have the old value - to delete it - and the 
> new one ) to replace it.
> The thing is that a user may have more than one password, and on a 
> modify operation, changing only one of the passwords will require to 
> know whci of the passwords have to be removed (the old one).
> Now, considering the passwordPolicy implementation, this makes no 
> sense
> : we should only have one single password for a user for the PP to be 
> able to manage correctly the password, thus requiring the old password 
> is nonsensical.
> This is something that need to be fixed.
> There is also one other thing that I don't like in the way the PP is 
> handled : one should never have to enter the pwdPolicySubEntry 
> attribute
this attribute is not needed at all unless there is a custom policy to be applied on a user

> in an entry. But this is another problem that requires a full redesign 
> off the PP implementation. Something we must discuss, it's not a 
> simple task...

Kiran Ayyagari
View raw message