[Date Prev][Date Next] [Chronological] [Thread] [Top]

Chain Overlay and SASL Proxy Auth with Multiple Referrals.



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?

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