Hi all,
I had exactly the same problem last June. Pierangelo Masarati helped me understanding the problem. He even provided the code for a contrib module to solve this issue. You can search the list for the subject "back_meta does not like my LDAP_MATCHING_RULE_IN_CHAIN filter".
I have "packed" all of it into a github repo at https://github.com/cbueche/openldap-passthru and announced it to the list on 6.6.2014. It would be nice if the maintainer take it over to the official openldap tarball within contrib/slapd-modules/mr_passthru/ so future needs are "officially" covered. I think the LDAP_MATCHING_RULE_IN_CHAIN filters will find their use for many other people.
Markus: I can help you for the implementation if needed. Feel free to provide for more functionality.
Regs, Charles
On 23.10.14 08:17, Markus.Storm@t-systems.com wrote:
Hi Howard,
have you had a chance to look into this? We're a bit desperate over here, short of alternative solutions.
Regards Markus
-----Original Message----- From: Storm, Markus Sent: Thursday, September 18, 2014 8:44 AM To: 'Howard Chu'; openldap-technical@openldap.org Subject: AW: allow to pass on "undefined" filters in meta
-----Ursprüngliche Nachricht----- Von: Howard Chu [mailto:hyc@symas.com] Gesendet: Mittwoch, 17. September 2014 18:17 An: Storm, Markus; openldap-technical@openldap.org Betreff: Re: allow to pass on "undefined" filters in meta
Markus.Storm@t-systems.com wrote:
Hi I've run into a problem trying to deploy back-meta in front of an Active Directory target.
What is the exact filter you are trying to use?
a filter such as
(&(objectclass=user) (|(memberOf:1.2.840.113556.1.4.1941:=CN=GRP_AAA_ADM,OU=Groups,OU=AAA,OU=Se rvers,DC=lab,DC=net) (memberOf:1.2.840.113556.1.4.1941:=CN=GRP_BBB_ADM,OU=Groups,OU=AAA,OU=Serv ers,DC=lab,DC=net)))
The problem is with the matching rule to be used :1.2.840.113556.1.4.1941: That translates into LDAP_MATCHING_RULE_IN_CHAIN which makes the server recursively check for nested group membership. That's a feature in AD but not supported in OpenLDAP (or at least not by simply specifying that matching rule, and to rework the query is no option).
I believe that to resolve it, I need to get a new option implemented. I need to issue a request through a back-meta proxy . That query happens to contain a matching rule which is not implemented in OpenLDAP so slapd does not know to evaluate the query. The target
that
the query will ultimately be passed on to (an Active Directory) does
know to process the query, though.
OpenLDAP, however, considers the filter to be "undefined" and thus on relaying the request to the AD target, back-meta replaces a portion
of
the original query with a "(?=undefined)" filter as documented in
e.g.
slapd-meta manpage "noundeffilter" option. But I need the original query to be passed on. It's in fact a _valid_ LDAP request, just OpenLDAP happens to be unable to parse it. But at least in my setup, slapd does not have to do _/anything/_ about the query other than to pass it on, so I find it inacceptable that it replaces the query just because it doesn't understand it. Please, can you add an option switch to the code to allow for passing on original queries *without* replacing undefined portions ? I have not found any other solution to my problem. I tried to make OpenLDAP aware of the undefined portion by adding the matching rule
to
the schema but I failed. Seems that would need to be planted into the code, and not being a programmer, that's not as easy as it is with expanding the schema by some new attributes. Also, while of course any parser/feature enhancement will always be appreciated, I would think that to implement the matching rule is
not
the best way of fixing things: I believe there will always be situations where OpenLDAP cannot parse the input while another LDAP
server can.
For a proof of concept, I hacked servers/slapd/back-meta/map.c
(around
line 581as of 2.4.39) and but - again, I'm not a programmer - I
feel
incapable of turning this into a full-blown patch free of side effects, also I want the modification to become available to anyone. So I'm hoping for you to implement the switch mentioned above, maybe as a third possible setting for the "noundeffilter" option. Thanks a lot in advance, best regards Markus Storm