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

Re: cn=config && (ACI || ACL)

Pierangelo Masarati wrote:
Turbo Fredriksson wrote:
I managed to get cn=config working by following
to the letter (meaning: I had to setup a rootdn/rootpw pair
to be able to do searches).

How can this be used, _without_ using the rootdn/rootpw?

You can't. Only the rootdn can access the cn_config database. However, you don't have to use the rootpw: any other means to auth the rootdn (read: SASL, or in-directory credentials for a rootdn that's actually a DN in another database) is just fine.

I want
ordinary users to be able to search/modify 'stuff' there (eventually,
when I know exactly what it is and how to use it :).

Not 100% sure; but you should be able to use proxied authorization for this (RFC 4370).

It would work, but only if you allow them to proxyAuthz as the rootdn, which may give away too much privilege.

I tried 'access to * by * write' as only ACL, but I _still_ got
'Insufficient access' whether or not I authenticated...
And running with '-d 128' shows NOTHING for anonymous access
(and only 'auth access to userPassword' when using bind DN).

In OpenLDAP 2.3 back-config does no ACL checking, it simply requires you to use the rootdn to have any access at all.

In OpenLDAP 2.4 back-config follows usual ACL controls.

Also (when on the subject of cn=config), in what way is
'cn=schema,cn=config' different from 'cn=Subschema'?
The devil is in the details, but why wasn't 'cn=Subschema'
enough? It have everything (?) that 'cn=schema,cn=config'
have... ?

cn=subschema is to __expose__ schema; cn=schema,cn=config is to administer it.

The cn=subschema view doesn't preserve any organization of the schema elements. Read the Admin Guide description of cn=schema,cn=config to see the difference.

  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/