Re: Transparent proxy, (objectClass=user) not being relayed. Schema issue?

[masarati@aero.polimi.it]

> 2.3.43 included with CentOS. I'll try the latest package. Thanks!

Ah.  Actually, I only tried an undefined objectClass, which works.  In
fact, in the case you're considering, (objectClass=user) contains an
invalid value of a valid attribute, while (sAMAccountName=user01) contains
an invalid attribute, so the two cases are different.  Right now, with
HEAD's back-meta for "(&(objectClass=user)(sAMAccountName=user01))" I get
"(&(?objectClass=user)(!(objectClass=*)))".  Let me check a bit more.

p.

> On Mon, Jan 31, 2011 at 11:16 AM, Pierangelo Masarati <
> masarati@aero.polimi.it> wrote:
>
>> Christopher Cprek wrote:
>>
>>> Thank you!
>>>
>>> Unfortunately, I'm seeing the same issue with back-meta.
>>>
>>
>> What version?  I checkd with HEAD, so my test might not be
>> representative.
>>  In any case, this issue should now be fixed in back-ldap.
>>
>> p.
>>
>>
>>  The simple configuration:
>>>
>>> database meta
>>> suffix  "dc=ad,dc=mydomain,dc=edu"
>>> uri  "ldap://ldapadlb.mydomain.edu/dc=ad,dc=mydomain,dc=edu";
>>>
>>> When using this configuration I still have to use my hacked AD schema
>>> for
>>> correct relaying. Example case of a filter without including the custom
>>> schema "(&(objectClass=user)(sAMAccountName=user01))"... Still results
>>> in
>>> this:
>>>
>>> conn=0 op=1: meta_back_getconn[0]
>>> conn=0 op=1 meta_back_getconn: candidates=1 conn=0 fetched
>>> conn=0 op=1 >>> meta_back_search_start[0]
>>> conn=0 op=1 >>> meta_search_dobind_init[0]
>>> conn=0 op=1 <<< meta_search_dobind_init[0]=1
>>> ldap_search_ext
>>> put_filter: "(&(!(objectClass=*))(!(objectClass=*)))"
>>> put_filter: AND
>>> put_filter_list "(!(objectClass=*))(!(objectClass=*))"
>>> put_filter: "(!(objectClass=*))"
>>> put_filter: NOT
>>> put_filter_list "(objectClass=*)"
>>> put_filter: "(objectClass=*)"
>>> put_filter: simple
>>> put_simple_filter: "objectClass=*"
>>> put_filter: "(!(objectClass=*))"
>>> put_filter: NOT
>>> put_filter_list "(objectClass=*)"
>>> put_filter: "(objectClass=*)"
>>> put_filter: simple
>>> put_simple_filter: "objectClass=*"
>>> ldap_send_initial_request
>>> ldap_send_server_request
>>> ber_scanf fmt ({it) ber:
>>> ber_scanf fmt ({) ber:
>>> ber_flush: 111 bytes to sd 10
>>> conn=0 op=1 <<< meta_back_search_start[0]=1
>>> conn=0 op=1 meta_back_search: ncandidates=1 cnd="*"
>>> ldap_result ld 0x2b5e683de880 msgid 2
>>> wait4msg ld 0x2b5e683de880 msgid 2 (timeout 0 usec)
>>> wait4msg continue ld 0x2b5e683de880 msgid 2 all 2
>>>
>>> Including the hacked schema corrects the problem, but it is only a
>>> subset
>>> of
>>> possible search filters that could fail.
>>>
>>> Am I missing something in the back-meta configuration?
>>>
>>> Thanks again!
>>>
>>> /Chris
>>>
>>> On Sat, Jan 29, 2011 at 4:34 AM, <masarati@aero.polimi.it> wrote:
>>>
>>>  I would appreciate any guidance to help resolve my problem. All I want
>>> is
>>>>> the filter (objectClass=user) to be relayed correctly from the slapd
>>>>> service
>>>>> to the LDAP proxy backend.
>>>>>
>>>> back-ldap/search.c 1.273 -> 1.274, related to ITS#6814, should fix
>>>> your
>>>> problem.  Back-meta does not suffer from this problem, as it correctly
>>>> relays undefined objectClasses in search filters.
>>>>
>>>> p.
>>>>
>>>>
>>>>
>>>
>>
>