On 2/5/21 8:40 AM, Uwe Sauter wrote: The above error means you did not load ppolicy schema. Add to slapd.conf: include /etc/openldap/schema/ppolicy.schema Adjust the path to match the exact path of your local OpenLDAP build. Ciao, Michael.

On 2/5/21 7:55 PM, Uwe Sauter wrote: Ah, forgot that this was changed to be hard-coded in slapo-ppolicy. So you have to load overlay ppolicy. Ciao, Michael.

On 2/5/21 8:15 PM, Uwe Sauter wrote: Then there's something else wrong with your setup which I can't tell. Ciao, Michael.

Am 5. Februar 2021 22:15:47 MEZ schrieb Liam Gretton <liam.gretton(a)gmail.com&gt;: Yes it is. Account locking after failed attempts, password changes honoring configured rules, password history etc. all works since this was set up in 2017. Back then I just forgot to hide the pwd* attributes that are managed by the ppolicy overlay. Perhaps I need to set up a minimal environment to figure this out... -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Am 06.02.21 um 00:29 schrieb Quanah Gibson-Mount: I'm not sure I understand the question. I am unable to configure the ACL because slaptest won't accept it and if I restart the running service it will fail during startup due to the bad configuration. So I cannot test the ACL. Never the less, the current situation is that an anonymous query will list the pwd* attributes (ldapsearch -x '(uid=myuser)' +). I want to restrict access to these attributes so that only the manager account can access them (lapdsearch -xWD cn=manager,dc=example,dc=com '(uid=myuser)' +). Regards, Uwe > 2.4.47: >    Fixed slapo-ppolicy with multi-provider replication (ITS#8927) > > 2.4.48: >    Fixed slapo-ppolicy behavior when pwdInHistory is changed (ITS#8349) > > 2.4.49: >    Fixed slapo-ppolicy when used with slapauth (ITS#8629) >    Fixed slapo-ppolicy to add a missed normalised copy of pwdChangedTime (ITS#9126) > > 2.4.50: >    Fixed slapo-ppolicy callback (ITS#9171) > > 2.4.51: >    Added slapo-ppolicy implement Netscape password policy controls (ITS#9279) >    Fixed slapo-ppolicy to expose the ppolicy control (ITS#9285) >    Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302) >    Fixed slapo-ppolicy so it can only exist once per DB (ITS#9309) > > 2.4.53: >    Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302,ITS#9334) > > I'd note again, Symas provides free drop-in replacement builds for CentOS/RHEL 7 that are current: > > <https://repo.symas.com/sofl/rhel7/> > > You will want to reload the database to account for the 2.4.49 fix for ITS#9126 (it requires a reload of the db via > slapcat/slapadd to fix the internal normalization of pwdChangedTime). > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>

--On Saturday, February 6, 2021 8:55 PM +0100 Uwe Sauter <uwe.sauter.de(a)gmail.com&gt; wrote: Snippets are not useful, as slapd.conf is contextual and it matters where certain directives exist. You need to provide your entire slapd.conf with sensitive parts redacted (i.e., passwords, hostnames if you care about them, etc). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

Hi all, just to wrap this up. It turned out that this was caused by a wrong order of including ACLs from a second file and loading the ppolicy plugin. With the correct order the pwd* attributes provided by the ppolicy module (not the schema file!) are available when the ACLs are parsed and thus the test succeeds. Regards, Uwe Am 05.02.21 um 08:40 schrieb Uwe Sauter: > Good morning, > > I'm trying to restrict access to the operational attributes that are provided by the ppolicy overlay > (e.g. pwdChangedTime, pwdHistory). > > When I add the following to my ACL configuration file and try to verify the configuration an error > occurs: > > #### ACL > access to attrs=pwdHistory > by * none > ######## > > #### slaptest output > 601cf554 /etc/openldap/acl.conf: line 96: unknown attr "pwdHistory" in to clause > 601cf554 <access clause> ::= access to <what> [ by <who> [ <access> ] [ <control> ] ]+ > <what> ::= * | dn[.<dnstyle>=<DN>] [filter=<filter>] [attrs=<attrspec>] > <attrspec> ::= <attrname> [val[/<matchingRule>][.<attrstyle>]=<value>] | <attrlist> > <attrlist> ::= <attr> [ , <attrlist> ] > <attr> ::= <attrname> | @<objectClass> | !<objectClass> | entry | children > <who> ::= [ * | anonymous | users | self | dn[.<dnstyle>]=<DN> ] > [ realanonymous | realusers | realself | realdn[.<dnstyle>]=<DN> ] > [dnattr=<attrname>] > [realdnattr=<attrname>] > [group[/<objectclass>[/<attrname>]][.<style>]=<group>] > [peername[.<peernamestyle>]=<peer>] [sockname[.<style>]=<name>] > [domain[.<domainstyle>]=<domain>] [sockurl[.<style>]=<url>] > [dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]] > [ssf=<n>] [transport_ssf=<n>] [tls_ssf=<n>] [sasl_ssf=<n>] > <style> ::= exact | regex | base(Object) > <dnstyle> ::= base(Object) | one(level) | sub(tree) | children | exact | regex > <attrstyle> ::= exact | regex | base(Object) | one(level) | sub(tree) | children > <peernamestyle> ::= exact | regex | ip | ipv6 | path > <domainstyle> ::= exact | regex | base(Object) | sub(tree) > <access> ::= [[real]self]{<level>|<priv>} > <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage > <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+ > <control> ::= [ stop | continue | break ] > dynacl: > <name>=ACI <pattern>=<attrname> > > slaptest: bad configuration file! > #################### > > My questions: > > * How can I restrict access to operational attributes? Does this depend on the specific overlay? > > * Is this a bug in the ppolicy overlay? One might consider the pwd* attributes confidential but at > the same time allowing anonymous queries might be necessary. > > * Is there anything I miss (besides still using configuration files – they are way easier to handle)? > > Best, > > Uwe > > > >