[Fedora-directory-users] Specifying an all-inclusive User directory subtree?

[Jeff Clowser]

Kevin Myer wrote:

> Quoting Jeff Clowser <jclowser at unitedmessaging.com>:
>
>> There is really no need to use the dc=k12,dc=pa,dc=us style tree - in 
>> fact, in most cases I've set up, that was actually a bad choice.  Sun 
>> uses o=internet as a base under which to put a full dc tree (in their 
>> 5.x messaging software), but even they are moving away from that, 
>> because it doesn't work very well in a lot of cases (though it works 
>> a lot better than st=pa,c=us type trees).  If you really want to use 
>> a domain based tree, build it under something like o=internet. (i.e. 
>> dc=k12,dc=pa,dc=us,o=internet, etc) so there is a common root.
>
>
> I should have been more specific and stated that using a domain component
> approach to the tree layout was an initial assumption.  

One thing I've seen is the following:
1.  Create separate trees - i.e. dc-k12,dc=pa,dc=us, etc.
2.  Then create another tree, such as o=isp, and under that, create 
referals or chains for each of your "real" trees, so that you can search 
the "forest" using o=isp, but have each tree stand alone.

Personally, I don't like this approach, because it has implications for 
clients (do they follow referals?), aci's, and is just a mess to 
maintain.  I also prefer to only use referals/chains to split trees 
across servers (if that's needed for delegation or scaling of services), 
rather than to remap trees (I hate doing a search where the dn that gets 
returned isn't under the tree I searched...  But that's just me).  KISS 
is important :)

> What are the problems you've encountered using a domain based tree
> (dc=iu13,dc=org,o=internet), versus one where the domain is treated as an
> organization (o=iu13.org,o=internet), other than having a few more 
> components
> to type?  Has thinking on using DC style tree's changed?

I wouldn't say thinking on dc style trees have "changed", so much as 
there are different opinions out there :) .  As far as I know, rfc2247 
is the only rfc that defines a tree structure, but also as far as I 
know, it is just saying "here is one way to build a tree", rather than 
"here's the best/recommended way to build a tree".  It's nice because it 
mirrors DNS, another common directory service, but it isn't the best for 
all cases.  Other tree structures (i.e. o based) are just as valid, 
depending on what your needs are.  I believe the dc structure is the one 
Microsoft uses in Active Directory, so a lot of people will say it's 
"best" to use this to be able to interoperate more easily with Active 
Directory.  The directory server does not _require_ this structure by 
any means - it's just the default suffix it offers. 

As for the problems I've had - they are very similar to the problems you 
are describing - if I have xyz.com and abc.org, how do I put them in a 
common tree?  I can't, unless I have a stub entry to root them under 
(i.e. o=internet, etc).  Most ldap enabled services/software (mail, 
calendar, dns, etc) expect one tree to look for resources in.  If you 
create separate trees, you often have to deploy separate 
servers/instances of servers for each, which is not efficient.  If you 
want to handle web or mail services for N domains, do you want to deploy 
one server (or server cluster) to handle this, or do you want to have to 
deploy/maintain n servers, each separately/differently configured?  
Also, if you are hosting a dozen domains with 100 users in each, do you 
want one server or a dozen under-utilized servers to maintain?  This 
just doens't scale well/efficiently using separate trees like this.

In any event, it is unwise to write applications that assume anything 
about the data based on the structure of the tree (other than apps that 
administer the data in ldap), so the tree structure _shouldn't_ matter 
too much (yeah, I know, in an ideal world).  A simple example of this:  
say you have a mail server that receives mail for user joe at abc.org.  It 
looks in ldap only under dc=abc,dc=org.  Sounds good, but what if the 
organization has multiple domains - say abc.com and abc.org.  Further, 
joe receives email to joe at abc.org and joe at abc.com.  Joe's login account 
has to be under dc=abc,dc=org or dc=abc,dc=com - he can't be under both, 
realistically.  Sure, you could create his account under dc=abc,dc=org, 
and create an alias under dc=abc,dc=com that redirects things to 
joe at abc.org.  However, now you have 2 entries that represent joe - if he 
quits, you have to remember to clean up all these entries - putting all 
this in one entry (say mail and mailalternateaddress if you use Sun's 
mail server) means it's all in one place and easy to clean up.  Also, 
you probably have user accounts for the same organization under both, 
maybe with aliases in the other.  Also, you have to be careful as to 
whether or not joe at abc.com and joe at abc.org are different users, or one 
is an alias of the other.  Also, if you are delegating administration 
(say to multiple customers), segregating administration of domains using 
this model gets complex or is limiting (i. no customer can have more 
than one domain).  All doable, but much more complex to keep track of.

If, on the other hand, you create o=abc.org,o=isp, and associate abc.com 
and abc.org with that branch (Sun's messaging, for example, has domain 
and associateddomain attributes in this entry to define the primary and 
associated domains under this branch), and put all users with either 
domain under that, things are nice and clean and organized.

On a similar note - even if the directory server allowed you to search 
across all trees with a base of "", I'm guessing there's probably a lot 
of client software out there that doesn't allow you to define a search 
base of "".

Anyway, this is mostly just my opinion - take that for what it's worth :)

 - Jeff