This LDAP is an inherited project that has taken me quite some time to begin to understand and ACLs are certainly on my list.

slapcat was working properly until I applied the ppolicy overlay. Then I started to get the error. The order I did was:

slapcat -n 0 to pull a backup (this worked) apply the ppolicy schema apply the ppolicy module (or try - this seems to be where it started to go wrong) apply the ppolicy overlay (a bad decision in retrospect)

for better or worse, I attempted to load the module ppolicy.la (rather than ppolicy - with no .la) and got this error:

SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=module{0},cn=config" ldap_modify: Other (e.g., implementation specific) error (80)

However ldapsearch of cn=module{0},cn=config shows this: # 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 olcModuleLoad: {3}ppolicy.la

examination of cn=module{0}.ldif shows that the last 2 entries are not being written

The systemd unit file is getting the following:

SLAPD_CONFIG_FILE=/etc/openldap/slapd.conf (which does not exist) SLAPD_CONFIG_DIR=/etc/openldap/slapd.d (this is correct)

So it <appears> that it is working with the correct directory. Permissions and ownership is correct. For some reason, it appears that ldapmodify is not writing to cn=module{0}.ldif

I apologize if my conjecture is off base.

John Alexander

On Mon, Jun 8, 2020 at 12:12 PM Quanah Gibson-Mount quanah@symas.com wrote:

--On Monday, June 8, 2020 12:23 PM -0700 John Alexander jalexander@concentricsky.com wrote:

...

Thank you for your patience, Quanah. The ldapsearch output of cn=config is below (with passwords redacted):

What you really need to track down is where slapd's configuration is actually stored, so you can slapcat it correctly. The ldapsearch output shows a valid configuration, where ppolicy is loaded, the schema exists, and the overlay is attached to the HDB database.

Your ACLs are a bit of a mess, and I think that "by * read" on userPassword is a *very* bad idea, but the first part needs fixing first.

Regards, Quanah

--

Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com