On Wed, Apr 26, 2017 at 10:16 PM, Howard Chu <[email protected]> wrote: > Matthew Kemp wrote: > >> >> On Thu, Apr 20, 2017 at 6:36 AM, mailing lists <[email protected] >> <mailto:[email protected]>> 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
