Hello,
I'm attempting to configure a slapd server in a very simple transparent proxy configuration. I'm having a problem where clients for this proxy have a (objectClass=user) filter defined. This filter is being replaced with (!(objectClass=*)) when the searchRequest is relayed to the backend LDAP server.
I believe this is something missing in the schema, though I'm very new to LDAP. I've already included an AD schema in my slapd.conf to resolve some AD specific filters I had trouble with.
I've attempted to uncomment and modify the core.schema's definition of attributetype NAME objectClass, and commented out what I suspected was the conflicting duplicate attributeType NAME supportedApplicationContext.
But I can't get slapd to start. I keep getting a duplicate attribute type error in the config.
hdb_back_initialize: Sleepycat Software: Berkeley DB 4.4.20: (January 10, 2006) /etc/openldap/schema/core.schema: line 66: Duplicate attributeType: "2.5.4.0" slapd-ldap destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.
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.
Thanks in advance!
/Chris
Christopher Cprek wrote:
Hello,
I'm attempting to configure a slapd server in a very simple transparent proxy configuration. I'm having a problem where clients for this proxy have a (objectClass=user) filter defined. This filter is being replaced with (!(objectClass=*)) when the searchRequest is relayed to the backend LDAP server.
I believe this is something missing in the schema, though I'm very new to LDAP. I've already included an AD schema in my slapd.conf to resolve some AD specific filters I had trouble with.
I've attempted to uncomment and modify the core.schema's definition of attributetype NAME objectClass, and commented out what I suspected was the conflicting duplicate attributeType NAME supportedApplicationContext.
But I can't get slapd to start. I keep getting a duplicate attribute type error in the config.
hdb_back_initialize: Sleepycat Software: Berkeley DB 4.4.20: (January 10, 2006) /etc/openldap/schema/core.schema: line 66: Duplicate attributeType: "2.5.4.0" slapd-ldap destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.
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.
Do *not* modify standard track schema files; define the "user" objectclass (in principle, you should be able to find about its definition by inspecting the subschema subentry of the server you're proxying).
p.
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.
Thank you!
Unfortunately, I'm seeing the same issue with back-meta.
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.
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.
2.3.43 included with CentOS. I'll try the latest package. Thanks!
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.
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.
openldap-technical@openldap.org
-
Christopher Cprek -
masarati＠aero.polimi.it -
Pierangelo Masarati