Bug 48196 - Enable more LDAP filters for listener modules
Enable more LDAP filters for listener modules
Status: NEW
Product: UCS
Classification: Unclassified
Component: Listener (univention-directory-listener)
UCS 5.0
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
Depends on:
  Show dependency treegraph
Reported: 2018-11-23 10:39 CET by Valentin Heidelberger
Modified: 2021-05-03 21:54 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.023
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Valentin Heidelberger univentionstaff 2018-11-23 10:39:13 CET
Currently only LDAP filters using equal matches are allowed for listener modules.

See https://docs.software-univention.de/developer-reference.html#listener:handler

filter (required)

    Defines a LDAP filter which is used to match the objects the listener is interested in. This filter is similar to the LDAP search filter as defined in RFC 2254, but more restricted:

        it is case sensitive
        it only supports equal matches

It would be nice to be able to use more filters as described in the RFC:

I recently wanted to use an extensible filter for example.
Comment 1 Arvid Requate univentionstaff 2018-11-26 14:53:34 CET
This is probably not really possible due to the architecture of Listener/Notifier replication. Here the catch:

The "LDAP-like" filters in listener modules are not really evaluated by an actual LDAP server (or library). The filtering is only "simulated". To implement an actual LDAP filtering of the objects, the code would have to know the LDAP schema and be capable to actually use the correct per attribute matching rules. In an ideal world we would change the Listener to use an (additional) LDAP server as caching backend (preferably embedded as a library, but nobody implemented such a thing until now). If we would have that, the Listener could offload the LDAP filtering process to his LDAP server backend. I would love to see this implemented, but I'm afraid the benefit/cost ratio is not good enough, as yet.