Re: [ldapext] password policy administrative operations

[Ludovic Poitou <ludovic.poitou@Sun.COM>]

John McMeeking wrote:

> There are some administrative operations that are not addressed by the
> password policy draft.
>
>  
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.


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

> 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
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
>  

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