[Date Prev][Date Next]
Re: NT Domain backend
>A few more details: the domain backend can handle multiple domains,
>each of which is in it's own OU. Also, users and groups can be put
>into separate OUs. So you can get dns that look like:
> cn=John Doe, ou=People, ou=MyDomain, o=MyCo, c=US
>That's all configurable, but you get the idea.
It might be interesting to limit each database to one domain
but to allow multiple databases to be configured as needed.
You can have multiple domain backends, each serving as many domains
as you want.
I would also suggest using dc style naming (to be consistent
with other examples). That is: dc=MyDomain, dc=MyCo, dc=COM
in examples and docs. Of course, users can should be able to
whatever naming they choose.
This is configurable. I'll change the examples to use "dc=". What
is the proper objectclass for objects whose dn starts "dc=" ? Does
Avoid umich schema. We hope to eliminate all umich schema items
for 2.0 (in favor of standard-track items).
Hopefully inetOrgPerson will be published as an RFC soon.
OK, I'll make sure not to use umich stuff. I don't think umichPerson
had anything interesting (for NT domains) in it anyway, so I didn't
>I agree that back-domain and back-passwd should share where possible,
>especially if we cannot get a list of the oc's/attributes that MS
Even if we can get MS schema items, I rather we encourage use of
standard track items. This does not imply that we should not
create and distribute an "microsoft.schema" file and allow users
to use it. I just prefer that, by default, we use standard
track schema items.
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
I guess the backend would then look at the schema data structures to
determine which OIDs/attributes are available, and use whatever is
>I've attached the basic objectclass defs at the bottom of this
>message. Please send any comments, especially if you know of an
>existing person or group attribute that could be used instead of the
We'll need full schema defs for these items (ie: RFC2252 format).
Feel free to create in servers/slapd/schema:
microsoft.schema (new RFC2252 derived schema defs)
microsoft.at.schema (old format attribute types)
microsoft.oc.schema (old format object classes)
I'll start compiling a list (Jeremy Jones has agreed to help).