8

I'm trying to load the password policy overlay but I'm having the following error:

ldapadd  -Wx -D "cn=Manager,cn=config"  -f overlay.ldif 
Enter LDAP Password: 
adding new entry "olcOverlay=ppolicy,olcDatabase={0}bdb,cn=config"
ldap_add: No such object (32)
    matched DN: cn=config

This is the contents of the file:

dn: olcOverlay=ppolicy,olcDatabase={0}bdb,cn=config
olcOverlay: ppolicy
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcPPolicyDefault: cn=default,ou=Policies,dc=site,dc=com
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: FALSE

In the log I found:

config_add_internal: DN="olcOverlay=ppolicy,olcDatabase={0}bdb,cn=config" not child of DN="cn=config"

I'm using CentOS 6.3 and openldap-servers-2.4.23-26.el6_3.2.x86_64.

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
user27238
  • 117
  • 1
  • 4

2 Answers2

3

Some of the records in the cn=config database of OpenLDAP use number prefixes ({0}, {1}, etc). So when you go to modify something in the cn=config database, you have to make sure you're using the right DN (Distinguished Name: the path to the record). In OpenLDAP when using cn=config, the first olcDatabase entry is usually the config database itself (olcDatabase={0}config,cn=config). On my specific system, my main database is olcDatabase={1}hdb,cn=config.

If you don't know the DN of the olcDatabase you need to modify, the only way to know is to do a search and look through the results.

As for what those numbers (the {0} bit) are, they serve 2 purposes.

  1. They allow you to have multiple entries of the same name.
    You could have 2 olcDatabase=bdb databases, in which you'd have a problem as you cant have 2 entries with the same DN.
  2. They allow ordering.
    The LDAP protocol does not care about order. But you can prefix RDNs with {X} to allow ordering. In this specific case, I can't think of any reason off hand why the databases need to be ordered. But there are other critical use cases, such as in cn=schema,cn=config. In cn=schema, a schema can define an object class which depends on an attribute from a previous schema. As such the schemes must be loaded in order.
phemmer
  • 70,657
  • 19
  • 188
  • 223
  • Re: ordering - backend databases have historically been identified by the numeric index (implicit by the order of their definition) mostly for backup/restore purposes. Also, when multiple databases/suffixes are used, the subordinates must be defined before their superiors (parents). – mr.spuratic Oct 18 '14 at 18:38
1

olcDatabase={0}bdb,cn=config

needs to be changed to

olcDatabase={2}bdb,cn=config

jasonwryan
  • 71,734
  • 34
  • 193
  • 226
Dave
  • 11
  • 1