Re: Do DN's have to be rooted at country

[Will Ballantyne <Will.Ballantyne@gems1.gov.bc.ca>]

Quite coincidentally I posted this to the openldap-devel list yesterday.  It's
meant to solve this type of issue with the multiple standards defining varying
search bases (roots if you prefer).

Will Ballantyne wrote:

> I've put together some code to allow for the aliasing of search bases in
> the openldap package.  The code is only implemented for the search
> capability but I will add it to the add/mod/del etc. as time permits.
>
> This comes about from the puzzle of how to support the various standards
> for the composition of DNs.  Specifically how the choice of a base could
> be made to fit the various standards for later integration in the name
> spaces defined by the various authorities.
>
> For example, in the X.500 structure we have the name "o=Government of
> British Columbia,c=CA".  While we are phasing out X.500, we will likely
> continue to provide access through some form of DAP/DSP to LDAP bridge.
> RFC2377 recommends using the dc components, so we would have
> "dc=gov,dc=bc,dc=ca".  The base aliasing allows the ldap server to
> receive and respond to both correctly and we don't need to worry too
> much about which we choose internally.  Subparts can also be aliased in
> this way.
>
> I would like to apply enhancements we make here back to the original
> distribution.  Please let me know the best way to provide the code and
> whether this enhancement would be useful to others.  Also, I would be
> very curious as to what others are doing to the following three areas:
>
>     bound access control, especially object based access control.
>     host based access control
>     chaining and replication
>
> Thanks.
>
> --
> Will Ballantyne     GEMS Technical Architect
> mailto:Will.Ballantyne@gems1.gov.bc.ca

--
Will Ballantyne     GEMS Technical Architect
mailto:Will.Ballantyne@gems1.gov.bc.ca






Luke Howard wrote:

> > Country does not have to be a part of the dn. Actually
> > there's a movment
> > out now to make dn's a bit more easier to understand (see
> > rfc2377 which
> > came out last month).
>
> Yes, there are divergent opinions on how to name the root of your directory.
> My perception is that it matters a lot less than it does with X.500, as LDAP
> referrals can direct the client to an arbitary part of a server's DIT.
>
> Here are some of the approaches that I've seen; note that I'm not addressing
> the issue of how you publish the fact that your organization serves part of
> the DIT. I'm sure X.500 die-hards will have something to add on this issue
> :-)
>
> 1/ X.500 organization+country, e.g. o=Xedoc Software Development,c=AU. The
> implication is that a naming authority grants you that part of the
> namespace; I think in the US, it's the ANSI. In Australia, I believe that
> (by virtue of having a registered company name) you can automatically
> "claim" a part of the DIT.
>
> 2/ Variations on the X.500 theme, such as omitting the country and just
> using the organization or using the organization's domainname as the
> "organization" (eg. o=xedoc.com. IMHO this is wrong; I *think* the reason
> some vendors recommended it related certificates requiring organizational
> names). I think MS Exchange uses this (eg. o=Xedoc Software Development)
> too.
>
> 3/ RFC 1279, mapping a DNS domain (eg. xedoc.com) to
> dc=xedoc,dc=com,o=Internet.
>
> 4/ RFC 2247, essentially the same thing with the o=Internet dropped.
>
> My personal preference is for the last option, particularly as it works
> nicely with DNS SRV records to allow a client to find an LDAP server and
> naming context once it knows its domain name. This approach is supported by
> the nss_ldap module and NT 5.0, and it nicely leverages the distributed
> nature of the DNS. (On the other hand, you can use DNS TXT records to
> accomplish the same thing with non-DC names, as JNDI does.)
>
> Just my 2c.
>
> -- Luke

--
Will Ballantyne     GEMS Technical Architect
mailto:Will.Ballantyne@gems1.gov.bc.ca