The answer would be obvious if we had a misconfigured URI, but I don't think we do. In fact, we are getting this error from the ldap/translucent proxy on a first attempt to retrieve a DN from a remote Active Directory, then a second identical ldapsearch always succeeds. That makes us think there might be a timing issue getting from our openldap server, through a forwarding proxy out of a DMZ, and finally to the target AD server. But since all the openldap log messages appear with the same timestamp, there would have to be a sub-second timeout somewhere in the path. Does openldap have any default sub-second timeouts? I haven't configured any of the slapd or slapd-ldap timeout options.

Here is a typical log from a failed search:

Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 fd=10 ACCEPT from IP=172.20.11.85:54864 (IP=0.0.0.0:636) Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 fd=10 TLS established tls_ssf=256 ssf=256 Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=0 BIND dn="cn=localuser,ou=users,ou=Native,dc=example,dc=com" method=128 Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=0 BIND dn="cn=localuser,ou=users,ou=Native,dc=example,dc=com" mech=SIMPLE ssf=0 Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=0 RESULT tag=97 err=0 text= Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(sAMAccountName=steve.eckmann)" Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=1 SRCH attr=cn Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=1 ldap_back_retry: retrying URI="ldap://172.30.11.20" DN="cn=remoteuser,ou=users,ou=system accounts,dc=example,dc=com" Jul 15 09:46:09 eck1 slapd[9198]: Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? Jul 15 09:46:09 eck1 slapd[9198]: <= mdb_equality_candidates: (sAMAccountName) not indexed Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 op=2 UNBIND Jul 15 09:46:09 eck1 slapd[9198]: conn=1001 fd=10 closed

Thanks.

Steve