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.

Improve this question
1
  • Interestingly, doing an ldapsearch on cn=module{0},cn=config indicates that ppolicy module is loaded. Commented Jun 6, 2020 at 17:27

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.