Re: NT Domain backend

["Kurt D. Zeilenga" <kurt@boolean.net>]

Mark Valence wrote:
> This is configurable.  I'll change the examples to use "dc=".  What
> is the proper objectclass for objects whose dn starts "dc=" ?  Does
> it matter?

Well, all entries need to have structure.  Something like "domain"
or "organizationalUnit" would likely be appropriate.  If the structural
object class doesn't support dc naming, then you should mix in
dcObject auxiliary object class.

> I'll take a look at inetOrgPerson and see if anything can be used
> from that, but there will still be some needed attributes.  If we
> don't use the MS attributes (or give the option not to use it), then
> does that mean we supply our own attributes, with OIDs from the
> OpenLDAP arc?

Well, the key here is that we want to favor standard-track schema
over informational (non-proprietary) schema over informational
(proprietary) over vendor (OpenLDAP) schema [over private (user) schema].

So, I would favor using MS schema over defining our own schema.

However, only schema which is well documented should be considered.
That is, the schema must be published (by the OID holder or delegate)
in a document to which we can reference in our documents.  To consider
distribution of MS schema, we must have a MS document which is
publicly available (preferably without fee).

> I guess the backend would then look at the schema data structures to
> determine which OIDs/attributes are available, and use whatever is
> there.

Just because it's there doesn't mean it what the user wants to use.
I suggest backend like password/ntdomain provide configuration support
as appropriate to switch between support schemas.  Of course, there
is some point where it's not feasible to support such switching
(except by hacking code).

My advice here is to think "open" and to code in "flexibility".
However, there are realities of time and energy limitations which
necessity less configurable solutions.