Re: [ldapext] Password Policy operational attributes

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

Draft 9 has not been published yet. Still working on it.

Adding the NO-USER-MODIFICATION keyword to the state information would 
prevent administrators to update the attributes for unlocking a user for 
example, and would probably require the introduction of a set of 
administration procedures for  password policy management, such as 
unlocking a locked account ...
The security considerations mention that ACI should be used to restrict 
access to the state attributes. I think that the security considerations 
need a little bit of work for clarification of the security issues and 
the recommandations.

Ludovic



Howard Chu wrote:

> I vaguely recall someone mentioning that the policy schema would be 
> updated again for draft 9, but I can't seem to find it in my mailbox 
> now. (So was I just imagining it?) Anyway, it seems that the state 
> information needs to be defined with NO-USER-MODIFICATION in order to 
> serve its purpose, otherwise any user with write access to their own 
> entry can circumvent most of the policies.

--
Ludovic Poitou
Directory Architect.
Directory Server Group, Grenoble, France
Sun Microsystems Inc.

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