Hi,
I've been trying to script database creation via cn=config. Creating the HDB database works fine, but when I try to add the LDIF for the root node, I get:
# ldapadd -YEXTERNAL -H ldapi:/// -f ./bootstrap.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "dc=app,dc=example,dc=com" ldap_add: Insufficient access (50) additional info: no write access to parent
... which is understandable. However, I would prefer not to set a temporary rootpw for the database. Is there any way around that?
I considered Proxy authorization, but the root DN for the database I'm creating is in the LDIF I'm trying to add.
/Peter
PS: As you can probably see, all access goes through SASL EXTERNAL. UNIX root maps to cn=config via ldapi:/// , remote access uses x509 certificates.
Peter Mogensen wrote:
Hi,
I've been trying to script database creation via cn=config. Creating the HDB database works fine, but when I try to add the LDIF for the root node, I get:
# ldapadd -YEXTERNAL -H ldapi:/// -f ./bootstrap.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "dc=app,dc=example,dc=com" ldap_add: Insufficient access (50) additional info: no write access to parent
... which is understandable. However, I would prefer not to set a temporary rootpw for the database. Is there any way around that?
I considered Proxy authorization, but the root DN for the database I'm creating is in the LDIF I'm trying to add.
/Peter
PS: As you can probably see, all access goes through SASL EXTERNAL. UNIX root maps to cn=config via ldapi:/// , remote access uses x509 certificates.
Add an ACL (either global, if there aren't any in that database, or local) that allows the identity you trust to write to that database.
p.
Pierangelo Masarati wrote:
Add an ACL (either global, if there aren't any in that database, or local) that allows the identity you trust to write to that database.
Global ACLs was probably a solution. (didn't know you could that).
So if I give cn=config write access to children attribute of dc=example,dc=com, globally and write access to scope "one" (and UNIX root maps via SASL EXTERNAL to cn=config), then root will be able to ldapadd any node below dc=example,dc=com
I'll try that...
/Peter
Pierangelo Masarati writes:
Peter Mogensen wrote:
PS: As you can probably see, all access goes through SASL EXTERNAL. UNIX root maps to cn=config via ldapi:///,
...plus authz-regexp, I assume
remote access uses x509 certificates.
Add an ACL (either global, if there aren't any in that database, or local) that allows the identity you trust to write to that database.
Or (temporarily?) change rootdn for the HDB database to cn=config, so root won't need a password for that rootdn over ldapi://. Or use authz-regexp to map your SASL/EXTERNAL identity to the database's rootdn instead of to cn=config.
Peter Mogensen writes:
Hallvard B Furuseth wrote:
Or (temporarily?) change rootdn for the HDB database to cn=config,
Isn't the rootdn required to be under the database suffix?
No, use of rootpw requires rootdn to be under the database suffix.
Our site's slapd.conf uses authz-regexp to rewrite the root ldapi:// DN to "cn=admin". Works fine.
Remember that rootdn has two functions: authentication (if there is a rootpw) and authorization (providing unlimited access to the database).
Authentication: Simple Bind is dispatched to the database whose suffix is a suffix of the Bind DN. Only that database's rootdn and rootpw is checked against the Bind DN and Bind password.
Authorization: Once you are successfully bound as some DN, that DN is checked against the rootdn and access controls of the database you are accessing.
--On Wednesday, September 16, 2009 2:08 PM +0200 Peter Mogensen apm@mutex.dk wrote:
Hallvard B Furuseth wrote:
Or (temporarily?) change rootdn for the HDB database to cn=config,
Isn't the rootdn required to be under the database suffix? Or has than been relaxed (or do I remember wrong)
You remember incorrectly. ;) I use cn=config as my rootdn for all databases.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org
-
Hallvard B Furuseth -
Peter Mogensen -
Pierangelo Masarati -
Quanah Gibson-Mount