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

Re: NT Domain backend

At 12:41 PM 11/17/99 -0500, Mark Valence wrote:
>>At 11:53 AM 11/17/99 -0500, Mark Valence wrote:
>> >I've finished the first cut at an NT domain backend.  It is currently
>> >"read-only" although I will be adding editing capabilities later.  It
>> >does users and groups, works only when running slapd on WinNT, and
>> >only does binds when running as a service (this is a silly NT
>> >requirement).
>> >I am using oc's of person, organizationalPerson, and groupOfNames
>> >(yes, these should be configurable).  I also added new oc's to
>> >slapd.oc.conf, with corresponding new attributes, to support some
>> >information that is specific to NT users and groups.
>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.

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.

>>If at all possible, use standard-track schema.
>>If reasonable, I would like to see back-passwd and back-ntd
>>share the same base schema.
>I've used attributes already defined in person, organizationalPerson, 
>and groupOfNames.  The new oc's are just for NT-specific stuff.  I 
>also loked at things like umichPerson, residentialPerson, etc. to see 
>if I could use attributes from those oc's instead of adding new ones.

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.

>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'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 
>new attrs.

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)

Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>