[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: password policy enforcement
On Tue, 29 Feb 2000, Howard Chu wrote:
In this scenario, how would I handle a replicate slave? I really
don't want them changing if the master doesn't change. Are you saying
there's no place in slapd itself I can store login failure counts?
# 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 enforcement logic can all be encapsulated in bind.c
# in the respective backends. (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 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.
#
# 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. If it had been structured such that all results
# were returned to the slapd mainline, then it would be simple for a single
# generic frontend "bind" routine to fetch bindDN entries from any particular
# backend, do all the boilerplate password validation, etc., without it
# needing to be redundantly managed in each individual backend. If ACL
# checking were consolidated in the front end, then the generic frontend bind
# would also have no trouble storing the updated entries back into their
# respective backends as bookkeeping items were recorded. Need more time...
#
# -- Howard Chu
# Chief Architect, Symas Corp. Director, Highland Sun
# http://www.symas.com http://highlandsun.com/hyc
#
# > -----Original Message-----
# > From: owner-openldap-devel@OpenLDAP.org
# > [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Dustin Sallings
# > Sent: Tuesday, February 29, 2000 2:15 AM
# > To: openldap-devel@OpenLDAP.org
# > Subject: password policy enforcement
# >
# >
# >
# > Hi, I brought this thread up in openldap-general and it was
# > suggested that I bring it over here.
# >
# > This is my most basic set of needs:
# >
# > Ability to lock and unlock authentication for an entry.
# > Ability to have an entry autolock on failure (x bad passwords).
# >
# > This is pretty important to me, and I don't mind doing the work, but I'd
# > like existing developers to give me an idea of what the scope is, and what
# > the right way to wedge it into the existing code base might be. Thanks a
# > lot.
# >
# > --
# > dustin sallings The world is watching America,
# > http://2852210114/~dustin/ and America is watching TV.
# >
# >
#
#
--
dustin sallings The world is watching America,
http://2852210114/~dustin/ and America is watching TV.