Edgar Fuß ef@math.uni-bonn.de writes:
That is for proxy authorization. Do you really need that?
I suppose so, at least the documentation under http://www.openldap.org/doc/admin24/overlays.html#Chaining seems to instruct me to do so.
From my understanding the clients would b[ind] to the consumer replica and the master enforces access control. IMHO no need for proxy authz.
Now I am confused. My understanding is that the client binds to the syncrrepl consumer, the consumer binds to the provider (using the replication dn, for example). But now, how should the master know which access control to enforce? I thought that precisely for that purpuse, the consumer would idassert-bind (i.e. PROXYAUTHZ) to the client's identity. Is my understanding totally wrong? Is there an easier way of doing this?
No, there is no easier way but configure the chain overlay. As the user connecting via chaining to the provider, access control on the provider is enforced, just run the provider with debugging mode acl to see parsing of access rules.
EF> As an aside, I couldn't find it documented that authzTo was an EF> operational attribute, so I wasted my time looking for a schema EF> containing that attribute. MS> Why is looking at the schema a waste of time? I was looking /for/ a (non-existent) schema containing the (operational) authzTo attribute. To me, taht looks like I've wasted my time. Or am I wrong again in my assumption that authzTo is an operational attribute?
authzTo is hard coded in servers/slapd/schema_prep.c.
-Dieter