Hi List- I'm new here but was invited to post the following by someone from this list so I hope it's not OT here.
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 = [EMAIL PROTECTED]) %d = domain portion of %u if available (%d = domain.tld when %u = [EMAIL PROTECTED]), 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: [EMAIL PROTECTED],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). -- Kevin http://www.gnosys.us
