[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: allow to pass on "undefined" filters in meta



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