0

I have an OpenLDAP server on CentOS 7.8 and am trying to get the ppolicy overlay loaded. I'm attempting to load in the module with this command:

ldapmodify -Y EXTERNAL -H ldapi:/// -f ppolicy_load.ldif

and I get this error:

add olcModuleLoad:
        ppolicy
modifying entry "cn=module{0},cn=config"
ldap_modify: Type or value exists (20)
        additional info: modify/add: olcModuleLoad: value #0 already exists

The contents of ppolicy.ldif:

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy

cn=module{0},cn=config.ldif contents:

dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov

additional info:

ldapsearch of cn=module{0},cn=config yields the following:

# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}ppolicy

The ppolicy schema was loaded. I also unfortunately applied the ppolicy overlay

dn: olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverLay: ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=mydomain,dc=com

and now, slapcat -n 0 yields the following error:

5ede54b5 UNKNOWN attributeDescription "OLCPPOLICYDEFAULT" inserted.
5ede54b5 config error processing olcOverlay={1}ppolicy,olcDatabase={2}hdb,cn=config:
slapcat: bad configuration file!

I assume this is due to the module not being properly loaded and now have a touch of a problem.

Can anyone provide guidance on how to get this working? I configured this on test servers that I derived from my main ldap server with no problem.

Thanks.

JohnA
  • 586
  • 3
  • 13
  • Interestingly, doing an ldapsearch on cn=module{0},cn=config indicates that ppolicy module is loaded. – JohnA Jun 06 '20 at 17:27

1 Answers1

0

The solution to this problem was to import the config database backup I had previously made right before beginning the work on ppolicy:

  • shut down slapd
  • move /etc/openldap/slapd.d to a new home
  • slapadd -n 0 -F /etc/openldap/slapd.d -l config.ldif
  • chown -R ldap:ldap /etc/openldap/slapd.d
  • restart slapd

The issue here appears to have been that the entry: 

cn=module{0},cn=config

did not have the creation metadata that all the other entries have. Here is the relevant section from the slapcat of the config database before I started working on applying ppolicy

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov

here is that same part from a slapcat dump I took right after the restore

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
structuralObjectClass: olcModuleList
entryUUID: 1c4f8c4c-3eb1-103a-867c-85064373bd37
creatorsName: cn=config
createTimestamp: 20200609152452Z
entryCSN: 20200609153126.629105Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20200609153126Z

and so after restoring the config database, I was able to proceed with no issues with configuration of ppolicy. Naturally I tested this on a clone of my LDAP server (yay ESX).

I suppose I could be off base, but since the problems all appear to have centered around cn=module{0},cn=config and is now fixed... I'll go with that.

JohnA
  • 586
  • 3
  • 13