[Date Prev][Date Next]
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.
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.
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
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'
cn=subschema is to __expose__ schema; cn=schema,cn=config is to
-- 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/