-----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?

> 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 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

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