[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Setting up the LDAP Directory Design
One option would be to stick with what you have - set up 2 suffixes (I think
you can do this on NS DS 3.x - DS 4.x does support this). I.e, One company
is o=company1, the other is o=company2. You have 2 distinct trees, one for
each company. This makes it easy to move these so each company is hosted on
different servers, such as if the companies each go their own way. However,
for searches, you can's search across 2 suffixes. To allow users to see
both, say in Communicator's address book or a cgi interface, you can create
2 entries, one with a base dn of o=company1, the other with o=company2.
Users would pick the appropriate address book to search one company or the
other. For some this is preferable, for others, this won't do. This is
probably the simplest to implement.
Another option is to create a suffix that represents all your companies -
i.e., if these both fall under a parent company, make "o=parentcompany", and
under that have "ou=company1, o=parentcompany", and "ou=company2, o=parent
company", placing each entry as separate branches under the parent, in a
single tree. You can search across all entries, but it's harder to break
these off to separate servers, esp if you want to keep the searching
capability across companies.
You can also have something like the above, but have 3 suffixes/trees -
"o=parentcompany", "ou=company1, o=parentcompany", "ou=company2,
o=parentcompany" as 3 separate suffixes, and define referals between them
such that the mapping hands things off to the right place. This gets kinda
complicated getting all the referals set up, and I think referals are mainly
LDAP v3 (forget where/when they are "safe" to use), and you may be
restricted to v3 servers and clients. However, it may make things easier to
break off later. I can't tell you a lot about referals - personally, I
haven't used them yet.
Another option is to have "o=companies" - something generic - and have a
single, common tree. Within each record, create a "companyid" attribute, so
each record can be assigned to a company. The easiest way to do this is to
modify your schema to add an objectclass like "companyinfo" that has a
companyid attribute. Anything you tie directly to a company would add this
objectclass and attribute. To find people by company, add
(companyid=<compid>) to your search filters. For performance, you may need
to index the companyid field. If it is acceptable in your case, this is
nice because it keeps the tree flat and simple, and makes it very easy to
move resources/people betweeen companies.
Stanley Weilnau wrote:
> I am setting up an LDAP server that will support 2 companies using
> Netscape Directory Server 3.1. The instructions show how to do a single
> company by using o=company1 as the base. I want to set up a single LDAP
> directory that has some different base and multiple o='s. I want the
> users to see all of the names (one company has ~40 people and the other
> ~10) at once.
>
> This is currently only for internal use, but I want to make
> it flexible enough that I can add an external LDAP server that can
> interoperate with it at a much later date.
>
> Any suggestions?
>
> Stanley Weilnau