6:22 a.m.
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?
7:34 a.m.
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.
2:33 a.m.
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?
6:33 a.m.
Edgar Fuß <ef(a)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
8:29 a.m.
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.
10:43 a.m.
New subject: chain-rebind-as-user (was: syncrepl, updateref, chain overlay and the authzTo attribute)
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).
5118
days inactive
5119
days old
openldap-software@openldap.org
5 comments
3 participants
participants (3)
-
Dieter Kluenter -
Edgar Fuß -
Michael Ströder