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. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20050728/fd2bcd80/attachment.bin
