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.
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?
openldap-technical@openldap.org
-
Howard Chu -
Matthew Kemp