Some questions around syncrepl, updateref, the chain overlay and teh authzTo attribute:
For performance reasons, I need a LDAP replica on a remote site. I set this up using syncrepl. Now, given some clients' inability to direct updates to an LDAP server different from the one they send queries to, is the following the intended way to deal with this situation (using OpenLDAP as a server, of course) or is there a simpler solution?
- set updateref on the syncrepl consumer - use the chain overlay on the syncrepl consumer - set an appropriate authzTo attribute for the replication entity and set autz-policy to to on the syncrepl provider
I'm somewhat reluctant to configuring something as powerful as proxy auth in LDAP attributes. Is there a way to configure proxy authorisation solely in slapd.conf? Or at least, to restrict it to entities explicitly enumerated in slapd.conf?
As an aside, I couldn't find it documented that authzTo was an operational attribute, so I wasted my time looking for a schema containing that attribute. Did I miss something or is this indeed not documented explicitly?
Edgar Fuß wrote:
For performance reasons, I need a LDAP replica on a remote site. I set this up using syncrepl. Now, given some clients' inability to direct updates to an LDAP server different from the one they send queries to, is the following the intended way to deal with this situation (using OpenLDAP as a server, of course) or is there a simpler solution?
- set updateref on the syncrepl consumer
- use the chain overlay on the syncrepl consumer
Yupp. Use slapo-chain on the consumer.
- set an appropriate authzTo attribute for the replication entity and set
autz-policy to to on the syncrepl provider
That is for proxy authorization. Do you really need that? From my understanding the clients would be to the consumer replica and the master enforces access control. IMHO no need for proxy authz.
As an aside, I couldn't find it documented that authzTo was an operational attribute, so I wasted my time looking for a schema containing that attribute.
Why is looking at the schema a waste of time?
Ciao, Michael.
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?
EF> As an aside, I couldn't find it documented that authzTo was an operational EF> attribute, so I wasted my time looking for a schema containing that EF> 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?
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
Edgar Fuß wrote:
Michael Ströder wrote:
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.
Hmm, yes. This text implicates use of proxy authz.
But slapo-chain(5) mentions directive 'chain-rebind-as-user' which you probably want to set to TRUE. There is no descriptive text for this directive yet (=> filed ITS#6305).
So please try this and report back. I don't have the time today to test it myself.
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?
As Dieter already noted it's declared hard-coded in the C code not in the subschema config files. So looking only at the config files might not be sufficient. => Use a decent schema browser to examine the actual subschema subentry of your server installation.
Ciao, Michael.
But slapo-chain(5) mentions directive 'chain-rebind-as-user' which you probably want to set to TRUE.
That, according to documntation of the ldap backend, is for re-establishing a broken connection.
There is no descriptive text for this directive yet (=> filed ITS#6305).
See slapd-ldap(5).
openldap-software@openldap.org
-
Dieter Kluenter -
Edgar Fuß -
Michael Ströder