Re: [ldapext] Password Policy draft 9

[Ludovic Poitou <Ludovic.Poitou@Sun.COM>]

Howard Chu wrote:

> After adopting the schema changes in draft 9 we ran into a new issue; 
> the pwdAccountLockedTime operational attribute is now marked 
> NO-USER-MODIFICATION. Should this attribute be automatically removed 
> when a password change is successfully performed?

Yes, i believe that this is desireable (and that's what we've implemented).
However, there should also be a way to unlock an account without 
requiring a change in the password. A user should not be "punished" and 
have his pasword changed everytime the server is subject to an attempt 
of a dictionary attack.

> (I.e., give it the same treatment as pwdFailureTime and 
> pwdGraceUseTime which are removed upon successful password change.) 
> Otherwise it's not clear that a password administrator can re-enable 
> an account using the currently defined protocol operations, and 
> requiring a manipulation outside the protocol seems wrong.


> I have the same concern with pwdPolicySubentry, which seems to me to 
> require manual setting. (For all the other non-modifiable attributes, 
> they have clearly defined automated behaviors, so there's no issue 
> there.)
In our implementation the pwdPolicySubentry can be set via our 
implementation of collective attribute, or manually...
But I would expect some servers to have the attribute fully handled by 
the server.

Ludovic.

--
Ludovic Poitou                                    Sun Microsystems Inc.
Software Architect                               Directory Server Group
http://blogs.sun.com/Ludo/                             Grenoble, France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext