Thanks for the quick reply, we've been using a bit more time to think about it. Rearranging your reply a bit:
Michael Ströder writes: > Hallvard B Furuseth wrote: >> When we run an LDAP server for some other organizations, what base >> DN should we recommend that they choose for their LDAP tree? > > This is basically the same problem like running several LDAP servers > within one company (e.g. MS AD and OpenLDAP or whatever). > >> The server host name will be under our domain, not theirs. (And the >> server cert cannot contain name under their domain, so it will only >> confuse matters if they create a CNAME under their domain which refers >> to the server.) > > This does not have anything to do with the search root anyway. Well, it makes names more easily guessable for users or clients who want to try to guess. Like foo.com -> www.foo.com for a web server. But "just ignore that part" is the answer I hoped for, yes. >> dc=<their domain>,dc=no still seems the normally best choice. Doesn't >> allow hostname/DN guessable from each other and won't work like intended >> with DNS SRV records. > > Do you mean their FQDN as <their domain>? I'd not recommend this. Oops, I meant foo.no -> dc=foo,dc=no of course. > Generally I recommend to follow dc-style naming but with an additional > level (sub-domain) reflecting each service name. To be sure talk to the > DNS people to reserve the used sub-domain for this particular service. > In some companies it might be hard to even register sub-domains though. > You have to negotiate that with the DNS responsibles. > > Examples: > msad.stroeder.com -> dc=ad,dc=stroeder,dc=com > corpdir.stroeder.com -> dc=corpdir,dc=stroeder,dc=com > > With this approach you're totally flexible regarding referrals and SRV > RRs and you avoid name clashes in advance. Cool idea, we'll suggest that one. We're already stealing name administration from DNS, so push it right back there. Except, I'm not coming up with any good names for the "who knows what it'll eventually be used for"-directory. A common development will likely be that it starts as an authentication directory with no public read access, and existing directory entries later grow to be publicly readable whitepages entries as well. "dc=ldap,dc=someorg,dc=no" seems a bit spurious. In any case, it's the customers' problem what to use. We'll just give them recommendations (including yours) and host whatever they say. > (...) >> The one problem I see is if they intend to use "our" LDAP server for one >> kind of clients (probably authentication) may set up some other public >> LDAP server of their own. They may then (or some time later) want >> referrals between the servers. A referral can change the DN of the >> referred entry, but client support for such features vary. > > Frankly most of my customers don't even know about referrals. So > referrals are really rarely used in the wild and this is rather > academic. Client software capable of accessing multiple directories are > capable of holding multiple LDAP configuration records. OK, good. My experience is rather narrow, I don't know much about what LDAP clients live out there. > Usually the AD guys have to deal with the relationship of LDAP and DNS. > But most other LDAP client software is not able to deal with SRV RRs. So > you won't find them in corporate networks for anything else than AD. Yes, it was mostly a "just in case"-concern of mine. The advice I got in a Microsoft group is that AD demands _ldap._tcp.<domain> for its own use. That would mean the choice is between using Windows (with a normal setup I guess) and having real LDAP SRV records. -- Regards, Hallvard --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
