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. 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
