[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: password policy enforcement

At 02:45 AM 2/29/00 -0800, Howard Chu wrote:
>Seems like a reasonably inobtrusive enhancement. Define a couple new
>attributeTypes (for example):
>    loginDisabled (boolean) - is the account locked?
>    loginFailures (integer) - how many failures have there been?
>    loginMaxFailures (integer) - how many allowed before autolock occurs?
>Ideally "loginFailures" would be an operational attribute, but I don't think
>it's a big problem.
>Assuming you massage your users' objectclasses appropriately to allow for
>your new attributes,

The attributes should be operational and, hence, not require modification of
existing object classes.

>the enforcement logic can all be encapsulated in bind.c
>in the respective backends.

Yes.  But using common utilities.

>(It would of course be nice if you could  put it
>in the slapd front end, so that any/all backends can use it. I don't see an
>easy way to do this, though.)

The frontend does not know or care if there is an entry associated with
DN.  An entry is not required to allow authentication.

>The code in bind already has to retrieve an
>entry for the DN in question, so you can readily pull the current state of
>any locking attributes. Storing the modified attributes when login failures
>occur shouldn't be too hard either.

One thing I'd like to point out is that directory management of password
policy makes the most sense when the passwords are stored in the directory
entry associated with the identity being authenticated.  Note, however,
that the entry (if one) may not contain that password itself, but a
reference to the password.  In such cases, the service providing the
password should be relied on to provide policy (for consistency).
Also, the identity may not even represent a directory entry.  This is
another case were password policy should likely be left to the underlying
authentication service.

>I really wish the backend architecture wasn't modeled on the notion of
>individual backends being individual DSAs, sending results to the client
>independently of each other.

I'll leave this discussion for a later day.