Learning OpenLDAP, following an "older" tutorial-- hdb vs. mdb update needed, adjusting a step to move forward

Question

http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-provider.php

This 2017 tutorial uses the hdb olcDatabase-- modern installations default to mdb.

The step I am on is: http://www.rjsystems.nl/en/2100-d6-kerberos-openldap-provider.php#cncf

Change 2.1.1

# 2.1.1
dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {2}to *
  by self write
  by dn="cn=admin,dc=example,dc=com" write
  by * read

First, I know the version of OpenLDAP I am using defaults to mdb-- but, that simple change isn't enough.

I know the dn: olcDatabase={1}hdb,cn=config needs modified to get a match. I think this is removing admin rights when you are not logged into the OpenLDAP machine itself. But, I'm not smart enough yet to understand how to construct a good search string or even take it apart. I just haven't grokked it yet.

I did learn how to dump my config tree.

root@auth:~/ldap# slapcat -n 0
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
entryUUID: 4233e57c-461f-103b-823a-eddba7c2a4d6
creatorsName: cn=config
createTimestamp: 20210510210556Z
olcLogLevel: stats
entryCSN: 20210510211216.057315Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20210510211216Z

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
structuralObjectClass: olcModuleList
entryUUID: 42344030-461f-103b-8242-eddba7c2a4d6
creatorsName: cn=admin,cn=config
createTimestamp: 20210510210556Z
entryCSN: 20210510210556.957974Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20210510210556Z

...

dn: olcBackend={0}mdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}mdb
structuralObjectClass: olcBackendConfig
entryUUID: 423454b2-461f-103b-8243-eddba7c2a4d6
creatorsName: cn=admin,cn=config
createTimestamp: 20210510210556Z
entryCSN: 20210510210556.958497Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20210510210556Z

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=extern
 al,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500
structuralObjectClass: olcDatabaseConfig
entryUUID: 4233e996-461f-103b-823b-eddba7c2a4d6
creatorsName: cn=config
createTimestamp: 20210510210556Z
entryCSN: 20210510210556.955757Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20210510210556Z

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern
 al,cn=auth manage by * break
olcRootDN: cn=admin,cn=config
structuralObjectClass: olcDatabaseConfig
entryUUID: 4233ef9a-461f-103b-823c-eddba7c2a4d6
creatorsName: cn=config
createTimestamp: 20210510210556Z
entryCSN: 20210510210556.955910Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20210510210556Z

dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=bradchesney,dc=net
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * non
 e
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=bradchesney,dc=net
olcRootPW:: e1NTSEF9aGdrUVFacXpaMHBaTkVIYjVvalZwbEswQ1o5cWxsaXA=
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824
structuralObjectClass: olcMdbConfig
entryUUID: 423457f0-461f-103b-8244-eddba7c2a4d6
creatorsName: cn=admin,cn=config
createTimestamp: 20210510210556Z
entryCSN: 20210510210556.958581Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20210510210556Z

But, now what?

My guess is that I need to somehow hook on to olcDatabase-- which is there a few times in my config.ldif slapcat dump and delete those entries. My interpretation is that it is like classes in HTML-- you combine searching for classes until you distill down to the distinct subset of elements you wanted. Which may be an incorrect view.

score 2 · Accepted Answer · answered May 13 '21 at 07:25

2

My interpretation is that it is like classes in HTML-- you combine searching for classes until you distill down to the distinct subset of elements you wanted. Which may be an incorrect view.

This would be right for 'ldapsearch', where you give it a filter that matches against certain attributes (which often includes objectClass as the 1st condition) and it spits out the found entries.

But it's not correct for 'ldapmodify'. When modifying or deleting an entry, you always specify the exact entry DN that you want to update; in LDIF that's the dn: field. This is not an attribute-based filter at all – an entry's DN is its exact unique path, very much like a filesystem path.

(Often LDAP modifications are indeed made by first performing an attribute-based search to determine the entry DNs, then modifying each entry by its DN one by one.)

So when looking at a 'ldapsearch' or 'slapcat' output, you just take the value of the 'dn:' shown as the 1st line of each result. In your case, the entry describing the main database is olcDatabase={1}mdb,cn=config.

answered May 13 '21 at 07:25

user1686

10,162
1
26
42

1

This is a good answer. I would like to add that an LDAP object has many attributes, but only one of these attributes can be used to distinguish it from the other objects, in this case, oldDatabase is the distinguishing attribute, and thus the distinguished name (dn:) is then olcDatabase={1},cn=config (I think attribute=value,path) – feitingen May 13 '21 at 16:07
1

@feitingen: That's not entirely true – a multi-attribute RDN is actually allowed, e.g. `cn=Fred+sn=Foobar` is a valid RDN. (Each RDN is encoded as a _set_ of attribute=value pairs in X.500, and that was inherited by LDAP.) Some LDAP servers have schema checks to limit which attributes of a given object class can act as distinguishing attributes (some don't), but even in that case it is not necessarily limited to one; e.g. either `cn` and `uid` could used for a posixAccount. – user1686 May 13 '21 at 17:08
Ah, so what the tutorial is getting me to change is "olcAccess: {2}to * by * read" ...I found that I could remove that change and continue (albeit with a less secure installation). But, I think I might fire up the VM snapshot to right before the change and try again. – BradChesney79 May 13 '21 at 17:13

Learning OpenLDAP, following an "older" tutorial-- hdb vs. mdb update needed, adjusting a step to move forward

1 Answers1