Re: [ldapext] Re: Password Policy for LDAP Directories

[Neil Dunbar <neil.dunbar@hp.com>]

On Fri, 2004-09-10 at 00:28, Andrew Sciberras wrote:

> The solution to this is certainly consistency. There are two paths that 
> you could go down:
>      * Consistently expire at the MaxAge time, which is how you describe 
> IBM's solution.
>      * Always provide a warning time of pwdExpireWarning seconds.

> I would argue that the way that the Tivoli Directory Server handles this 
> is incorrect. It's my opinion, which also reflects our implementation, 
> that the second option is preferable. For example, imagine that a server 
> has the following rules:
>      pwdMaxAge -> 500 seconds
>      pwdExpireWarning -> 100 seconds
> 
> And the user logs on for the first time at t=495, then they should 
> receive a whole 100 seconds to change their password, instead of the 5 
> seconds that the Tivoli Directory Server would provide.

Hmm. I'm not so sure. Are you saying that if you've passed the maximum
age, then you go into the "grace login" period, where the only allowable
operation is to change your password? If so, does that get overridden by
the "number of grace logins" setting in the password policy? If not,
then the maximum age of the password is not a boundary on the worthiness
of the password. I'd argue that this would be a bad thing.

The pwdMaxAge should be the absolute maximum time that the password can
be used by anyone as a credential. The pwdExpirationWarning time, I
think, should be the earliest opportunity that the directory server can
warn the user that his/her password is approaching expiry. If the user
comes into the expiry period late in the game - tough. You can always
use the grace logins feature to allow the user with the dud password to
change it after it has ceased to be a meaningful credential for general
directory operations.

When I prototyped the code for the password policy module for OpenLDAP,
I used the same logic as the Tivoli system. I tried to make sense of the
I-D, but couldn't turn it into clear code. That said, since Howard Chu
of Symas rewrote the prototype into a real module, he may have altered
the logic. I'll check later.

Cheers,

Neil


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