Quoting Jeff Clowser <jclowser@xxxxxxxxxxxxxxxxxxx>:
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
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
