How to set up proper access directive in LDAP? - ldap

I'm new to LDAP and for a school project I have an access to part of my school LDAP. I can bind with users that are in a Organizational Unit.
When I bind, I am able to see my password and not any other passwords from other users (That's normal I guess for security reasons).
So I have exported the LDIF of this LDAP and imported it on my own LDAP server for leaning purposes.
ldapsearch commands works well and I retrieve all entries (excepted password and that's normal).
So now, I try to bind with any user, I've added password by Apache Directory Studio in each LDAP Users (inetorgPerson under the ou where I usually search).
However, I can't bind.
I guess that it is due to wrong access rights.
I know that I must use ldapmodify command and that I need to forge a directive like access to * by * read (with less rights than * but it could be great to begin with).
However, I cant find how to use this directive with ldapmodify.
I think that I must create an LDIF file to modify config but I don't understand which entry I should update.
Can anyone give me tips in order to modify the proper entry?
Thanks
Here id part of my config (Domain edited to domain.fr):
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 * write
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=domain,dc=fr
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
olcRoot
dn: cn=admin,dc=domain,dc=fr
olcRootPW: {SSHA}YNGbI0zpbUoVLZggbKeZqFIlVdq+0ZJP
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824
search: 2

• Since, you have imported the LDIF file in the new AD, all the users in the original AD are created afresh in your AD environment. Thus, you would need to create a DNS naming service identical to the original one in your environment as the suffix to which you want to add the entry should exist in the database. Also, the domain admin credentials used in the original LDAP directory will be required to bind with the credentials of a user in imported LDIF file.
To do this, you would need to modify the domain admin credentials using the following commands. Below shown script is a sample on how to modify the domain admin credentials and then try to bind the user using those credentials.
Create a new LDIF file with the following contents: -
‘ dn: uid=XYZ,ou=Domain Administrators,dc=example,dc=com
cn: XYZ
sn: XYZ
givenName: XYZ
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: Accounting
ou: People
l: Santa Clara
uid: XYZ
mail: XYZ#example.com
roomnumber: 5484
userpassword: Pass#123 ’
Then, add the entry using ‘ldapmodify’ with the ‘—defaultAdd’ option
‘ ldapmodify --hostname localhost --port 389 --bindDN "cn=Directory Manager" \
--bindPassword password --defaultAdd --filename /tmp/new.ldif ‘
With these commands, you would be able to modify the domain administrator credentials and then be able to bind the user in LDAP for sure. Just change the ldif file name with the one you have and change the entries in the ldif file with the actual ones from the original directory. Please find this link below for your reference: -
https://docs.oracle.com/cd/E22289_01/html/821-1273/adding-modifying-and-deleting-directory-data.html

Related

OpenLDAP ACL not working - Error code 50 - No write access to parent

I built couple of OpenLDAP servers for an application service. Both the servers seem perfectly okay on the configuration side and I can manage these with Apache Directory Studio as RootDN cn=admin,dc=somedomain,dc=com. And the replication works between them too. These are built on RHEL8 by compiling OpenLDAP source code as OpenLDAP Server packages are not provided any more. The OpenLDAP version is 2.4.52.
I'm able to create OUs and also users through Directory Studio and used one of them in the app for authentication purposes as service account. In this case the user is uid=svc-admin,ou=Admins,ou=People,dc=somedomain,dc=com and the OUs are as below:
ou=Admins,ou=People,dc=somedomain,dc=com
ou=Readers,ou=People,dc=somedomain,dc=com
ou=Users,ou=People,dc=somedomain,dc=com
The requirement now is that user svc-admin should have write/full permissions to the above OUs as the app is designed to provision new users and it'll be writing into the above OUs using svc-admin as service account. It should be able to create users and modify their attributes.
I created an ACL and was able to apply it using ldapmodify however, when I connect to the LDAP server as the svc-admin on Apache DS I can read but cannot modify or create new users. When I do that I get an error both via Apache DS and as well as in shell. Insufficient right - Error 50 - No write access to parent.
Here's the ACL that I used:
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to dn.subtree="ou=People,dc=somedomain,dc=com" by dn.exact="uid=svc-admin,ou=Admins,ou=People,dc=somedomain,dc=com" write
olcAccess: to dn.subtree="ou=Users,ou=People,dc=somedomain,dc=com" by dn.exact="uid=svc-admin,ou=Admins,ou=People,dc=somedomain,dc=com" write
olcAccess: to dn.subtree="ou=Readers,ou=People,dc=somedomain,dc=com" by dn.exact="uid=svc-admin,ou=Admins,ou=People,dc=somedomain,dc=com" write
It's not working. And here are my olcDatabase={1}mdb and olcDatabase={0}config files. I cleaned up the ACLs as they aren't doing any good.
olcDatabase={1}mdb
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 54063f10
dn: olcDatabase={1}mdb
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/openldap
olcSuffix: dc=somedomain,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange,shadowExpire by self wr
ite by anonymous auth by dn.subtree="gidNumber=0+uidNumber=0,cn=peercred,cn
=external,cn=auth" manage by * none
olcAccess: {1}to dn.subtree="dc=somedomain,dc=com" by dn.subtree="gidNumber=
0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by users read by * re
ad
olcRootDN: cn=admin,dc=somedomain,dc=com
olcRootPW:: e1NTSEF9dkc0ZkIyYkZrYVduNU1BbTdkAHQ5ZXE0WlFEUHBSSGk=
olcDbIndex: uid pres,eq
olcDbIndex: cn,sn pres,eq,approx,sub
olcDbIndex: mail pres,eq,sub
olcDbIndex: objectClass pres,eq
olcDbIndex: loginShell pres,eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbMaxSize: 42949672960
structuralObjectClass: olcMdbConfig
entryUUID: 3b57a8aa-b1d8-103a-87d6-7198db52aeab
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20201103042439Z
olcSyncrepl: {0}rid=003 provider=ldaps://ldapserver01.somedomain.com binddn="
cn=admin,dc=somedomain,dc=com" bindmethod=simple credentials="TestCreds" s
earchbase="dc=somedomain,dc=com" type=refreshAndPersist timeout=0 network-t
imeout=0 retry="30 5 300 +"
olcSyncrepl: {1}rid=004 provider=ldaps://ldapserver02.somedomain.com binddn="
cn=admin,dc=somedomain,dc=com" bindmethod=simple credentials="TestCreds" s
earchbase="dc=somedomain,dc=com" type=refreshAndPersist timeout=0 network-t
imeout=0 retry="30 5 300 +"
olcMirrorMode: TRUE
entryCSN: 20210202222100.054442Z#000000#001#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20210202222100Z
olcDatabase={0}config:
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 f2b26838
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=exter
nal,cn=auth" manage by self write by users read by anonymous auth
olcRootDN: cn=config
structuralObjectClass: olcDatabaseConfig
entryUUID: f1608708-b1d7-103a-8934-b724f0ebd8c8
creatorsName: cn=config
createTimestamp: 20201103042234Z
olcRootPW:: e1NTSEF9dkc0ZkIyYkZrYVduNU1BbTdkAHQ5ZXE0WlFEUHBSSGk=
olcSyncrepl: {0}rid=001 provider=ldaps://ldapserver01.ugo-wallet.com binddn="
cn=config" bindmethod=simple credentials="TestCreds" searchbase="cn=config
" type=refreshAndPersist timeout=0 network-timeout=0 retry="30 5 300 +"
olcSyncrepl: {1}rid=002 provider=ldaps://ldapserver02.ugo-wallet.com binddn="
cn=config" bindmethod=simple credentials="TestCreds" searchbase="cn=config
" type=refreshAndPersist timeout=0 network-timeout=0 retry="30 5 300 +"
olcMirrorMode: TRUE
entryCSN: 20210202221926.832349Z#000000#001#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20210202221926Z
How can I solve this. Any help in tackling this problem is greatly appreciated.
I think this might not be the appropriate approach but it worked for me. I removed the below ACLs from olcDatabase={1}mdb ..
olcAccess: {0}to attrs=userPassword,shadowLastChange,shadowExpire by self wr
ite by anonymous auth by dn.subtree="gidNumber=0+uidNumber=0,cn=peercred,cn
=external,cn=auth" manage by * none
olcAccess: {1}to dn.subtree="dc=somedomain,dc=com" by dn.subtree="gidNumber=
0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by users read by * re
ad
..and add the below ones in LDIF file and now the user account svc-admin can do everything in that application wants it to do.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attrs=userPassword by self write by dn.exact="uid=svc-admin,ou=Admins,ou=People,dc=somedomain,dc=com" write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by dn.exact="uid=svc-admin,ou=Admins,ou=People,dc=somedomain,dc=com" write by * read
olcAccess: {2}to dn.subtree="ou=People,dc=somedomain,dc=com" by dn.exact="uid=svc-admin,ou=Admins,ou=People,dc=somedomain,dc=com" write
olcAccess: {3}to * by * read

ldapadd adds entries without userPasswords

I have a LDAP database, imported from this LDIF:
dn: olcDatabase=hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: hdb
olcDbDirectory: /var/lib/ldap-jenkins
olcSuffix: dc=example,dc=com
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW:: e1NTSEF9YmkzUDlFa1ZycDJMb2JDRDZoRmJmNkpLR2xhNWV2Q1doQzBOWmc9PQ==
olcDbIndex: uid eq
olcDbIndex: mail eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: objectClass eq
olcAccess: to attrs=userPassword,shadowLastChange
by self write
by dn="cn=admin,dc=example,dc=com" write
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
by anonymous auth
by * none
olcAccess: to *
by self write
by dn="cn=admin,dc=example,dc=com" write
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by dn="cn=jenkins,dc=example,dc=com" read
by * none
I'm trying to import this entry with # ldapadd -c -Y EXTERNAL -H ldapi:/// -f darth_vader.ldif:
dn: mail=darth.vader#death.star,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: simpleSecurityObject
objectClass: person
cn: Anakin
sn: Skywalker
mail: darth.vader#death.star
userPassword: e1NTSEF9LzVHNXczbUViYnlJaE5CM0RBdGRjS3I3c1hYN085em90d3B3QWc9PQ==
The entry is imported, but without userPassword. What's wrong?
So, the issue was the way I connect to the database, not with the import. I was connecting using jenkins user which does not have access to the userPassword attribute as specified in the ACL. He just does not see that attribute.
What I need to do is to add some permissions for him:
olcAccess: to attrs=userPassword,shadowLastChange
by self write
by dn="cn=admin,dc=example,dc=com" write
by dn="cn=jenkins,dc=example,dc=com" read
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
by anonymous auth
by * none
Read is sufficient, but, probably, lower level like auth or compare will work too.

LDAP multiple structural objectclasses

I am quite new in administering LDAP, but I have come quite far...
On my OpenLDAP server I am using phpLDAPadmin to do the following:
I have an entry with a structural objectclass account because I need the attribute host.
Now I want to add the attribute mail to this entry, but this does not appear in the list when selecting Add new attribute.
So I thought I could add the objectClass inetOrgPerson which has the attribute mail but this objectClass is not in the list of classes I can add to this entry; only non-structural classes are listed...
How can I add this attribute mail to a an entry with the structural class account ?
This is the current ldif for this user (with some parts changed/removed for privacy)
# Entry 1: cn=intrixius,ou=Admins,ou=Managed,dc=bla,dc=eu
dn: cn=intrixius,ou=Admins,ou=Managed,dc=bla,dc=eu
cn: intrixius
gecos: intrixius
gidnumber: 500
homedirectory: /home/intrixius
host: host1
host: host2
loginshell: /bin/bash
objectclass: top
objectclass: account
objectclass: posixAccount
objectclass: shadowAccount
objectclass: ldapPublicKey
sshpublickey: ssh-rsa ... intrixius#arch
uid: intrixius
uidnumber: 16859
userpassword: {CRYPT}$6$X...
You can't have multiple STRUCTURAL object classes unless they form a single inheritance hierarchy.
If you can modify the schema of your LDAP server, you could create a new auxiliary class with the attribute 'mail' and assign it to your account. Some implementations also support the 'extensibleObject' auxiliary class that allows adding all attributes that are defined in the schema.
A good overview about class types etc. can be found here

LDAP with Cloudera hue integration

I have configured LDAP server in my ubuntu 12.04 in the same server Cloudera core hadoop service installed . Here i want to integrate cloudera hue with LDAP server.
Following is my LDAP users
root#ip-10-81-160-152:/home/ubuntu# ldapsearch -x -b "dc=gmps,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=gmps,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# gmps.com
dn: dc=gmps,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: gmps
dc: gmps
# admin, gmps.com
dn: cn=admin,dc=gmps,dc=com
cn: admin
description: LDAP administrator
objectClass: simpleSecurityObject
objectClass: organizationalRole
objectClass: uidObject
uid: admin
ou: admin
# aaryan aditya, students, users, gmps.com
dn: cn=aaryan aditya,cn=students,ou=users,dc=gmps,dc=com
cn: aaryan aditya
givenName: aaryan
gidNumber: 500
homeDirectory: /home/users/aditya
sn: aditya
loginShell: /bin/sh
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
uidNumber: 1000
uid: aditya
i use phpldapadmin to login my LDAP server which was working fine ..
My Login DN: cn=admin,dc=gmps,dc=com
I have configured this ldap server in Hue cloudera as
ldap_url : ldap://75.101.250.10
LDAP Username Pattern : "uid=admin,ou=admin,dc=greycampus,dc=com"
user_name_attr: admin
After this i restarted HUE and i just logged into HUE web UI there if click on
Hue ---> Manage Users ---> Sync LDAP users and groups --> Sync
i am not getting any users syced from LDAP server ..
if i click Add/Sync LDAP user .. then enter username and ok .. i am getting
There was an error when communicating with LDAP
{'info': 'invalid DN', 'desc': 'Invalid DN syntax'}
i dont know where i did wrong .. and its still confusing where i have supply my LDAP password .. and how hue communicate with LDAP without password .. kindly any one please help
I can't understand neither your LDAP configuration nor your Hue configuration.
firstly you define your LDAP root, dc=gmps,dc=com, ok.
Next, you define an admin role, which is definitly not a user, just a role.
dn: cn=admin,dc=gmps,dc=com
Finally you define a user, which doesn't seem to be linked to the admin role.
If you don't have any relation defined between a user and a role, it'll be difficult for hue to grant something to your user.
Next, about yourr Hue configuration:
The user should be a parameter of the pattern.
If a user DN is dn: cn=aaryan aditya,cn=students,ou=users,dc=gmps,dc=com, your pattern should be at least something like cn=
Hue webapp substitute by the typed login and make a first request to validate the authentification of your user (aka username/password against the LDAP user information).
To perform the search, you need to define the LDAP base search (dc=gmps,dc=com) and a bind user, authorized user DN to look into your LDAP (for instance, cn=aaryan aditya,cn=students,ou=users,dc=gmps,dc=com)
If you want to limit the global access to just a portion of your LDAP, you can specify an additional filter. When you'll define a relation between users and roles, you'll can restrict the access to the users by their roles.
You have to specify what's the attribute you're considerating to identify the user (in your case, it seems to be cn, so user_name_attr = cn)
To do the mapping between LDAP and Hue permissions, you have to tell Hue which roles are considerated, throw the group_filter. Next you have to specify the attribute of the role which allow to identify the role (in your case, it seems to be cn)
Finally, you have to tell to hue which attribute allows you to link a role to a user (which doesn't seem to be undefined in your configuration)
Next, restarting your cluster, everything should be ok. Syncing your users/group will load users and roles from your LDAP to Hue, next step will be configure each role in HUE to give it the expected permissions.

Adding an entry to OpenLDAP

I just Installed OpenLDAP on Ubuntu Server 12.10, and I added an ldif file using slapadd -c -l init.ldif as the following :
dn:dc=tpw,dc=uca,dc=ma
dc: tpw
objectClass: dcObject
objectClass: top
objectClass: domain
dn: ou=people,dc=tpw,dc=uca,dc=ma
ou: people
objectClass: organizationalUnit
objectClass: top
dn: ou=groupes,dc=tpw,dc=uca,dc=ma
ou: groupes
objectClass: organizationalUnit
objectClass: top
dn: uid=admin,ou=people,dc=tpw,dc=uca,dc=ma
uid: admin
sn: Admin
cn: Admin
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
userPassword:: e1NIQX0wRFBpS3VOSXJyVm1EOElVQ3V3MWhReE5xWmM9
mail: admin#uca.ma
givenName: admin
dn: cn=GI,ou=groupes,dc=tpw,dc=uca,dc=ma
uniquemember: uid=admin,ou=people,dc=tpw,dc=uca,dc=ma
cn: GI
objectClass: groupOfUniqueNames
objectClass: top
dn: cn=GP,ou=groupes,dc=tpw,dc=uca,dc=ma
uniquemember: uid=admin,ou=people,dc=tpw,dc=uca,dc=ma
cn: GP
objectClass: groupOfUniqueNames
objectClass: top
dn: cn=GT,ou=groupes,dc=tpw,dc=uca,dc=ma
uniquemember: uid=admin,ou=people,dc=tpw,dc=uca,dc=ma
cn: GT
objectClass: groupOfUniqueNames
objectClass: top
Now my ldap tree looks like this :
Then I tried to add a new inetOrgPerson using Apache Directory Studio, but I got this error :
[LDAP: error code 80 - index generation failed]
Then I tried the same thing using phpLDAPadmin, but I got this error :
Impossible d'ajouter l'objet au serveur LDAP.
LDAP dit :: Other (e.g., implementation specific) error
Erreur numéro :: 0x50 (LDAP_OTHER)
Then I created a file which I named xx.ldif :
dn: uid=xx,ou=people,dc=tpw,dc=uca,dc=ma
cn: XX
givenname: xx
mail: xx#edu.uca.ma
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
sn: XX
uid: xx
userpassword: toor
And I tried to add this entry using this command via terminal :
sudo ldapadd -x -D cn=Manager,dc=tpw,dc=uca,dc=ma -W -f xx.ldif
But I got this error :
ldap_add: Other (e.g., implementation specific) error (80)
additional info: index generation failed
How can I solve this problem ?
PS : In another scenario I deleted my database and I modified the file init.ldif wich contains all the entries I want to add, and I added the entry xx, then I imported my file using the slapadd command, but In this way I have to delete the database every time I want to add a new entry, which is not practical.
Edit1 :
This is the output of the command slapindex :
WARNING!
Runnig as root!
There's a fair chance slapd will fail to start.
Check file permissions!
5370d6f9 /etc/ldap/slapd.conf: line 95: rootdn is always granted unlimited privileges.
5370d6f9 /etc/ldap/slapd.conf: line 112: rootdn is always granted unlimited privileges.
5370d6f9 hdb_db_open: database "dc=tpw,dc=uca,dc=ma": database already in use.
5370d6f9 backend_startup_one (type=hdb, suffix="dc=tpw,dc=uca,dc=ma"): bi_db_open failed! (-1)
slap_startup failed
The first thing is that init.ldif file seems to be misconfigured :
domainComponent "uca" (dc=uca) is missing, there should be an entry (dcObject or domain objectClass) to define this attribute that holds a component of the domain name.
dcObject is intended to be used in entries for which there is an appropriate structural object class. For example, if the domain represents a particular organization, the entry would have as its structural object class 'organization', and the 'dcObject' class would be an auxiliary class.
domain is a structural object class used for entries in which no other information is being stored. The domain object class is typically used for entries that are placeholders or whose domains do not correspond to real-world entities.
In your .ldif file you can replace the first entry "dn: dc=tpw,dc=uca,dc=ma" with these 2 (then delete your database again and redo the slapadd command) :
dn: dc=uca,dc=ma
objectClass: top
objectClass: organization
objectClass: dcObject
dc: uca
o: an organization name (mandatory with 'organization' objectClass)
dn: dc=tpw,dc=uca,dc=ma
objectClass: top
objectClass: domain
dc: tpw
Second thing : obviously you have landed into an index issue. I think you do want to use indexes but if not, find and remove any line beginning with index from slapd.conf, e.g. :
index objectClass eq.
Remember to stop slapd and run slapindex after every change comitted to the index definitions in slapd.conf, and ensure all ldap clients have been disconnected before running slap commands to prevent database already in use messages.
So take the hints given you by slapindex. Don't run slapd as root, fix lines 95 and 112, and don't run slapd twice, or fix whatever is causing it to think the database is already in use.
While this isn't relevant to the OP's question, I ran into a similar error of:
bdb_db_open: database already in use
or
hdb_db_open: database "dc=XXX,dc=XXX,dc=XXX": database already in use.
One of our Openshift nodes went down and the PVC's (mount) /var/lib/ldap/ __db.001, __db.002 and __db.003 had become locked. After googling for hours, the only solution I found was to perform the following (and note, since it was OpenShift, I had to use a debug pod to get a shell).
mkdir /var/lib/ldap/backup
mv /var/lib/ldap/__db.* /var/lib/ldap/backup
Try and restart slapD, if it still fails as it did with one of OpenLDap instances, then move the alock file
mv /var/lib/ldap/__db.* /var/lib/ldap/backup
Restart slapD or in our instance delete the OpenShift pod and let it be recreated. Everything may now be working as it did for us - hope this might help anyone else running into the same issue.