2

I'm upgrading a Ubuntu 14.04 OpenLDAP server to 16.04 and running into a snag. There is an (localhost) import script which uses uses ldapdelete -r -Y EXTERNAL -H ldapi:///... to remove some OUs and then re-populate them with new information. This is failing due to what I suspect is a missing/changed olcAccess attribute. Anyone know why this isn't working?

I've run a line from the script by hand with this result:

# ldapdelete -r -Y EXTERNAL -H ldapi:/// "ou=people,dc=my,dc=org"
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
ldap_delete: Insufficient access (50)
        additional info: no write access to parent

I can use the olcRootDn to remove the OUs successfully however this requires putting the rootdn password somewhere which I'd rather not do.

# ldapdelete  -x -D "cn=admin,dc=my,dc=org" -W -h ldap1 "ou=people,dc=my,dc=org"
Enter LDAP Password: 

# ldapdelete  -x -D "cn=admin,dc=my,dc=org" -W -h ldap1 "ou=people,dc=my,dc=org"
Enter LDAP Password: 
ldap_delete: No such object (32)
        matched DN: dc=my,dc=org

I've run slapcat to view the olcAccess attributes -- it seems the dn-exact=... entries should be providing the correct permissions but that must be incorrect.

dn: olcBackend={0}hdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}hdb

dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500

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

dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=my,dc=org
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=my,dc=org
olcRootPW: {SSHA}(removed)...
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
Server Fault
  • 3,454
  • 7
  • 48
  • 88

1 Answers1

2

According to your configuration of {1}hdb database, The appropriate ACL for the root system user is missing. You should add:

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

This ACL must be the first one for this database (index {0})

Same ACL that is in the {-1}frontend database is appended to the ACLs list of {1}hdb. This mean added at the end of this list, ie after "olcAccess: {2}to * by * read" one. the "to * by * read" directive causes the ACL engine stop processing with only read right.

From the OpenLDAP administrator guide (See 5.2.5.2.):

Note: Access controls defined in the frontend are appended to all other databases' controls.

Abdelhamid MEDDEB
  • 461
  • 4
  • 5