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

Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)




On Wed, Apr 26, 2017 at 10:16 PM, Howard Chu <hyc@symas.com> wrote:
Matthew Kemp wrote:

On Thu, Apr 20, 2017 at 6:36 AM, mailing lists <listas.correo@yahoo.es
<mailto:listas.correo@yahoo.es>> wrote:

    Hello,

    I am testing the chain overlay from a read-only slave (consumer) slapd
    server to a read-write master (provider), but what I am seeing is an
    anonymous bind from the consumer to the provider instead of the
    authorization identity configurated in the chain directive.


We're also seeing the same behavior and reported a similar issue last month to
this list:
http://www.openldap.org/lists/openldap-technical/201703/msg00047.html

I'm hopeful we can track down this issue as it's causing us some issues that
we'll need to resolve eventually.

Only ProxyAuth will work, now.

As documented, the chain overlay only intercepts responses to operations, and only acts when it sees a referral in the response. In order for rebind-as-user to work, the overlay would need to intercept Bind requests and cache the credentials, but it never intercepts Bind requests, therefore it has nothing to rebind with. It *could* intercept referrals from Bind responses, and grab the user's credentials at that point. But back in 2004 we turned those off, and slapd now will never return a referral to a Bind request. (commit 100facedf3c9ec241121a5e3ad7aa059a7c57bc2 in git.) Probably we should remove references to rebind-as-user from the slapo-chain(5) manpage now, since that commit basically killed this feature.


--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Howard, thanks for the response. 

That is unfortunate to hear, as I spent an not insignificant amount of time trying to make the configuration work as the documentation implied it might, especially given how long that documentation has apparently not been accurate. I agree with your suggestion to remove those references.

I am slightly concerned that ProxyAuth places a lot of power into the credentials used by consumer, unless I entirely misunderstand the process. I was hoping that by enforcing the user to bind as themselves in order to change their passwords, I wouldn't have to worry about users with root access in staging environments where we plan to have read-only syncrepl consumers potentially being able to get ProxyAuth access to other users account information.

Do you have any advice for a situation such as ours? 

--
Matt Kemp
Production Engineer
Braintree