> 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 < > [email protected]> 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, <[email protected]> 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. >>>> >>>> >>>> >>> >> >
