Tim Stewart wrote:

Hello,

I have three servers, A, B, and C. C has the master copy of all data. A is set to refer to B, and B will refer to C.

I have properly configured SASL on all three systems. All use Kerberos and use their ldap service principal to authenticate. They are properly mapped to in-directory DNs via the authz-regexp directive. Also, I'm sure everything is working because the same SASL config is used for replication.

I have configured the chain overlay on servers A and B to use SASL authentication and have chain-uris defined for B and C, respectively.

• Scenario 1:

  A write request is issued to server B. The chain overlay follows the referral and binds using its SASL identity to server C. It then rebinds (allowed via authzTo in the dn for server B's identity) as the user making the request and successfully updates the database. Things work as expected.

• Scenario 2:

  A write request is issued to server A. The chain overlay follows the referral and binds using its SASL identity to server B. It then rebinds (allowed via authzTo in the dn for server A's identity) as the user making the request. Server B's chain overlay then takes over to handle the referral to C.

  The chain overlay on server B binds to server C as its SASL identity, which succeeds. The overlay then attempts to rebind as *server A*, rather than the original user. This rebind fails as the authzTo in the dn for server B's identity only allows rebinding as normal users in my setup. The update fails.

Even if server B's identity were allowed to rebind as server A, the update would fail because server A does not have the appropriate permissions. Regardless, server B should be rebinding as the original user.

After some research I have found that this issue feels very similar to ITS#3526, ITS#4070, and ITS#5110. Is there anything I can do to force the second referral to rebind as the correct user?

Sounds like you need to set "chain-chase-referrals no"

Here are the relevant sections of my configuration:

################################## # Server A

overlay chain chain-tls start chain-max-depth 3

chain-uri "ldap://serverB.example.com" chain-idassert-bind bindmethod=sasl saslmech=gssapi mode=self

################################## # Server B

overlay chain chain-tls start chain-max-depth 3

chain-uri "ldap://serverC.example.com" chain-idassert-bind bindmethod=sasl saslmech=gssapi mode=self

Thanks you,

-- -TimS Tim Stewart Stoo Research tim@stoo.org

You hit a limitation of chaining as it is implemented today: chaining of chained operations (namely, using idassert with proxied authorization, as when mode=self) is explicitly disallowed, as back-ldap refuses to add an instance of the proxied authorization control when one is already present. This is the case of chained requests. This limitation would be eliminated by the implementation of distributed procedures, currently a work in progress (stalled, I believe).

Let me add that I find your setup a little bit nonsensical: if you have shadow databases that are exact replicas of the producer, then each shadow should be able to answer read requests. As a consequence, there is no need to chain a shadow to another shadow. As a consequence, you should rather chain all shadow servers to the producer.

p.