Subject: [ldapext] password policy administrative operations

From: John McMeeking <[email-masked]>
Date: Fri, 16 Jan 2004 11:16:48 -0600

There are some administrative operations that are not addressed by the
password policy draft.

- Can an account be unlocked after being locked due to failed requests?  If
so, is this done by having the administrator reset the password?  Or should
there be another way to unlock the account without changing the password?
Perhaps an extended request?  Modify requrest to delete the
pwdaccountlockedtime attribute?

- Is there a way to prevent passwords from expiring on specific accounts?
One obvious way is to place these accounts where the password policy
doesn't apply, but I think a more appropriate approach would be a property
of the account -- some combination of operational attributes
(pwdneverexpires=TRUE?) and / or extended operations (some sort of "set pwd
attributes" extended operation?).

There's probably others, but these are items I have encountered as folks
look at implementing pwd policy in their organizations.

John  McMeeking

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

---

From: Ludovic Poitou <[email-masked]>
Date: Fri, 16 Jan 2004 19:24:01 +0100

>There are some administrative operations that are not addressed by the
I agree... I think that the draft is already too complex and too long 
and if we are starting to add all the administrative operations that can 
be done on the password policy, we will end up with a book. :-)

We tried to describe a schema for defining a policy and a schema 
(operational attributes) for enforcing the policy.
We tried to describe what the server should do with these attributes to 
have consistent behavior and security between level between 
hetereogenous servers.
I'm not sure we really want to describe administrative operations. If we 
were to define all administrative operations, i would do it with 
extended operations and would certainly remove all the operational 
attributes and related description to let implementors choose their own 
design.
This would certainly bring interoperability from a client application 
point of view but will prevent replication / synchronization between 
different vendors.

>pwdaccountlockedtime attribute?
This may be a choice of the user of the password policy. Some customers 
may request to have the password changed after it's been locked due to 
failures. Some other customers may just want to be able to remove the 
lock and don't change the password.
Should we really mandate all Administrative operations ?

>- Is there a way to prevent passwords from expiring on specific accounts?
How about defining a specific password policy for those account with no 
expiration of the password ?
Not all entries have to obey the same policy.

Ludovic.

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