On Tue, 2017-11-14 at 12:44 +0100, Michael Ströder wrote:

Geert Hendrickx wrote:

...

Is there a way to restrict (acl?) searches using wildcards?

AFAIK no.

...

For compliancly reasons, I want to allow certain (actually most) users to search on eg. known email addresses, like: mail=user@example.org, but not to retrieve a list of all users, like mail=*@example.org.

There is really no way to block this. If you disable this search you can do:

uid=* sn=* mail=* (pres) objectClass=*

Even with admin limits, paged search limits etc, you can not block this. You can *always* get *every* entry from a server given enough time.

I really think that the question you should ask yourself is "what's the threat you want to counter? How can I prevent that?"

A list of users is one thing, but perhaps the threat is "list of users full names". So then limit access to cn/sn/displayName etc. If it's mail addrs then limit who can read mail. It could be a eduProvider so block access to edu* attrs instead. There are better ways to achieve what you want here I think,

I think that you should ask those questions and think about better ways to express the threat you want to prevent, and build accordingly.

...

Sizelimit restriction is not enough, because they could still iteratively retrieve everything, without launching an actual dictionary attack on all possible mail addresses, which would be much harder.

You could remove SUBSTR matching rule from attribute type description of 'mail' (in core.schema or core.ldif).

Caveats:

1. Probably you already know that tweaking standard schema is not

recommend.

2. It disables sub-string matching on 'mail' completely. You might

solve this by building a partial replica or a LDAP proxy dedicated to the exact search on known e-mail addresses.

AFAICS other possibilities would be implementing an overlay or a dynacl module for your specific needs.

Ciao, Michael.