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