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
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... - 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 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
389-users@lists.fedoraproject.org
-
Jeff Clowser -
Kevin M. Myer -
Rich Megginson