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(a)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(a)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(a)openldap.org
>> Betreff: Re: allow to pass on "undefined" filters in meta
>>
>> Markus.Storm(a)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