From uwe.sauter.de@gmail.com Fri Feb  5 16:05:19 2021
From: Uwe Sauter <uwe.sauter.de@gmail.com>
To: openldap-technical@openldap.org
Subject: How to restrict access to operational attributes?
Date: Fri, 05 Feb 2021 08:40:56 +0100
Message-ID: <dade99db-47cd-08a4-e837-b57ec56162e6@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2297811632264406571=="

--===============2297811632264406571==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

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 c=
onfiguration an error
occurs:

#### ACL
access to attrs=3DpwdHistory
        by * none
########

#### slaptest output
601cf554 /etc/openldap/acl.conf: line 96: unknown attr "pwdHistory" in to cla=
use
601cf554 <access clause> ::=3D access to <what> [ by <who> [ <access> ] [ <co=
ntrol> ] ]+
<what> ::=3D * | dn[.<dnstyle>=3D<DN>] [filter=3D<filter>] [attrs=3D<attrspec=
>]
<attrspec> ::=3D <attrname> [val[/<matchingRule>][.<attrstyle>]=3D<value>] | =
<attrlist>
<attrlist> ::=3D <attr> [ , <attrlist> ]
<attr> ::=3D <attrname> | @<objectClass> | !<objectClass> | entry | children
<who> ::=3D [ * | anonymous | users | self | dn[.<dnstyle>]=3D<DN> ]
        [ realanonymous | realusers | realself | realdn[.<dnstyle>]=3D<DN> ]
        [dnattr=3D<attrname>]
        [realdnattr=3D<attrname>]
        [group[/<objectclass>[/<attrname>]][.<style>]=3D<group>]
        [peername[.<peernamestyle>]=3D<peer>] [sockname[.<style>]=3D<name>]
        [domain[.<domainstyle>]=3D<domain>] [sockurl[.<style>]=3D<url>]
        [dynacl/<name>[/<options>][.<dynstyle>][=3D<pattern>]]
        [ssf=3D<n>] [transport_ssf=3D<n>] [tls_ssf=3D<n>] [sasl_ssf=3D<n>]
<style> ::=3D exact | regex | base(Object)
<dnstyle> ::=3D base(Object) | one(level) | sub(tree) | children | exact | re=
gex
<attrstyle> ::=3D exact | regex | base(Object) | one(level) | sub(tree) | chi=
ldren
<peernamestyle> ::=3D exact | regex | ip | ipv6 | path
<domainstyle> ::=3D exact | regex | base(Object) | sub(tree)
<access> ::=3D [[real]self]{<level>|<priv>}
<level> ::=3D none|disclose|auth|compare|search|read|{write|add|delete}|manage
<priv> ::=3D {=3D|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
<control> ::=3D [ stop | continue | break ]
dynacl:
        <name>=3DACI      <pattern>=3D<attrname>

slaptest: bad configuration file!
####################

My questions:

* How can I restrict access to operational attributes? Does this depend on th=
e specific overlay?

* Is this a bug in the ppolicy overlay? One might consider the pwd* attribute=
s confidential but at
the same time allowing anonymous queries might be necessary.

* Is there anything I miss (besides still using configuration files =E2=80=93=
 they are way easier to handle)?

Best,

	Uwe




--===============2297811632264406571==--


From michael@stroeder.com Fri Feb  5 16:31:38 2021
From: Michael =?utf-8?q?Str=C3=B6der?= <michael@stroeder.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Fri, 05 Feb 2021 17:31:19 +0100
Message-ID: <d28a26c7-91c7-c101-e3db-8751c6afe26b@stroeder.com>
In-Reply-To: <dade99db-47cd-08a4-e837-b57ec56162e6@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6975602882298759163=="

--===============6975602882298759163==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 2/5/21 8:40 AM, Uwe Sauter wrote:
> I'm trying to restrict access to the operational attributes that are provid=
ed by the ppolicy overlay
> (e.g. pwdChangedTime, pwdHistory).
>=20
> When I add the following to my ACL configuration file and try to verify the=
 configuration an error
> occurs:
>=20
> #### ACL
> access to attrs=3DpwdHistory
>         by * none
> ########
>=20
> #### slaptest output
> 601cf554 /etc/openldap/acl.conf: line 96: unknown attr "pwdHistory" in to c=
lause

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.

--===============6975602882298759163==--


From uwe.sauter.de@gmail.com Fri Feb  5 18:58:00 2021
From: Uwe Sauter <uwe.sauter.de@gmail.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Fri, 05 Feb 2021 19:55:26 +0100
Message-ID: <8b31990e-0f7d-4869-d45c-2fb34a494847@gmail.com>
In-Reply-To: <d28a26c7-91c7-c101-e3db-8751c6afe26b@stroeder.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0052504403773438363=="

--===============0052504403773438363==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Michael.

Am 05.02.21 um 17:31 schrieb Michael Str=C3=B6der:
> On 2/5/21 8:40 AM, Uwe Sauter wrote:
>> I'm trying to restrict access to the operational attributes that are provi=
ded by the ppolicy overlay
>> (e.g. pwdChangedTime, pwdHistory).
>>
>> When I add the following to my ACL configuration file and try to verify th=
e configuration an error
>> occurs:
>>
>> #### ACL
>> access to attrs=3DpwdHistory
>>          by * none
>> ########
>>
>> #### slaptest output
>> 601cf554 /etc/openldap/acl.conf: line 96: unknown attr "pwdHistory" in to =
clause
>=20
> The above error means you did not load ppolicy schema.
>=20
> Add to slapd.conf:
>=20
> include /etc/openldap/schema/ppolicy.schema
>=20
> 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=3D""
         by * read

access to attrs=3DuserPassword,sambaLMPassword,shadowLastChange
         by dn=3D"cn=3DManager,dc=3Dexample,dc=3Dcom" write
         by dn=3D"cn=3Dradius-lookup,dc=3Dexample,dc=3Dcom" read
         by self write
         by * auth

[more acl entries]

## ppolicy # man 5 slapo-ppolicy
access to dn.subtree=3D"ou=3DPolicies,dc=3Dhlrs,dc=3Dde"
         by dn=3D"cn=3DManager,dc=3Dhlrs,dc=3Dde" write
         by * none

access to attrs=3DpwdHistory
        by * none

[even more entries]
##################################


# slaptest
601d92d6 /etc/openldap/acl.conf: line 84: unknown attr "pwdHistory" in to cla=
use
[=E2=80=A6]
slaptest: bad configuration file!


This is on CentOS with openldap-servers-2.4.44-22.el7.


Thanks,

	Uwe


> Ciao, Michael.
>=20

--===============0052504403773438363==--


From michael@stroeder.com Fri Feb  5 19:03:24 2021
From: Michael =?utf-8?q?Str=C3=B6der?= <michael@stroeder.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Fri, 05 Feb 2021 20:03:13 +0100
Message-ID: <2906141a-9527-959d-4766-94796a2eef8e@stroeder.com>
In-Reply-To: <8b31990e-0f7d-4869-d45c-2fb34a494847@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3924675140483457223=="

--===============3924675140483457223==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

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.

--===============3924675140483457223==--


From uwe.sauter.de@gmail.com Fri Feb  5 19:19:55 2021
From: Uwe Sauter <uwe.sauter.de@gmail.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Fri, 05 Feb 2021 20:15:31 +0100
Message-ID: <35488c88-5367-3bb7-756e-6e896ecc1b60@gmail.com>
In-Reply-To: <2906141a-9527-959d-4766-94796a2eef8e@stroeder.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7225083623054101937=="

--===============7225083623054101937==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable



Am 05.02.21 um 20:03 schrieb Michael Str=C3=B6der:
> On 2/5/21 7:55 PM, Uwe Sauter wrote:
>> Am 05.02.21 um 17:31 schrieb Michael Str=C3=B6der:
>>> 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=3DpwdHistory
>>>>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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.
>=20
> 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 no=
w realised that these pwd* attributes were=20
open to everyone and wanted to restrict access to the manager account.

Regards,

	Uwe


> Ciao, Michael.
>=20

--===============7225083623054101937==--


From michael@stroeder.com Fri Feb  5 19:22:21 2021
From: Michael =?utf-8?q?Str=C3=B6der?= <michael@stroeder.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Fri, 05 Feb 2021 20:22:14 +0100
Message-ID: <c9f2c367-5b99-a89a-2e31-95fb9a4fe16f@stroeder.com>
In-Reply-To: <35488c88-5367-3bb7-756e-6e896ecc1b60@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5804015761870152989=="

--===============5804015761870152989==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

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.

--===============5804015761870152989==--


From liam.gretton@gmail.com Fri Feb  5 21:35:34 2021
From: Liam Gretton <liam.gretton@gmail.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Fri, 05 Feb 2021 21:15:47 +0000
Message-ID: <497fe6f2-24f1-4910-6ed4-ea4ed98b1f15@gmail.com>
In-Reply-To: <8b31990e-0f7d-4869-d45c-2fb34a494847@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1428239470901882542=="

--===============1428239470901882542==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On 2021-02-05 18:55, Uwe Sauter wrote:
> # slaptest
> 601d92d6 /etc/openldap/acl.conf: line 84: unknown attr "pwdHistory" in to c=
lause
> [=E2=80=A6]
> 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=20
other ppolicy attributes without any problems.

You obviously have the ppolicy schema included, but is the ppolicy=20
overlay actually loaded?





--===============1428239470901882542==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.htm"
MIME-Version: 1.0

PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRl
bnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPGRp
diBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAyMDIxLTAyLTA1IDE4OjU1LCBVd2UgU2F1dGVy
IHdyb3RlOjxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIKICAgICAg
Y2l0ZT0ibWlkOjhiMzE5OTBlLTBmN2QtNDg2OS1kNDVjLTJmYjM0YTQ5NDg0N0BnbWFpbC5jb20i
PgogICAgICA8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPiMgc2xhcHRlc3QKNjAx
ZDkyZDYgL2V0Yy9vcGVubGRhcC9hY2wuY29uZjogbGluZSA4NDogdW5rbm93biBhdHRyICJwd2RI
aXN0b3J5IiBpbiB0byBjbGF1c2UKW+KApl0Kc2xhcHRlc3Q6IGJhZCBjb25maWd1cmF0aW9uIGZp
bGUhCgoKVGhpcyBpcyBvbiBDZW50T1Mgd2l0aCBvcGVubGRhcC1zZXJ2ZXJzLTIuNC40NC0yMi5l
bDcuCjwvcHJlPgogICAgPC9ibG9ja3F1b3RlPgogICAgPGJyPgogICAgSSdtIHVzaW5nIDIuNC41
MCAobXkgb3duIGJ1aWxkKSBvbiBDZW50T1MgNyBhbmQgSSBoYXZlIEFDTHMgb24gdGhpcwogICAg
YW5kIG90aGVyIHBwb2xpY3kgYXR0cmlidXRlcyB3aXRob3V0IGFueSBwcm9ibGVtcy48YnI+CiAg
ICA8YnI+CiAgICBZb3Ugb2J2aW91c2x5IGhhdmUgdGhlIHBwb2xpY3kgc2NoZW1hIGluY2x1ZGVk
LCBidXQgaXMgdGhlIHBwb2xpY3kKICAgIG92ZXJsYXkgYWN0dWFsbHkgbG9hZGVkPzxicj4KICAg
IDxicj4KICAgIDxicj4KICA8L2JvZHk+CjwvaHRtbD4K

--===============1428239470901882542==--


From uwe.sauter.de@gmail.com Fri Feb  5 23:10:20 2021
From: Uwe Sauter <uwe.sauter.de@gmail.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Sat, 06 Feb 2021 00:06:27 +0100
Message-ID: <9D89F4B3-DE37-40CB-A14A-6225933BD564@gmail.de>
In-Reply-To: <497fe6f2-24f1-4910-6ed4-ea4ed98b1f15@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1977080622623730103=="

--===============1977080622623730103==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable



Am 5. Februar 2021 22:15:47 MEZ schrieb Liam Gretton <liam.gretton(a)gmail.co=
m>:
>On 2021-02-05 18:55, Uwe Sauter wrote:
>> # slaptest
>> 601d92d6 /etc/openldap/acl.conf: line 84: unknown attr "pwdHistory"
>in to clause
>> [=E2=80=A6]
>> 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=20
>overlay actually loaded?

Yes it is. Account locking after failed attempts, password changes honoring c=
onfigured rules, password history etc. all works since this was set up in 201=
7. Back then I just forgot to hide the pwd* attributes that are managed by th=
e ppolicy overlay.

Perhaps I need to set up a minimal environment to figure this out...

--=20
Diese Nachricht wurde von meinem Android-Ger=C3=A4t mit K-9 Mail gesendet.

--===============1977080622623730103==--


From quanah@symas.com Fri Feb  5 23:30:01 2021
From: Quanah Gibson-Mount <quanah@symas.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Fri, 05 Feb 2021 15:29:54 -0800
Message-ID: <80715DBC7E81B894B15233B0@[192.168.1.156]>
In-Reply-To: <9D89F4B3-DE37-40CB-A14A-6225933BD564@gmail.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1566979168813313976=="

--===============1566979168813313976==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit



--On Saturday, February 6, 2021 12:06 AM +0100 Uwe Sauter 
<uwe.sauter.de(a)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>

--===============1566979168813313976==--


From uwe.sauter.de@gmail.com Sat Feb  6 19:41:29 2021
From: Uwe Sauter <uwe.sauter.de@gmail.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Sat, 06 Feb 2021 10:57:22 +0100
Message-ID: <fc240589-db9f-d8fe-6b8e-9b6176d56cd1@gmail.com>
In-Reply-To: <80715DBC7E81B894B15233B0@[192.168.1.156]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0621368966962412131=="

--===============0621368966962412131==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable



Am 06.02.21 um 00:29 schrieb Quanah Gibson-Mount:
>=20
>=20
> --On Saturday, February 6, 2021 12:06 AM +0100 Uwe Sauter <uwe.sauter.de(a)=
gmail.com> wrote:
>=20
>> 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.
>=20
> Just to confirm, you're not using the rootdn to test the ACL right? Because=
 the rootdn is never subject to ACL=20
> restraints.=C2=A0 I'd also advise upgrading to the current release, there a=
re 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 re=
start the running service it will fail=20
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 th=
e pwd* attributes (ldapsearch -x=20
'(uid=3Dmyuser)' +). I want to restrict access to these attributes so that on=
ly the manager account can access them=20
(lapdsearch -xWD cn=3Dmanager,dc=3Dexample,dc=3Dcom '(uid=3Dmyuser)' +).

Regards,

	Uwe


> 2.4.47:
>  =C2=A0=C2=A0 Fixed slapo-ppolicy with multi-provider replication (ITS#8927)
>=20
> 2.4.48:
>  =C2=A0=C2=A0 Fixed slapo-ppolicy behavior when pwdInHistory is changed (IT=
S#8349)
>=20
> 2.4.49:
>  =C2=A0=C2=A0 Fixed slapo-ppolicy when used with slapauth (ITS#8629)
>  =C2=A0=C2=A0 Fixed slapo-ppolicy to add a missed normalised copy of pwdCha=
ngedTime (ITS#9126)
>=20
> 2.4.50:
>  =C2=A0=C2=A0 Fixed slapo-ppolicy callback (ITS#9171)
>=20
> 2.4.51:
>  =C2=A0=C2=A0 Added slapo-ppolicy implement Netscape password policy contro=
ls (ITS#9279)
>  =C2=A0=C2=A0 Fixed slapo-ppolicy to expose the ppolicy control (ITS#9285)
>  =C2=A0=C2=A0 Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#93=
02)
>  =C2=A0=C2=A0 Fixed slapo-ppolicy so it can only exist once per DB (ITS#930=
9)
>=20
> 2.4.53:
>  =C2=A0=C2=A0 Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#93=
02,ITS#9334)
>=20
> I'd note again, Symas provides free drop-in replacement builds for CentOS/R=
HEL 7 that are current:
>=20
> <https://repo.symas.com/sofl/rhel7/>
>=20
> 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=20
> slapcat/slapadd to fix the internal normalization of pwdChangedTime).
>=20
> Regards,
> Quanah
>=20
> --=20
>=20
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>

--===============0621368966962412131==--


From uwe.sauter.de@gmail.com Sat Feb  6 20:20:25 2021
From: Uwe Sauter <uwe.sauter.de@gmail.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Sat, 06 Feb 2021 20:55:35 +0100
Message-ID: <af26ee8f-382a-e057-02f4-a62ce3f37565@gmail.com>
In-Reply-To: <fc240589-db9f-d8fe-6b8e-9b6176d56cd1@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5053255846010316584=="

--===============5053255846010316584==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

>> 2.4.47:
>> =C2=A0=C2=A0=C2=A0 Fixed slapo-ppolicy with multi-provider replication (IT=
S#8927)
>>
>> 2.4.48:
>> =C2=A0=C2=A0=C2=A0 Fixed slapo-ppolicy behavior when pwdInHistory is chang=
ed (ITS#8349)
>>
>> 2.4.49:
>> =C2=A0=C2=A0=C2=A0 Fixed slapo-ppolicy when used with slapauth (ITS#8629)
>> =C2=A0=C2=A0=C2=A0 Fixed slapo-ppolicy to add a missed normalised copy of =
pwdChangedTime (ITS#9126)
>>
>> 2.4.50:
>> =C2=A0=C2=A0=C2=A0 Fixed slapo-ppolicy callback (ITS#9171)
>>
>> 2.4.51:
>> =C2=A0=C2=A0=C2=A0 Added slapo-ppolicy implement Netscape password policy =
controls (ITS#9279)
>> =C2=A0=C2=A0=C2=A0 Fixed slapo-ppolicy to expose the ppolicy control (ITS#=
9285)
>> =C2=A0=C2=A0=C2=A0 Fixed slapo-ppolicy race condition for pwdFailureTime (=
ITS#9302)
>> =C2=A0=C2=A0=C2=A0 Fixed slapo-ppolicy so it can only exist once per DB (I=
TS#9309)
>>
>> 2.4.53:
>> =C2=A0=C2=A0=C2=A0 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=20
>> 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.=20
Queries work, replication does work,=E2=80=A6

The problem persists. If I try to restrict one of the pwd* attributes using

access to attrs=3D<pwdAttribute>
         by * none

then slaptest will fail with

601ef16b /etc/openldap/acl.conf: line 93: unknown attr "<pwdAttribute>" in to=
 clause=20

601ef16b <access clause> ::=3D access to <what> [ by <who> [ <access> ] [ <co=
ntrol> ] ]+
[=E2=80=A6]

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}=20

password-crypt-salt-format "$6$%.16s"

overlay smbk5pwd=20

smbk5pwd-enable samba

overlay                ppolicy
ppolicy_default        "cn=3Ddefault,ou=3DPolicies,dc=3Dexample,dc=3Dcom"
ppolicy_use_lockout
######################################################################

### policy related entries ###
1199 ou=3DPolicies,dc=3Dexample,dc=3Dcom
objectClass: top
objectClass: organizationalUnit
ou: Policies

1200 cn=3Ddefault,ou=3DPolicies,dc=3Dexample,dc=3Dcom
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
>>
>> --=20
>>
>> Quanah Gibson-Mount
>> Product Architect
>> Symas Corporation
>> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
>> <http://www.symas.com>

--===============5053255846010316584==--


From quanah@symas.com Sat Feb  6 20:21:46 2021
From: Quanah Gibson-Mount <quanah@symas.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Sat, 06 Feb 2021 12:21:39 -0800
Message-ID: <4C76D494928A2DFE1A7BDBF3@[192.168.1.156]>
In-Reply-To: <af26ee8f-382a-e057-02f4-a62ce3f37565@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7945608561947451815=="

--===============7945608561947451815==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit



--On Saturday, February 6, 2021 8:55 PM +0100 Uwe Sauter 
<uwe.sauter.de(a)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>

--===============7945608561947451815==--


From Ulrich.Windl@rz.uni-regensburg.de Mon Feb  8 16:04:08 2021
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: openldap-technical@openldap.org
Subject: Antw: [EXT] Re: How to restrict access to operational attributes?
Date: Mon, 08 Feb 2021 09:54:56 +0100
Message-ID: <6020FC60020000A10003EC88@gwsmtp.uni-regensburg.de>
In-Reply-To: <9D89F4B3-DE37-40CB-A14A-6225933BD564@gmail.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0283030406971564078=="

--===============0283030406971564078==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

>>> Uwe Sauter <uwe.sauter.de(a)gmail.com> schrieb am 06.02.2021 um 00:06 in
Nachricht <9D89F4B3-DE37-40CB-A14A-6225933BD564(a)gmail.de>:

> 
> Am 5. Februar 2021 22:15:47 MEZ schrieb Liam Gretton
<liam.gretton(a)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.

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.



--===============0283030406971564078==--


From uwe.sauter.de@gmail.com Mon Feb  8 20:41:32 2021
From: Uwe Sauter <uwe.sauter.de@gmail.com>
To: openldap-technical@openldap.org
Subject: Re: How to restrict access to operational attributes?
Date: Mon, 08 Feb 2021 21:41:17 +0100
Message-ID: <740529fc-1c47-e304-6acc-a9a80adf92da@gmail.com>
In-Reply-To: <dade99db-47cd-08a4-e837-b57ec56162e6@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4054438328897376467=="

--===============4054438328897376467==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

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=20
loading the ppolicy plugin.

With the correct order the pwd* attributes provided by the ppolicy module (no=
t the schema file!) are available when the=20
ACLs are parsed and thus the test succeeds.


Regards,

	Uwe

Am 05.02.21 um 08:40 schrieb Uwe Sauter:
> Good morning,
>=20
> I'm trying to restrict access to the operational attributes that are provid=
ed by the ppolicy overlay
> (e.g. pwdChangedTime, pwdHistory).
>=20
> When I add the following to my ACL configuration file and try to verify the=
 configuration an error
> occurs:
>=20
> #### ACL
> access to attrs=3DpwdHistory
>          by * none
> ########
>=20
> #### slaptest output
> 601cf554 /etc/openldap/acl.conf: line 96: unknown attr "pwdHistory" in to c=
lause
> 601cf554 <access clause> ::=3D access to <what> [ by <who> [ <access> ] [ <=
control> ] ]+
> <what> ::=3D * | dn[.<dnstyle>=3D<DN>] [filter=3D<filter>] [attrs=3D<attrsp=
ec>]
> <attrspec> ::=3D <attrname> [val[/<matchingRule>][.<attrstyle>]=3D<value>] =
| <attrlist>
> <attrlist> ::=3D <attr> [ , <attrlist> ]
> <attr> ::=3D <attrname> | @<objectClass> | !<objectClass> | entry | children
> <who> ::=3D [ * | anonymous | users | self | dn[.<dnstyle>]=3D<DN> ]
>          [ realanonymous | realusers | realself | realdn[.<dnstyle>]=3D<DN>=
 ]
>          [dnattr=3D<attrname>]
>          [realdnattr=3D<attrname>]
>          [group[/<objectclass>[/<attrname>]][.<style>]=3D<group>]
>          [peername[.<peernamestyle>]=3D<peer>] [sockname[.<style>]=3D<name>]
>          [domain[.<domainstyle>]=3D<domain>] [sockurl[.<style>]=3D<url>]
>          [dynacl/<name>[/<options>][.<dynstyle>][=3D<pattern>]]
>          [ssf=3D<n>] [transport_ssf=3D<n>] [tls_ssf=3D<n>] [sasl_ssf=3D<n>]
> <style> ::=3D exact | regex | base(Object)
> <dnstyle> ::=3D base(Object) | one(level) | sub(tree) | children | exact | =
regex
> <attrstyle> ::=3D exact | regex | base(Object) | one(level) | sub(tree) | c=
hildren
> <peernamestyle> ::=3D exact | regex | ip | ipv6 | path
> <domainstyle> ::=3D exact | regex | base(Object) | sub(tree)
> <access> ::=3D [[real]self]{<level>|<priv>}
> <level> ::=3D none|disclose|auth|compare|search|read|{write|add|delete}|man=
age
> <priv> ::=3D {=3D|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
> <control> ::=3D [ stop | continue | break ]
> dynacl:
>          <name>=3DACI      <pattern>=3D<attrname>
>=20
> slaptest: bad configuration file!
> ####################
>=20
> My questions:
>=20
> * How can I restrict access to operational attributes? Does this depend on =
the specific overlay?
>=20
> * Is this a bug in the ppolicy overlay? One might consider the pwd* attribu=
tes confidential but at
> the same time allowing anonymous queries might be necessary.
>=20
> * Is there anything I miss (besides still using configuration files =E2=80=
=93 they are way easier to handle)?
>=20
> Best,
>=20
> 	Uwe
>=20
>=20
>=20
>=20

--===============4054438328897376467==--