Bill Cole wrote:
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.
We can investigate your problem on Apache Direcroty Studio, and fix it,
that's for sure. Can you post a mail to the apache directory mailing
list with a short description of your problem, or even better, fill an
issue ?
links :
[EMAIL PROTECTED]
http://issues.apache.org/jira/browse/dirstudio (you will have to register)
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
