The question in my Subject is what all this boils down to, so if you
have no time to read a long explanation, feel free to answer it as
asked...
Background: I'm working on my first attempt at doing the grand
architecture for a new LDAP instance, although I've been working with
LDAP as an admin for years: doing housekeeping on existing servers,
setting up simple small environments, and managing other systems
using LDAP as a utility data/auth source. I'm not a newbie to LDAP
(or to OpenLDAP, which I'm using for this project) but I haven't
previously had any reason to depart from fairly tame "cookbook" work.
I now have to build a single directory to serve dozens of small to
medium businesses to authenticate users for a small collection of
mostly web-based applications that my employer provides for them. To
avoid complexity on the application side, we want to have a common
auth interface for all clients rather than proliferating a bunch of
per-client vhosts for little real purpose. Because we manage mail
systems for most of these companies, we have hard knowledge of user
email addresses, and those make the perfect globally-unique
identifiers for each user: we can enforce correctness and
uniqueness, and the users should have no trouble remembering what
their login ID's are.
Because we already have some facilities using Apple's "Open
Directory" environment, which integrates OpenLDAP, Kerberos, and
some of their own facilities, we're hoping to piggyback on the
existing LDAP it uses, which uses a domain-based suffix: the FQDN of
the server split into dc components. The obvious way to add in our
clients to that without putting them into the part of the directory
tree managed by Open Directory is to build out the logical
domain-based tree with our clients having their own branches, i.e.
"dc=hostname,dc=oursite,dc=ourdomain,dc=net" already exists and is
where the Open Directory DIT lives, and I was hoping to create
"dc=client1,dc=com" and "dc=client2,dc=net" and so on for our
clients. This way, we could (in principle) have the authentication
layer search for [EMAIL PROTECTED] with a null search base
across the whole DIT and find
"uid=username,cn=users,dc=client1,dc=com" which apps could use as a
way to identify which client organization the user is part of.
However, I am finding that actually setting up a server to handle a
pure domain-based tree that can be searched in full from a null base
is a battle against the prevailing models. I have a working system
from the standpoint of searches: ldapsearch finds user records
wherever they are in the tree, and the DSE object has a single empty
namingContexts attribute. However, the effect of this has also been
to completely confuse other more user-friendly tools (Apple's
Workgroup Manager, JXplorer, Apache Directory Studio) and that's not
going to fly because while I can handle the fact that client records
cannot be seen in Apple's tools, I cannot break those tools for their
existing user or hand the front-line support staff a system that can
only be administered with command-line tools and LDIF files. Even
when I populate the logical nodes between the root and the domains
that have real content, browsing tools don't see them, apparently
because they don't like the null naming context as a naming context.
So, I am looking here for an answer from the broad LDAP community to
the question in my Subject. I am concerned that while I may be trying
to do something that seems "right" based on my reading of RFC2247, I
may have missed something in my research and this may be conceptually
broken. While clearly I am doing something that is harder to get
working than I expected it to be, I am trying to not keep pounding
away at trying to get something to work that never will work or if I
manage it, *shouldn't* work.
--
Bill Cole
[EMAIL PROTECTED]
