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 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>
--
John Alexander
Systems Administrator
Concentric Sky, Inc