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

RE: password policy enforcement

At 09:38 AM 2/29/00 -0800, Dustin Sallings wrote:
>On Tue, 29 Feb 2000, Kurt D. Zeilenga wrote:
># The attributes should be operational and, hence, not require
># modification of existing object classes.
>	Where can I learn more about operational attributes?  I'm new
>here.  :)

ITU X.500 documents...  available for a fee from <http://www.itu.org/>.
You might also check your local bookstore for books on X.500.

># The frontend does not know or care if there is an entry associated
># with DN.  An entry is not required to allow authentication.
>	This makes sense given that the manager login doesn't necessarily
>have an entry associated with it.

Or a backend which does nothing but provide authentication using
some external service.

Not also that we also support external authentication services.
In such cases, we do want to cooperate with their password policy

>Where are they connected when it does exist, though?

They? who?

>I'm trying to figure out the point I can start working
>without having to read and understand the whole code base first.

I think the place to start is specification of schema, not code.
Hence my reference to the password policy I-D.  Note, though,
the I-D needs LOTS of work.

>I thought it would be appropriate to ask before diving in so you guys could
>make suggestions as to how I should do it so I don't go about
>implementing something nobody else will ever see.

Always wise...  I suggest looking at slapd/bind.c,
slapd/back-ldbm/bind.c, and slapd/passwd.c to get an
understanding of the flow of the bind process WHEN an
entry containing a userPassword attribute is involved.