I managed to get cn=config working by following http://www.openldap.org/faq/index.cgi?_highlightWords=cn%20config&file=1... 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? 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 :).
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).
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... ?
Turbo Fredriksson wrote:
I managed to get cn=config working by following http://www.openldap.org/faq/index.cgi?_highlightWords=cn%20config&file=1... 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).
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).
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.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati wrote:
Turbo Fredriksson wrote:
I managed to get cn=config working by following http://www.openldap.org/faq/index.cgi?_highlightWords=cn%20config&file=1... 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.
openldap-software@openldap.org
-
Howard Chu -
Pierangelo Masarati -
Turbo Fredriksson