[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