Re: o and c or dc?

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

On Mon, Jan 12, 2004 at 03:35:43PM -0400, Ace Suares wrote:

> > The main difference is in how easy it would be for a user to find your
> > directory when they want it. 
> 
> Yes, if you are trying to implement something under ONE domain.

Not at all - it is quite possible to have white-pages service across
any number of domains. In the PARADISE X.500 network, we built user
interfaces that would happily go and search for things like:

	smith, university, europe

That would look for anyone called Smith (or Smithers or Smithson or...)
in any organisation calling itself a university in any country that
declared itself to be in Europe. In practice this is *not* a sensible
search and you don't want people doing it as it soaks up resources at a
frantic rate, but it *was* possible. If the development of LDAP is
taken just a bit further and someone deploys a top-level server then
it would be possible again.

> What do you suggest if you implement something with many domains, like a 
> virtual domain hosting ISP ?

It all depends on what sort of searches you want to support. I have built
a mail system based around LDAP that does exactly what you describe,
and I chose to place the 'customer domains' under an OU beneath my own
organisation entry. In this case, the organisation entry was in dc=
format, but it could equally well have been in o=, c= form. The critical
consideration was that my mail admin tool needs complete authority over
the subtree that it uses to define mail routing. White pages lookups
are still possible but are very much a secondary requirement (if I were
going to advertise a white-pages service I might well offer to alias
each customer's data into the 'proper' place in the DIT)

As a concrete example, suppose suares.nl wants to run a mail service
for some well-known characters. It obviously has absolute rights to
use dc=suares,dc=nl and anything underneath, so I would suggest
starting with ou=mailsystem,dc=suares,dc=nl as the root of the system.
Under that node, you could follow the Lachman-LASER scheme or you
could define your own schema. I defined my own as I had some specific
requirements that did not quite fit with Lachman-LASER. I chose to put
my customer domains in a subtree called ou=domains,dc=..... and each
domain has its own data under
 associatedDomain=<customer DNS name>,ou=domains,dc=....
(This should make delegated management possible later if I need it,
using ACLs). Each individual mail user gets an entry at the next level
down, containing routing data, username, password (for IMAP) etc.
Thus we would see:

	Main entry for the firytales.org customer:
	associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl

	Some client mail-users:
	cn=Snow White,associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
	cn=Grumpy,associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
	cn=Snoozy,associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl

White pages lookups across the whole customer set are possible using a
search base of ou=mailsystem,dc=suares,dc=nl but you may prefer to
alias the entries into things like:

	cn=Grumpy,dc=fairytales,dc=org

	or 

	cn=Grumpy,o=Seven Dwarves,c=Fairyland

The problem then is that current user-interfaces would have trouble
searching across all customers at once. This might well be considered
an advantage :-)

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------