Re: Chain Overlay and SASL Proxy Auth with Multiple Referrals.

Howard Chu <[email protected]>
Newsgroups gmane.network.openldap.general
Message-ID <[email protected]>
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
> [email protected]
> 
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.