[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
OT? DIT design concepts for virtual domain hosting (strictly LDAP; not OpenLDAP)
Hi List-
As far as the on-topic or off-topic issue goes, I'm just not sure.
Based on some recent replies to the list, it may be off-topic because it
is not strictly an OpenLDAP issue. However, I'm using strictly OpenLDAP
in my learning and experimentation, and much of my examples come from
OpenLDAP commentary on the FAQ. I'm just not sure, thus the disclaimer
here at the top. As far as I can determine, my questions involve
strictly design issues with LDAP and nothing pertaining strictly to the
OpenLDAP implementation of it. My apologies if I'm out of line putting
it here, but at least you can stop reading now if you believe this is
OT.
In recent reading, I've encountered two fundamentally different ideas
for a LDAP DIT to be used in virtual domain hosting:
1) the server hosts only one suffix (under which all of the virtual
domains fall) and thus a single tree with a single root node such as
these:
1a) http://www.linuxjournal.com/article.php?sid=5917
1b) single tree described by Ace Suares in the faq-o-matic under
the heading, "More on sets and how they can be used as 'reversed
groups'" that goes something like this:
"...Consider a tree consisting of ISP's, in the following fashion:
isp=isp001,SUFFIX
isp=isp002,SUFFIX
isp=isp003,SUFFIX
Every ISP may have several domains, as follows:
domain=example.com,isp=isp001,SUFFIX
domain=example.net,isp=isp001,SUFFIX
domain=example.org,isp=isp001,SUFFIX..."
2) the server hosts several suffixes and thus several trees, each tree
its own database on the back-end such as that depicted in ascii art
here:
""
__________|___________
| |
o=airius.com o=airius corporation
| | | |
ou=people ou=groups | |
ou=people ou=groups
and described in more detail under "Chapter 6 Directory Tree Design:
Directory Tree Overview: Multiple Suffixes" and under "Chapter 6
Directory Tree Design: Directory Tree Overview: Planning Your Directory
Suffix(es): Using Multiple Suffixes: ISPs" at
http://docs.sun.com/source/816-6679-10/dit.htm
I'm sure they both have their merits and drawbacks (perhaps the first
would be faster?), but the second idea seems to have some good strong
reasons behind it. Quoting from the URL above:
"For most directory services there is no need to use multiple suffixes
with your Directory Server. The exception to this rule is Internet
Service Providers (ISPs) who may be supporting multiple enterprises with
their directory services. If you are an ISP, then you should approach
each of your customers as a unique enterprise and design their directory
trees following the advice and concerns as outlined in this book. For
security reasons, each account should be provided a unique directory
tree with a unique suffix and an independent security policy.
Your Directory Server can use multiple databases, so you can assign each
customer their own database, and you may want place each directory tree
on its own disk drive. Placing each directory tree in its own database
allows you to perform backup and restore activities for each directory
tree without impacting your other customer's operations.
By placing each directory tree on a unique disk drive, you reduce
possible performance problems caused by disk contention, and you also
reduce the number of accounts potentially impacted by a disk outage."
In my use of OpenLDAP Software (while interoperating with Cyrus SASL and
MIT Kerberos 5) I've also encountered some software interoperability
issues that would seem to put some additional design constraints on such
a LDAP DIT. For example, in Cyrus SASL for configuring saslauthd to
authenticate against a LDAP directory, one has the following parameter
and associated settings:
ldap_filter: <uid=%u>
Specify a filter. The following tokens can be used in the filter
string:
%% = %
%u = user
%U = user portion of %u (%U = test when %u = test@domain.tld)
%d = domain portion of %u if available (%d = domain.tld when %u =
%test@domain.tld), otherwise same as %r
%1-9 = domain tokens (%1 = tld, %2 = domain when %d = domain.tld)
%s = service
%r = realm
%D = user DN (available for group checks)
The %u token has to be used at minimum for the filter to be useful.
If ldap_auth_method is 'bind', the filter will search for the DN
(distinguished name) attribute. Otherwise, the search will look for
the 'ldap_password_attr' (see below) attribute.
These tokens can also be used in some additional parameters such as
ldap_search_base, ldap_default_realm, ldap_group_dn, ldap_group_filter,
ldap_group_search_base, and maybe others.
In particular, I've noticed that my first cut at such a DIT seems to me
to have some vivid shortcomings related to these tokens. The suffixes
in my DIT have the form: dc=domain,dc=com and the DN's have the form:
mail=user@domain.com,ou=people,dc=domain,dc=com and it's clear to me
that with such a design, I'll have a difficult time using the tokens
available here to specify a ldap_search_base (ie. how could I use %r or
%d to get into the desired suffix/database for several different
suffixes) that is derived from the information that a user will enter
into clients that would want to authenticate against this LDAP DIT (such
as email clients).
Thus, it seems clear to me that when considering the design of a DIT for
use with saslauthd, one really should consider these parameters and how
readily one can authenticate any user from any of possibly many
different hosted virtual domains against a single DIT.
Furthermore, although I do not understand all of the reasons very well,
it seems clear that trying to make sure that one's DIT can ultimately
fit in well with a global DIT for all of the hosted virtual domains also
imposes some design constraints. For example, just about all of the
examples I've encountered in ORA's _LDAP System Administration_ list a
suffix consisting of two dc's like dc=example,dc=com after the model of
the global DNS directory. It is so prevalent in book examples and other
examples that I cannot help but wonder if it is important to keep as a
basic design consideration of any DIT that might someday want to fit
into the global DIT. Is it? To be more specific, factoring all of the
possible issues into the equation (most of which I'm certain I'm
completely unaware of), is some DIT A with multiple suffixes:
dc=example,dc=com and dc=example,dc=net; just as good for virtual domain
hosting as some DIT B with multiple suffixes: domain=example.com and
domain=example.net (drawing from Ace Suares' example on the
FAQ-o-matic)? Or perhaps as good as some other DIT C with multiple
suffixes very different from these two?
Also, can anyone offer insights on interoperability issues similar to
the one listed above with saslauthd that might put additional
constraints on a good DIT design? And when I say constraints I don't
mean that in its strictest sense, but more something like, "Well, it can
be done that way but implementing it would be much more difficult than
with some other design..." I guess I'm hoping to avoid some "gotcha!"
that comes up well after I've designed a DIT and put it into use only to
find that my design approach removes some important options that I learn
later that I'd really like to have but that will require a major
overhaul of my DIT to make it practical.
Or perhaps someone can recommend a good reference for making such design
decisions that factor in all or many of the issues listed above? The
sun.com site above seems to have some good material related to my
questions and I'm eating it up, but it doesn't seem to consider some
other issues (such as interoperability with other software).
Thanks for reading and my apologies if this post shouldn't be in this
list. Since all of my learning and examples are from OpenLDAP it seemed
like it might be a fit and perhaps some others can benefit from some of
my questions.
-Kevin
http://www.gnosys.us