« April 2005 | Main | January 2006 »
June 2004, 2005
Survey Says
I took this survey. If you blog, you should too. The bigger the sample, the more accurate the results. Nothing to buy, etc. Take the MIT Weblog Survey"
Posted by ljl at 1:4 AM | Comments ()
June 14, 2005
LDAP Snarling
So, we have an LDAP implementation. Not a surprise. Now, currently this implementation only has a tree for "corp.foo.com". Problem is, out network infrastucture has to provide access for corp.foo.com, foreign.foo.com, and corp.bar.com!! Also, it needs to keep foo people from logging in to most of bar's servers, while still enabling foo and bar to share some resources (like a mail server).
Now, corp.foo.com is set up in the usual textbook fashion, with a base dn of corp.foo.com, and People.corp.foo.com, and Things.corp.foo.com being a couple of the top categories. This does not make for easy addition of corp.bar.com and foreign.foo.com! With corp.foo.com being the top level of the heirarchy, the new additions and rearrangement would have to become: People.corp.corp.foo.com, People.foreign.corp.foo.com, People.corp.bar.corp.foo.com. Eeeeyuck!
What would make sense is for one server (and 1 LDAP instance), baz, to serve LDAP for corp.foo.com, foreign.foo.com, and corp.bar.com. But there is not a single book or web resource that can tell me how to split out the base dn! The base dn should at least be *just* foo.com, with the sub dns being corp.foo.com, foreign.foo.com, and bar.foo.com. A base dn of "com" would be even happier, letting every part be a natural extension of that.
However, if any future co-dependant organization uses "net" or "org", all bets are off. Why not just use a base dn of "ldap"? Then you have corp.foo.com.ldap, corp.bar.com.ldap, foreign.foo.com.ldap, and open.foo.org.ldap.
The idea is to have a base dn that does not interfere with proper break-out of organizational units, and yet enable persons to switch between them without completely having to delete and re-add their entry. The textbook structure, as we have it now, doesn't do that.
If any reader knows a good work around for this issue, or a good web resource on migrating from an overdefined tree to a more flexible one, let me know. This issue has to have come up before, especially in non-profit orgs that are sharing common resources and namespaces, possibly with for-profit benefactors.
Posted by ljl at 4:1 PM | Comments ()