How to set an olcAccess attribute so gidNumber=0+uidNumber=0 works like olcRootDN? – A server stack is the collection of software that forms the operational infrastructure on a given machine. In a computing context, a stack is an ordered pile. A server stack is one type of solution stack — an ordered selection of software that makes it possible to complete a particular task. Like in this post about How to set an olcAccess attribute so gidNumber=0+uidNumber=0 works like olcRootDN? was one problem in server stack that need for a solution. Below are some tips in manage your linux server when you find problem about linux, openldap, ubuntu-16.04, , .
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
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.