6

I'm attempting to follow several tutorials on setting the root LDAP password (our previous sysadmin departed...abruptly), which all say more or less the same thing:

...but getting stuck at the first step. This seems bad:

# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b  cn=config
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
No such object (32)

What I've tried so far:

I can locate the data that query is intended to retrieve by digging it out of the slapd-config files:

# find /etc/ldap/slapd.d -type f -exec grep Root {} +
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif:olcRootDN: cn=admin,cn=config
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif:olcRootPW: {SSHA}[xxxxxx hash redacted xxxxxx]
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcRootDN: cn=admin,dc=example,dc=com
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcRootPW: {SSHA}[xxxxxx hash redacted xxxxxx]

and confirmed that slapd is in theory set up to read from those files:

# ps -ef | grep slapd
openldap  2244     1  0 Oct26 ?        00:00:16 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d

When I turn on ACL logging (and run from the command line; turning on logging from init.d makes slapd hang on start) I get this:

5bdb2ef2 => access_allowed: search access to "cn=config" "entry" requested
5bdb2ef2 => acl_get: [1] attr entry
5bdb2ef2 => acl_mask: access to entry "cn=config", attr "entry" requested
5bdb2ef2 => acl_mask: to all values by "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth", (=0)
5bdb2ef2 <= check a_dn_pat: *
5bdb2ef2 <= acl_mask: [1] applying none(=0) (stop)
5bdb2ef2 <= acl_mask: [1] mask: none(=0)
5bdb2ef2 => slap_access_allowed: search access denied by none(=0)
5bdb2ef2 => access_allowed: no more rules

Ideas?

krivard
  • 192
  • 2
  • 9

2 Answers2

5

I've stumbled over this issue myself but wasn't satisfied by accepted answer as it points out the reason for the issue but is very limited on providing actual instructions on how to fix it. So I kept searching and stumbled over this issue.

Precondition

I like using this SASL/EXTERNAL approach and as I'm trying to create a docker container setting up slapd properly is part of my intention. The problem is: how to set access rights on cn=config. The container is converting some initial slapd.conf file into cn=config on first start when there is no existing cn=config in configuration folder selected with option -F. So there must be some way to have cn=config setting up permissions as desired.

Analysis

Using rootDN seems to be odd as it is configured in scope of different database and according to previously resulting cn=config configuration still is bound to different database.

In addition cn=config is configured to grant none permissions to everyone accessing anything in database at cn=config. Check the file /your/config/dir/cn=config/olcDatabase={0}config.ldif:

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 e01f7658
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to *  by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: a85462ad-0102-456d-a2d7-e6d082b7e613
creatorsName: cn=config
createTimestamp: 20190429143842Z
entryCSN: 20190429143842.339724Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20190429143842Z

It clearly states olcAccess: {0}to * by * none so I'm pretty sure using rootDN doesn't help either.

In an existing LDAP server there is a different access rule applied: 

olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth manage by * break

So, this is what I need in my case!

Solution

When converting from slapd.conf to cn=config slapd and its tools are accepting partial configuration for the resulting database. olcDatabase={0}config is the resulting DN for a database named config. So add configuration for that database in your file. The following excerpt appended to the end of my slapd.conf file has been taken from issue linked before:

database config
access to *
    by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
    by * read

Don't miss to remove any existing configuration folder so the updated slapd.conf file will be converted to cn=config once again.

Thomas Urban
  • 202
  • 2
  • 10
  • `Never add the rootdn to the by clauses. ACLs are not even processed for operations performed with rootdn identity (otherwise there would be no reason to define a rootdn at all).` https://www.openldap.org/doc/admin24/access-control.html – 84104 May 03 '19 at 16:02
  • 2
    @84104 Your falling into trap of ambiguous documentation here. The rootDN is defined in scope of a database. So are ACLs. The quoted rule is true for accessing the database the rootDN is associated with. But a single LDAP server can house multiple databases and `cn=config` is just one of them. If either database's rootDN would be capable of gaining full access on any defined databases this would be a great mess. So, just try it out yourself: unless granting `access to * by * read` on database config the rootDN of your "actual" database can't read anything at suffix `cn=config`. Tried myself. – Thomas Urban May 04 '19 at 21:49
  • Yes, each db has its own rootdn. Multiple DITs can share the same rootdn. – 84104 May 05 '19 at 02:09
2

On a number of modern Linux systems root as identified by SASL/EXTERNAL as gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth is either the rootDN or has manager permissions when openldap-server/slapd is installed.

For your existing installation that is not currently the case.
If you know the password for your various rootDNs, use those. Otherwise, replace your rootDN (or it's password) to something you can use. You'll have to do this outside of LDAP by editing /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif or your equivalent and restarting slapd.

84104
  • 12,905
  • 6
  • 45
  • 76
  • No passwords are available, only systems root access. Is replacing one's rootDN an ldapmodify thing or a slapcat/edit/slapadd thing? – krivard Nov 02 '18 at 19:15