Subject: [ldapext] Password Policy - locking accounts

From: John McMeeking <[email-masked]>
Date: Thu, 4 Sep 2003 07:38:38 -0500

Is the notion of an administrator locking/unlocking (i.e. enable/disable
for authentication) an entry within the scope of the password policy draft?
This seems like a logical addition and a reasonable candidate for something
to be done in a standard way.

If folks agree, I suggest adding an extended operation to lock or unlock a
given entry.

On a related note, it is common to be able to set "password must be reset"
on a per user basis -- for example setting the password for an entry to be
used by an application.  This could be done by modifying the pwdReset
attribute, in which I think it would be appropriate for password policy to
specify that servers may allow this attribute to be modified.  Or another
extended operation; I don't have any good guidelines for when I think an
extended operation is more appropriate than modifying what has so far been
presented as a "status" attribute -- though I didn't see any
"NO-USER-MODIFICATION" atttached to any of these attributes.

John  McMeeking

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

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 04 Sep 2003 17:03:24 +0200

>If folks agree, I suggest adding an extended operation to lock or unlock a
I don't believe that enabling / disabling an account for authentication 
is part of the password policy.
I think it is more of a question of a login policy (ie one would like to 
enable / disable only some part of the day, or during week ends...).
This is outside the scope of the password policy document.

>"NO-USER-MODIFICATION" atttached to any of these attributes.
Our implementation allows administrators to modify the operational 
attributes. It's easier than extended operation and more coupled with 
Access Controls.
Extended operations are more complex to build in clients and SDKs and 
Access Controls are to be set for each extended operation as well.

I agree that we should add some text in the draft regarding the 
possibility to modify some of the attributes.

Ludovic.

-- 
Ludovic Poitou
Sun Microsystems Inc.
Sun ONE products - Directory Server Group - Grenoble - France

---

From: "Andrew Sciberras" <[email-masked]>
Date: Fri, 5 Sep 2003 08:10:38 +1000

Hi John!

>to be done in a standard way.

The draft specifies an attribute called pwdAccountLockedTime which holds the
time at which the user's account was locked.
The draft states the following about the operational attribute (Section
4.3.3):

>A 0 value means that the account has been locked
>permanently, and that only an administrator can unlock the account.

Since 0 isn't a valid GeneralizedTime value, I assume it means 00000101000Z.
In any case, the administrator could simply set this attribute to the zero
value in an account, which would effectively provide an administrator with
the power to lock/unlock an entry.

>John  McMeeking

Andrew Sciberras