Hello Dieter,

$ sudo ldapwhoami -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

I have been trying to delete a record using LDAPI as well as -D cn=config with a password. I have also added commands olcAccess to both dn: olcDatabase={0}config,cn=config as well as dn: olcDatabase={1}hdb,cn=config [DIT] databases.

The result is always the same: ldap_delete: Insufficient access (50) additional info: no write access to parent

Sincerely,

Igor Shmukler

On Thu, Mar 19, 2015 at 10:13 PM, Dieter Klünter dieter@dkluenter.de wrote:

Am Wed, 18 Mar 2015 23:28:35 +0200 schrieb Igor Shmukler igor.shmukler@gmail.com:

...

Hello,

I have been spamming this list, looking for insights into why I cannot configure OpenLDAP to use cn=config to delete an entry inside a DIT. Sorry.

Just now thought of and conducted another experiment. The results surprised me. If someone can please explain why OpenLDAP behaves this way, and whether this can be altered through configuration, it would certainly get me further on my way.

When I try to delete an entry using LDAPI as below: $ sudo ldapdelete -Y external -H ldapi:/// cn=john,dc=directory,dc=com ldap_delete: Insufficient access (50) additional info: no write access to parent

I do the same using domain administrator credentials and below and it works fine: $ ldapdelete -D cn=admin,dc=directory,dc=google,dc=com -W -x cn=john,dc=directory,dc=com

Why LDAPI does not work? What can be done?

probably because of unsufficient authz-regexp ?

What is the result of ldapwhoami -Y EXTERNAL -H ldapi:/// or sudo ldapwhoami -Y EXTERNAL -H ldapi:///

-Dieter

-- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

Hello Dan,

I must have done something wrong, yet this thing did not work either. One: the delete still failed with the usual error, and second - I got an error concerning my olcs:

550b380f /etc/ldap/slapd.d: line 1: rootdn is always granted unlimited privileges. 550b380f olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix 550b380f config error processing olcDatabase={0}config,cn=config: <olcRootPW> can only be set when rootdn is under suffix slapcat: bad configuration file!

After running the above command, I actually dropped my OpenLDAP server and rebuilt in by running a bunch of prepared scripts, so go back to the point where my settings made more sense. I have been experimenting for a bit too long without refreshing the environment. I am concerned that something stale is causing my problems.

Sincerely,

Igor Shmukler

On Thu, Mar 19, 2015 at 10:42 PM, Dan White dwhite@cafedemocracy.org wrote:

On 03/19/15 22:33 +0200, Igor Shmukler wrote:

...

Hello Dieter,

$ sudo ldapwhoami -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

I have been trying to delete a record using LDAPI as well as -D cn=config with a password. I have also added commands olcAccess to both dn: olcDatabase={0}config,cn=config as well as dn: olcDatabase={1}hdb,cn=config [DIT] databases.

The result is always the same: ldap_delete: Insufficient access (50) additional info: no write access to parent

If your goal is to manage your server using EXTERNAL over ldapi:///, configuring a olcAuthzRegexp is a far simpler approach. Map 'gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth' to your rootdn identity and you'll bypass acl restrictions altogether. -- Dan White

On 03/19/15 23:05 +0200, Igor Shmukler wrote:

Hello Dan,

I must have done something wrong, yet this thing did not work either. One: the delete still failed with the usual error, and second - I got an error concerning my olcs:

550b380f /etc/ldap/slapd.d: line 1: rootdn is always granted unlimited privileges. 550b380f olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix

You don't need to set olcRootPW in this case. See slapd-config(5).

On Thu, 2015-03-19 at 23:35 +0200, Igor Shmukler wrote:

Hello Dan and Michael,

I have a server with a config database and a few DIT databases. I use online configuration. A little white ago, I knew nothing about OpenLDAP. Now, your help, I understand a lot more, yet still little and able to achieve even less..

I want individual administrators [those from within each DIT] to be able to browse within their tree, and cn=config administrator to be able to search through all records on the server, across DITs. If this is too difficult, I would go for LDAPI. As a temporary workaround, LDAPI would be amazing.

None of it working, yet. I tried a bunch of suggestions, many of which I don't fully understand. Nothing worked so far.

Specifically, I cannot understand why should not the below applied to the config database does not work, if I did set the password. olcAccess: {0}to * by dn="cn=config" manage

Sincerely,

Igor Shmukler

On Thu, Mar 19, 2015 at 11:16 PM, Dan White dwhite@cafedemocracy.org wrote:

...

On 03/19/15 23:05 +0200, Igor Shmukler wrote:

...

Hello Dan,

I must have done something wrong, yet this thing did not work either. One: the delete still failed with the usual error, and second - I got an error concerning my olcs:

550b380f /etc/ldap/slapd.d: line 1: rootdn is always granted unlimited privileges. 550b380f olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix

You don't need to set olcRootPW in this case. See slapd-config(5).

-- Dan White

i think you are missing a key notion about cn=config. it is not a user object. you do not grant it access to anything. you grant someone/something access to *it*.

i have an acl granting a group in my directory manage access to my cn=config instance (mind the wrap):

{0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by group.exact="cn=ldapEngineers,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" manage by * none

so the root user on the local machine, and members of the ldapEngineers group are allowed to manage the cn=config instance.

then i have an acl granting a group in my directory manage access to my dc=bpk2,dc=con instance (mind the wrap):

{0}to dn.subtree="dc=bpk2,dc=com" by group.exact="cn=ldapAdmins,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" manage by dn="cn=kadmin,dc=bpk2,dc=com" write by dn="cn=kdc,dc=bpk2,dc=com" read by users read by anonymous auth by * none

members of the ldapAdmins group are allowed manage access to the directory, kerberos process id's are allowed read or write access, users can read, etc.

it took me a while to figure the above out, and i still dont have a great grip on acls, but you can always try slapacl to test your acls.

hope that helps.

brendan

Hello,

Indeed, slapacl(8) shows that I have read only access to DIT entries. I tried hijacking DIT databases, as in below:

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=ldap,dc=com" write by dn="cn=config" wri te by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=ldap,dc=com" wr ite by * read

This does not get me what I need.

Thank you,

Igor Shmkuler

On Fri, Mar 20, 2015 at 6:42 AM, Igor Shmukler igor.shmukler@gmail.com wrote:

Hello Brendan,

If there is no way to grant access to all records across all databases to cn=config [because it is not a user], I would go for having a [different] user who can delete records in multiple DITs[, by invoking LDAPI or whatever].

I will look into slapacl(8C). Did not there a tool for this. Not sure it will help someone like myself, but I will certainly try.

Thank you,

Igor Shmukler

On Fri, Mar 20, 2015 at 2:07 AM, Brendan Kearney bpk678@gmail.com wrote:

...

On Thu, 2015-03-19 at 23:35 +0200, Igor Shmukler wrote:

...

Hello Dan and Michael,

I have a server with a config database and a few DIT databases. I use online configuration. A little white ago, I knew nothing about OpenLDAP. Now, your help, I understand a lot more, yet still little and able to achieve even less..

I want individual administrators [those from within each DIT] to be able to browse within their tree, and cn=config administrator to be able to search through all records on the server, across DITs. If this is too difficult, I would go for LDAPI. As a temporary workaround, LDAPI would be amazing.

None of it working, yet. I tried a bunch of suggestions, many of which I don't fully understand. Nothing worked so far.

Specifically, I cannot understand why should not the below applied to the config database does not work, if I did set the password. olcAccess: {0}to * by dn="cn=config" manage

Sincerely,

Igor Shmukler

On Thu, Mar 19, 2015 at 11:16 PM, Dan White dwhite@cafedemocracy.org wrote:

...

On 03/19/15 23:05 +0200, Igor Shmukler wrote:

...

Hello Dan,

I must have done something wrong, yet this thing did not work either. One: the delete still failed with the usual error, and second - I got an error concerning my olcs:

550b380f /etc/ldap/slapd.d: line 1: rootdn is always granted unlimited privileges. 550b380f olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix

You don't need to set olcRootPW in this case. See slapd-config(5).

-- Dan White

i think you are missing a key notion about cn=config. it is not a user object. you do not grant it access to anything. you grant someone/something access to *it*.

i have an acl granting a group in my directory manage access to my cn=config instance (mind the wrap):

{0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by group.exact="cn=ldapEngineers,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" manage by * none

so the root user on the local machine, and members of the ldapEngineers group are allowed to manage the cn=config instance.

then i have an acl granting a group in my directory manage access to my dc=bpk2,dc=con instance (mind the wrap):

{0}to dn.subtree="dc=bpk2,dc=com" by group.exact="cn=ldapAdmins,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" manage by dn="cn=kadmin,dc=bpk2,dc=com" write by dn="cn=kdc,dc=bpk2,dc=com" read by users read by anonymous auth by * none

members of the ldapAdmins group are allowed manage access to the directory, kerberos process id's are allowed read or write access, users can read, etc.

it took me a while to figure the above out, and i still dont have a great grip on acls, but you can always try slapacl to test your acls.

hope that helps.

brendan

Hello Ferenc,

Thank you for the answer. This is even more confusing. I am going to slightly rephrase what you were suggesting, only to confirm that I understood you. I am not at all sure I did

I have an OpenLDAP server with multiple databases: a config database - {0)config,cn=config plus several for DITs {1}hdb,cn=config and also {2}hdb,cn=config ... {n}hdb,cn=config

Are you saying that I could pick an administrator associated with database X [last say 2] for some domain dc=example,dc=com and give this user identified by DN: cn=admin,dc=example,com rights to manage records in all DITs? Basically, something like "$ldapdelete -x -D cn=admin,dc=example,dc=com -W cn=john,dc=directory,dc=com" would successfully delete an entry from a DIT with index Y [say 1].

I apologize for asking these questions, but I have been given a lot of advice some of which was aimed to solve other problems. Apparently, my ability to clearly explain what I need is not much better than the ability to comprehend OpenLDAP docs.

Sincerely,

Igor Shmukler

On Fri, Mar 20, 2015 at 10:19 AM, Ferenc Wagner wferi@niif.hu wrote:

Igor Shmukler igor.shmukler@gmail.com writes:

...

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=ldap,dc=com" write by dn="cn=config" wri te by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=ldap,dc=com" wr ite by * read

OK, I think I understand your problem now. As Brendan mentioned, cn=config is not a user object, you can't set a userPassword on it. It's still possible to bind to it, because it's your RootDN, and RootPW is set. But this will give it access to its own database only, and skip ACL processing anyway. So the idea I gave you is good, but you have to use a normal user object with userPassword instead of cn=config. You can't create such an object in the config database, but anything else goes; let's say its cn=root,dc=example,dc=com. Use this in your ACLs for each database (cn=config included, if you want):

olcAccess: {0}to * by dn.base=cn=root,dc=example,dc=com manage [...]

and you should be set. So to correct my answer to your original question: what you want (use cn=config with simple bind to manage all your databases) is not possible. Using any normal user object instead of cn=config should work, though. At least according to my limited understanding. Sorry for mistaking this earlier. -- Regards, Feri.

Howard Chu hyc@symas.com writes:

Ferenc Wagner wrote:

...

Igor Shmukler igor.shmukler@gmail.com writes:

...

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=ldap,dc=com" write by dn="cn=config" wri te by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=ldap,dc=com" wr ite by * read

OK, I think I understand your problem now. As Brendan mentioned, cn=config is not a user object, you can't set a userPassword on it. It's still possible to bind to it, because it's your RootDN, and RootPW is set. But this will give it access to its own database only, and skip ACL processing anyway. So the idea I gave you is good, but you have to use a normal user object with userPassword instead of cn=config. You can't create such an object in the config database, but anything else goes; let's say its cn=root,dc=example,dc=com. Use this in your ACLs for each database (cn=config included, if you want):

olcAccess: {0}to * by dn.base=cn=root,dc=example,dc=com manage [...]

and you should be set. So to correct my answer to your original question: what you want (use cn=config with simple bind to manage all your databases) is not possible. Using any normal user object instead of cn=config should work, though. At least according to my limited understanding. Sorry for mistaking this earlier.

This is false. You can use cn=config with simple bind just like any other RootDN.

Sure, I also wrote above that he can (simple) bind to it, because it's the RootDN and RootPW is also set. But will it still participate in ACL processing for other databases? I mean, can you use it in ACLs just like any normal user object with a userPassword?

Also, what happens if several databases have the same RootDN?

Igor,

Igor Shmukler schrieb (20.03.2015 07:24 Uhr):

Indeed, slapacl(8) shows that I have read only access to DIT entries. I tried hijacking DIT databases, as in below:

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=ldap,dc=com" write by dn="cn=config" wri te by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=ldap,dc=com" wr ite by * read

This does not get me what I need.

additional to what Ferenc said:

- you have a data DIT in a database -- which seems to be under dc=ldap,dc=com in your case -- you can define a rootdn (user) for the database --- which is allowed to do anything in the database --- and bypasses all the ACLs -- ACLs define who (user entries and groups) can do what with your data --- ACLs are stored in the configuration -- the configuration of the database is _not_ inside the database itself but in the config

- you have a configuration of slapd -- which contains the database configuration --- like the database directory --- ACLs --- or the rootdn

- configuration can be in a file (slapd.conf) or in a database (cn=config; config backend) -- slapd.conf is edited in the file, so no need for a ldap user to modify it -- cn=config is a database --- like in the database for your actual data you have to define who can change the config database --- with a rootdn or by ACL

- a rootdn can be -- a (non existing) dn in the database with the rootpw defined in the config -- or a dn of a user entry somewhere inside your database --- with password defined in the entry --- mapped by authz-regexp (like Michael already explained)

To modify your data, you need a ACL or the rootdn for the database. To change the rootdn or the ACL you need to change the configuration. If the configuration is inside the configuration backend, you need to be able to change the database cn=config. So rootdn or ACL for cn=config must exist. If you are using cn=config it would be best you have a full working ldif to import and initialize cn=config with instead of trying to alter cn=config online/by ldapmodify to be able to change it.

I hope this clears things up a bit.

For additional infos see the man pages and the Admin guide.

Marc

Hi,

I have been trying to understand configuration OpenLDAP for a while. It is a challenge for me. Even people on this list, who know OpenLDAP [unlike your's truly] are at times contradicting one another. As we see from this thread, there are others confused about access configuration, too. If not for your and others' help, I would not even understand as much.

Seems to me that not many know how to write ACLs for OpenLDAP. This is obviously moot. I just need to figure out what can done, this time. I am not an administrator. If I can get my program, utilizing OpenLDAP as a backend, to work, I will be happy enough. :)

Of course, unless someone suggests something that works, I have no choice but analyze every example out there, at least for a bit longer. I figure that if nothing comes through by Sunday, it should consider throwing backend away and switching to a different architecture. Obviously OpenLDAP works well, but if I am not smart enough to get it to work as needed, it is not much good to me.

Sincerely,

Igor Shmukler

On Friday, March 20, 2015, Michael Ströder michael@stroeder.com wrote:

Igor Shmukler wrote:

...

If there is no way to grant access to all records across all databases to cn=config [because it is not a user], I would go for having a [different] user who can delete records in multiple DITs[, by invoking LDAPI or whatever].

You should really analyze this example configuration:

https://build.opensuse.org/package/view_file/home:stroeder:branches:network:...

Ciao, Michael.

Hello Michael,

Thank you for additional information.

I tried to do remapping inside a DIT database. Wrote the tiny snippet below: $ cat set_config_regexp.ldif dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcAuthzRegexp olcAuthzRegexp: {0}"gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=admin,dc=directory,dc=com"

$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f set_config_regexp.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={1}hdb,cn=config" ldap_modify: Object class violation (65) additional info: attribute 'olcAuthzRegexp' not allowed

I obviously do not know whether something is wrong with my syntax, or whether messed-up syntax could produce the above error. Seems more like than a syntax problem.

It appears to me that remapping anything for olcDatabase={0}config,cn=config would not help me either. I have multiple DITs each managed by a separate RootDN.

What am I doing wrong?

Sincerely,

Igor Shmukler

On Fri, Mar 20, 2015 at 9:47 AM, Michael Ströder michael@stroeder.com wrote:

Igor Shmukler wrote:

...

Seems to me that not many know how to write ACLs for OpenLDAP.

It's not that hard for your case.

See relevant building blocks from

https://build.opensuse.org/package/view_file/home:stroeder:branches:network:...

attached below.

As user root you can then write cn=config and dc=example,dc=com and initialize the data. The group cn=slapd admins,ou=groups,dc=example,dc=com can read cn=config and manage dc=example,dc=com.

You alter by-clause for cn=config

by group.base="cn=slapd admins,ou=groups,dc=example,dc=com" manage

to let this group also write to cn=config.

I spend some time creating this public example config. There's no way around learning a bit more though. You should read and understand the example which takes less time than writing so many list postings and wait for detailed answers. But please understand I don't have the time to help in every detail.

Ciao, Michael.

--------------------- snip ---------------------

[..]

# If connected via IPC socket (ldapi:///) and SASL/EXTERNAL was used # System user root is mapped to the rootdn in database dc=example,dc=com # which has also read access on config and monitor databases authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=root,dc=example,dc=com"

[..]

#--------------------------------------------------------------------------- # cn=config // Configuration database (always first!) # see slapd-config(5) #---------------------------------------------------------------------------

database config

# Cleartext passwords, especially for the rootdn, should # be avoid! See slappasswd(8) and slapd.conf(5) for details. # Best thing is not to set rootpw at all! # For local config access by root use LDAPI with SASL/EXTERNAL instead # (see above). #rootpw secret

access to dn.subtree="cn=config" by dn.exact="cn=root,dc=example,dc=com" manage by group.base="cn=slapd admins,ou=groups,dc=example,dc=com" read by * none

[..]

#--------------------------------------------------------------------------- # dc=example,dc=com // Example MDB database to be used by normal clients # see slapd-mdb(5) #---------------------------------------------------------------------------

database mdb

suffix "dc=example,dc=com"

[..]

# Catch-all ACL for the rest access to dn.subtree=dc=example,dc=com by group.base="cn=slapd admins,ou=groups,dc=example,dc=com" manage by self read by users read by * auth