Nabble - LDAP UMich Lists

Re: Is a searchable dc tree rooted in a null base suffix wrong or just hubris?

2008-12-04T14:16:52Z

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 mail=username@... 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 :
dev@...
http://issues.apache.org/jira/browse/dirstudio (you will have to register)

Thanks !

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Nabble - LDAP UMich Lists

Re: Is a searchable dc tree rooted in a null base suffix wrong or just hubris?

Re: Is a searchable dc tree rooted in a null base suffix wrong or just hubris?

Re: Is a searchable dc tree rooted in a null base suffix wrong or just hubris?

Is a searchable dc tree rooted in a null base suffix wrong or just hubris?

Re: Help

Re: Help

Help

Re: Guessing root DNs for active directory

Re: Guessing root DNs for active directory

Re: newbie question: how to put company structure to ldap

Re: newbie question: how to put company structure to ldap

Re: newbie question: how to put company structure to ldap

newbie question: how to put company structure to ldap

newbie question: how to put company structure to ldap

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set

Re: LDAP Error 32 v/s Empty Result Set