Le lun. 9 sept. 2019 à 18:25, Quanah Gibson-Mount <qua...@symas.com> a
écrit :
>
>
> --On Thursday, September 5, 2019 10:35 AM +0200 Manuela Mandache
> <manuela3manda...@gmail.com> wrote:
>
> >
> >
> >
> >
> >
> >
> > Le mer. 4 sept. 2019 à 16:00, Quanah Gibson-Mount <qua...@symas.com> a
> > écrit :
> >
> > --On Wednesday, September 4, 2019 1:56 PM +0200 Manuela Mandache
> > <manuela3manda...@gmail.com> wrote:
> >
> >> olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by
> >> dn.base="cn=adm
> >> in,dc=example,dc=com" manage by * break
> >> olcAccess: {1}to dn.base="" by * read
> >> olcAccess: {2}to dn.base=cn=Subschema by * read
> >> olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by *
> >> auth
> >> olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read
> >> olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read
> >> olcAccess: {6}to * by anonymous none by * read
> >
> > On what cn=config entry have you set these ACLs?
> >
> >
> >
> >
> > They're on
> > olcDatabase={2}mdb,cn=config
> > This is the DB containing the actual data of the directory, with
> > olcSuffix: dc=example,dc=com
>
> Given that, I would make the following notes:
>
> a) rootDNs are never subject to ACLs, so the access for cn=admin,cn=config
> manage in {0} is suspect, as I would infer that is a rootdn.
>
> b) ACL {1} is invalid for this database. It should be set in the dn:
> olcDatabase={-1}frontend,cn=config database
>
> c) ACL {2} is invalid for this database. See solution listed in (b)
>
> d) ACL {3} should only give auth access to anonymous, not *
>
> e) ACLs 3-5 should be rewritten to drop the dn.subtree="dc=example,dc=com"
> bit entirely. You're already only setting ACLs for that database, no need
> to list that restriction. You can also combine ACLs 4 & 5.
>
> olcAccess: {3} to attrs=userPassword by anonymous auth
> olcAccess: {4} to attrs=entry,cn,mail by * read
> olcAccess: {5} to * by anonymous none by * read
>
>
Hello Quanah,
Thank you for the detailed analysis of the ACLs - I wrote them based on
very old inherited ones, but this is no excuse.
Although I (believed I had) thoroughly RTFM, I feel like I only begin to
really understand the way they must be defined. Well, back to the drawing
board.
Do poorly written ACLs have a strong impact on performance?
> As for your question in general, I don't think you understand how ACLs
> work
> in relation to incoming search requests. The server did exactly what your
> ACLs said it should do: It provided no information when someone tried to
> search for data using an attribute that access is not granted to, and
> correctly returned 0 entries. It sounds as though you expected the
> connection to be dropped when the search was initiated because it was
> filtering off of sn.
No, I didn't think the connection would be dropped, but I thought no data
which are never to be returned would be searched.
E.g.:
- there are three branches in the directory, ou=people,dc=example,dc=com,
ou=dogs,dc=... and ou=carpets,...;
- a user has read rights on ou=dogs and none on the two other branches;
- this user makes a search with -b dc=example,dc=com and no filter.
As far as I understand, the whole content is recovered, then the people and
the carpets are dropped and only the dogs are returned.
I expected the request to be parsed against the ACLs before performing the
actual search in the directory, and so this search to be done only on
ou=dogs.
Maybe this example is completely different from the one in my first post:
It's true that I do not know how requests-and-ACLs actually work. Is there
some documentation I could read on the topic?
Best regards,
Manuela
> That is now how things work.
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
