RE: Can I bind to server with DN not on server ?

["Howard Chu" <hyc@symas.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Tom Riddle

> Is it possible to bind to an ldap server with a dn that is NOT in a
> naming context on that sever ?

In general, no. In specific, it may depend on the version of your software,
which you neglected to mention.

> For example I have 3 servers glued together with subordinate and
> superior referrals:
> server A:
> suffix "o=XYZ"
> contains ou=SFO,o=XYZ
> with subordinate referrals to servers B & C for ou=NYC,o=XYZ
> & ou=DCA,o=XYZ
>
> server B:
> suffix  "ou=NYC,o=XYZ"
> superior referral to server A: referral ldap://serverA/
> access to dn.children="ou=People,ou=NYC,o=XYZ"
>     by dn.children="ou=People,ou=NYC,o=XYZ" write
>     by dn.children="ou=People,ou=SFO,o=XYZ" write
>
> server C:
> suffix  "ou=DCA,o=XYZ"
> superior referral to server A: referral ldap://serverA/
> access to dn.children="ou=People,ou=DCA,o=XYZ"
>     by dn.children="ou=People,ou=DCA,o=XYZ" write
>     by dn.children="ou=People,ou=SFO,o=XYZ" write
>
> Regardless of the bind method, and regardless of which server I bind
> to,  I cannot seem to get the SFO people to see the entries
> on the other
> sites.  Slapd does not seem to follow referrals when it trying to
> authenicate the user.

Referrals are for clients to follow. slapd never follows referrals itself. In
the case of a Bind request, it's somewhat useless to Bind against a referral,
because the Bind will only be processed by the server that is the target of
the referral. You will still be unauthenticated on the original server.

> Is this even possible ?  I can provide more details of course, but I
> have a sneaking suspicision that this is the intended behavior.

This is the way referrals work.

> Is there a better approach ? I would prefer not to replicate
> the entire tree accross all sites if possible.

If you're using OpenLDAP 2.1 or newer, you can use back-ldap for distributing
the tree instead of using referrals. In this case, all of the naming contexts
will be defined on all of the servers, but some portions will be local
databases and some portions will be proxied via back-ldap. So in effect all
of your binds will always be contained within any of the servers' naming
contexts.

In server A:

database ldap
suffix ou=nyc,o=xyz
subordinate
uri ldap://serverB

database ldap
suffix ou=dca,o=xyz
subordinate
uri ldap://serverC

database bdb
suffix o=xyz

In server B:

database bdb
suffix ou=nyc,o=xyz
subordinate

database ldap
suffix ou=dca,o=xyz
subordinate
uri ldap://serverC

database ldap
suffix o=xyz
uri ldap://serverA

(And server C is pretty much configured like server B)

Referrals are an afterthought in LDAP. The original LDAP protocol didn't have
them at all. They are a poor solution to the larger problem that (unlike
X.500) LDAP was not designed with distribution in mind. back-ldap isn't
necessarily a perfect solution to the problem, but it does enable some
semblance of coordinated distributed operation...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support