Subject: Re: [ldapext] Password Policy draft 9

From: Howard Chu <[email-masked]>
Date: Thu, 01 Sep 2005 13:29:03 -0700

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? (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.)

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Ludovic Poitou <[email-masked]>
Date: Fri, 02 Sep 2005 13:07:28 +0200

Howard Chu wrote:

> 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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 02 Sep 2005 13:38:37 -0700

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 06 Sep 2005 11:26:27 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 9/2/05 2:38:37 pm >>>
there.)
>specified to be consistent with the standardized admin
I agree. Perhaps the specification needs to be more clear that the
value of a pwdPolicySubentry attribute is determined by the subtree
specification of the governing password policy subentry. On the other
hand, I dislike re-describing the nature of things already discussed in
other specifications.
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext