[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] Password Policy draft 9

At 04:07 AM 9/2/2005, Ludovic Poitou wrote:
>>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.

In the X.500 Admin Model, the entries controlled by a specific
subentry (holding collective, schema, password, etc. policy)
is controlled by the subtree specification associated with that
subentry.  Operational attributes which hold values referencing
which subentry is holding the controlling policy in each
controlled entry are maintained by the server through the
subtree specification, hence these attributes should not
be user modifiable.

While some servers don't follow the X.500 Admin Models, I
think all standardized policies should be designed and
specified to be consistent with the standardized admin
models.

Regarding the other operational attributes, such as
pwdAccountLockedTime, one should consider whether its
DSA administrated or user administrated.  It think its a
mistake to allow an attribute which administrated by
both user and server.  That is, I think there should be
a separate "account unlock" mechanism.   In considering
the design of this mechanism, one likely should consider
not only how an administrator (or other) unlocks a
single account, but groups of accounts or all accounts
controlled under a particular policy.

Kurt 


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