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

Re: syncrepl, updateref, chain overlay and the authzTo 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
-- 
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E