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
On 2/5/21 8:40 AM, Uwe Sauter wrote:
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
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.
Hi Michael.
Am 05.02.21 um 17:31 schrieb Michael Ströder:
On 2/5/21 8:40 AM, Uwe Sauter wrote:
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
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.
I would totally agree with you if that wasn't already the case.
### /etc/openldap/slapd.conf ### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/kerberos.schema include /etc/openldap/schema/freeradius.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/sudo.schema
# ACL definitions include /etc/openldap/acl.conf [many more lines] ################################
#### /etc/openldap/acl.conf #### access to dn.base="" by * read
access to attrs=userPassword,sambaLMPassword,shadowLastChange by dn="cn=Manager,dc=example,dc=com" write by dn="cn=radius-lookup,dc=example,dc=com" read by self write by * auth
[more acl entries]
## ppolicy # man 5 slapo-ppolicy access to dn.subtree="ou=Policies,dc=hlrs,dc=de" by dn="cn=Manager,dc=hlrs,dc=de" write by * none
access to attrs=pwdHistory by * none
[even more entries] ##################################
# slaptest 601d92d6 /etc/openldap/acl.conf: line 84: unknown attr "pwdHistory" in to clause […] slaptest: bad configuration file!
This is on CentOS with openldap-servers-2.4.44-22.el7.
Thanks,
Uwe
Ciao, Michael.
On 2/5/21 7:55 PM, Uwe Sauter wrote:
Am 05.02.21 um 17:31 schrieb Michael Ströder:
On 2/5/21 8:40 AM, Uwe Sauter wrote:
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
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.
I would totally agree with you if that wasn't already the case.
Ah, forgot that this was changed to be hard-coded in slapo-ppolicy. So you have to load overlay ppolicy.
Ciao, Michael.
Am 05.02.21 um 20:03 schrieb Michael Ströder:
On 2/5/21 7:55 PM, Uwe Sauter wrote:
Am 05.02.21 um 17:31 schrieb Michael Ströder:
On 2/5/21 8:40 AM, Uwe Sauter wrote:
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
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.
I would totally agree with you if that wasn't already the case.
Ah, forgot that this was changed to be hard-coded in slapo-ppolicy. So you have to load overlay ppolicy.
This is also already loaded, sorry I forgot to mention that.
The server is running this setup since 2017, with ppolicy in place. I just now realised that these pwd* attributes were open to everyone and wanted to restrict access to the manager account.
Regards,
Uwe
Ciao, Michael.
On 2/5/21 8:15 PM, Uwe Sauter wrote:
Am 05.02.21 um 20:03 schrieb Michael Ströder:
On 2/5/21 7:55 PM, Uwe Sauter wrote:
Am 05.02.21 um 17:31 schrieb Michael Ströder:
On 2/5/21 8:40 AM, Uwe Sauter wrote:
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
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.
I would totally agree with you if that wasn't already the case.
Ah, forgot that this was changed to be hard-coded in slapo-ppolicy. So you have to load overlay ppolicy.
This is also already loaded, sorry I forgot to mention that.
Then there's something else wrong with your setup which I can't tell.
Ciao, Michael.
On 2021-02-05 18:55, Uwe Sauter wrote:
# slaptest 601d92d6 /etc/openldap/acl.conf: line 84: unknown attr "pwdHistory" in to clause […] slaptest: bad configuration file!
This is on CentOS with openldap-servers-2.4.44-22.el7.
I'm using 2.4.50 (my own build) on CentOS 7 and I have ACLs on this and other ppolicy attributes without any problems.
You obviously have the ppolicy schema included, but is the ppolicy overlay actually loaded?
Am 5. Februar 2021 22:15:47 MEZ schrieb Liam Gretton liam.gretton@gmail.com:
On 2021-02-05 18:55, Uwe Sauter wrote:
# slaptest 601d92d6 /etc/openldap/acl.conf: line 84: unknown attr "pwdHistory"
in to clause
[…] slaptest: bad configuration file!
This is on CentOS with openldap-servers-2.4.44-22.el7.
I'm using 2.4.50 (my own build) on CentOS 7 and I have ACLs on this and
other ppolicy attributes without any problems.
You obviously have the ppolicy schema included, but is the ppolicy overlay actually loaded?
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...
--On Saturday, February 6, 2021 12:06 AM +0100 Uwe Sauter uwe.sauter.de@gmail.com wrote:
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.
Just to confirm, you're not using the rootdn to test the ACL right? Because the rootdn is never subject to ACL restraints. I'd also advise upgrading to the current release, there are a number of ppolicy fixes made since 2.4.44.
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
Am 06.02.21 um 00:29 schrieb Quanah Gibson-Mount:
--On Saturday, February 6, 2021 12:06 AM +0100 Uwe Sauter uwe.sauter.de@gmail.com wrote:
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.
Just to confirm, you're not using the rootdn to test the ACL right? Because the rootdn is never subject to ACL restraints. I'd also advise upgrading to the current release, there are a number of ppolicy fixes made since 2.4.44.
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
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).
So, I've cloned two of the produciton machines, slapcat'ed the DB, updated to Symas' 2.4.57 and slapadd'ed the DB. Queries work, replication does work,…
The problem persists. If I try to restrict one of the pwd* attributes using
access to attrs=<pwdAttribute> by * none
then slaptest will fail with
601ef16b /etc/openldap/acl.conf: line 93: unknown attr "<pwdAttribute>" in to clause
601ef16b <access clause> ::= access to <what> [ by <who> [ <access> ] [ <control> ] ]+ […]
slaptest: bad configuration file!
#### password / ppolicy relevant parts in the configuration file ####
include /etc/openldap/schema/ppolicy.schema include /etc/openldap/acl.conf
modulepath /usr/lib64/openldap moduleload ppolicy.la moduleload smbk5pwd.la
password-hash {CRYPT}
password-crypt-salt-format "$6$%.16s"
overlay smbk5pwd
smbk5pwd-enable samba
overlay ppolicy ppolicy_default "cn=default,ou=Policies,dc=example,dc=com" ppolicy_use_lockout ######################################################################
### policy related entries ### 1199 ou=Policies,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: Policies
1200 cn=default,ou=Policies,dc=example,dc=com objectClass: top objectClass: device objectClass: pwdPolicy objectClass: pwdPolicyChecker cn: default pwdAttribute: userPassword pwdMinAge: 0 pwdMaxAge: 0 pwdInHistory: 3 pwdCheckQuality: 2 pwdMinLength: 8 pwdExpireWarning: 1814400 pwdGraceAuthNLimit: 3 pwdLockout: TRUE pwdLockoutDuration: 600 pwdMaxFailure: 5 pwdFailureCountInterval: 0 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: FALSE pwdCheckModule: /usr/lib64/openldap/check_password.so ################################################
Regards,
Uwe
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@gmail.com wrote:
So, I've cloned two of the produciton machines, slapcat'ed the DB, updated to Symas' 2.4.57 and slapadd'ed the DB. Queries work, replication does work,…
The problem persists. If I try to restrict one of the pwd* attributes using
access to attrs=<pwdAttribute> by * none
then slaptest will fail with
601ef16b /etc/openldap/acl.conf: line 93: unknown attr "<pwdAttribute>" in to clause 601ef16b <access clause> ::= access to <what> [ by <who> [ <access> ] [ <control> ] ]+ […]
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
Uwe Sauter uwe.sauter.de@gmail.com schrieb am 06.02.2021 um 00:06 in
Nachricht 9D89F4B3-DE37-40CB-A14A-6225933BD564@gmail.de:
Am 5. Februar 2021 22:15:47 MEZ schrieb Liam Gretton
On 2021-02-05 18:55, Uwe Sauter wrote:
# slaptest 601d92d6 /etc/openldap/acl.conf: line 84: unknown attr "pwdHistory"
in to clause
[…] slaptest: bad configuration file!
This is on CentOS with openldap-servers-2.4.44-22.el7.
I'm using 2.4.50 (my own build) on CentOS 7 and I have ACLs on this and
other ppolicy attributes without any problems.
You obviously have the ppolicy schema included, but is the ppolicy overlay actually loaded?
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.
What happens if you query "cn=schema,cn=config" for olcObjectClasses=*? (assuming you can query cn=config)
Here I see: ( 1.3.6.1.4.1.42.2.27.8.1.20 NAME 'pwdHistory' DESC 'The history of users passwords' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 NO-USER-MODIFICATION USAGE directoryOperation )
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.
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
openldap-technical@openldap.org
-
Liam Gretton -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl -
Uwe Sauter