[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Password Policy operational attributes
I only see two operational attributes that arguably should be modifiable:
pwdReset and pwdAccountLockedTime. And pwdAccountLockedTime might be
modifiable only certain conditions:
pwdAccountLockedTime - arguably could be set to 000001010000Z to lock the
account, or the attribute deleted to unlock an account. I see no reason
why a server should allow it to be set to other values.
So, should a server allow pwdReset and pwdAccountLockedTime values to be
changed via a modify request? Or should this be an extended operation? It
doesn't matter much to me, but the document probably ought to state that
these values can be modified if that is the intent. I think its leaving to
much to the imagination of the implementer to expect interoperability when
two of the attributes might possibly require different behavior than the
others.
I don't see a reason why pwdChangedTime, pwdFailureTime, pwdHistory or
pwdGraceUseTime (and definitely not pwdPolicySubentry) should be user (or
administrator) modifiable under any conditions.
John McMeeking
ldapext-bounces@ietf.org wrote on 11/22/2004 07:18:34 AM:
> 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
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext