Fedora directory users - Jul 2005 - Specifying an all-inclusive User directory subtree?

On initial configuration and later in the management console, you specify or use
a "User directory subtree".  For a single organization, this may be
easy to
setup, but for ourselves, we manage directory entries for a variety of
.k12.pa.us, .org, and .net domains.  So whats the best way of creating a view
that encompasses all of those?  Is it possible to use a blank subtree, so that
when I search for a user from within the management application, I can find
them all, regardless of the domain components used?  Or are there better ways
to handle this?

Thanks,
Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

FDS does not support this.  There has been some work done in this area 
though, and it can easily be supported via a plugin.  There are two 
example plug-ins included with the source code - 
http://cvs.fedora.redhat.com/lxr/dirsec/source/ldapserver/ldap/servers/slapd/test-plugins/
- the testdatainterop and testdbinterop plugins.  These implement the 
capability to intercept search requests directed at the ''null
suffix'' "".

Ideally, one would be able to configure the mapping tree (see the 
example code) and specify a list of suffixes to which access is allowed 
from a onelevel or subtree search from the "" suffix - you probably
want
searches to go into dc=yourdomain,dc=tld but not cn=schema or 
cn=config.  This would also allow for "global" inheritance - setting 
ACIs, groups, roles, etc. at the top level and having them apply to all 
suffixes.

Kevin Myer wrote:
>On initial configuration and later in the management console, you specify or
use
>a "User directory subtree".  For a single organization, this may
be easy to
>setup, but for ourselves, we manage directory entries for a variety of
>.k12.pa.us, .org, and .net domains.  So whats the best way of creating a
view
>that encompasses all of those?  Is it possible to use a blank subtree, so
that
>when I search for a user from within the management application, I can find
>them all, regardless of the domain components used?  Or are there better
ways
>to handle this?
>
>Thanks,
>Kevin
>
>  
>

I would create a suffix with something like "o=isp", then create 
"o=k12.pa.us", "o=abc.org",
"o=<primarydomain>", etc under that.  Create
ou=people, ou=groups, etc under each, and set up admin groups, aci''s, 
etc to allow each to be managed separately, allow appropriate views by 
users, etc.

Search o=isp as your base to see all entries, or o=<primarydomain>,o=isp 
to see individual ones.  (Note I say <primarydomain> instead of
<domain>
because some organizations have more than one domain associated with 
them - you don''t have to define a branch for each domain you use - 
organize things by how you want to manage them and restrict views, etc).

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.

 - Jeff

Kevin Myer wrote:
>On initial configuration and later in the management console, you specify or
use
>a "User directory subtree".  For a single organization, this may
be easy to
>setup, but for ourselves, we manage directory entries for a variety of
>.k12.pa.us, .org, and .net domains.  So whats the best way of creating a
view
>that encompasses all of those?  Is it possible to use a blank subtree, so
that
>when I search for a user from within the management application, I can find
>them all, regardless of the domain components used?  Or are there better
ways
>to handle this?
>
>Thanks,
>Kevin
>
>  
>

Quoting Jeff Clowser <jclowser@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.  I''m aware that
I can
use a "fudge" base and artificially create a top-level parent with
that, and
use ACI''s appropriately to control access, as we''re already
doing that, but
without a common top level DN.  I can accomplish similiar functionality to the
two plugins Rich mentioned by using some of the OpenLDAP proxy/rewrite
backends, but I was more concerned about the initial suffix you setup in the
setup script and that is searched from within the management console, not so
much with client access.

I thought the 5.X release of Directory Server actually required a domain
component tree?  And that, in turn, was based on recommendations in RFC 
2247? 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?

Kevin
-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

Kevin Myer wrote:
> Quoting Jeff Clowser <jclowser@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.  I''m aware
that
> I can
> use a "fudge" base and artificially create a top-level parent
with
> that, and
> use ACI''s appropriately to control access, as we''re
already doing
> that, but
> without a common top level DN.  I can accomplish similiar 
> functionality to the
> two plugins Rich mentioned by using some of the OpenLDAP proxy/rewrite
> backends, but I was more concerned about the initial suffix you setup 
> in the
> setup script and that is searched from within the management console, 
> not so
> much with client access.
So you could put an OpenLDAP "proxy" in front of FDS.  You can also 
change the suffix used by the management console, but I''m not sure it 
allows "" as a valid suffix.
>
> I thought the 5.X release of Directory Server actually required a domain
> component tree?  And that, in turn, was based on recommendations in 
> RFC 2247? 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?
No.  In LDAPv3, nothing of the sort is really "required".  DC style 
naming is recommended for interoperability with other LDAP enabled 
applications and LDAP server vendors, but you can use just about 
anything for your suffix naming.  This is in stark contrast to X.500 
which prescribes suffix naming.  This is one of the things that puts the 
"Lightweight" in LDAP.
>
> Kevin

Kevin Myer wrote:
> Quoting Jeff Clowser <jclowser@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@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@abc.org and joe@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@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@abc.com and joe@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