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="===============6722752992886055455=="

--===============6722752992886055455==
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

--===============6722752992886055455==--