Thanks for the quick reply, Howard. I looked at the relevant code in bind.c, and of course what you say about it makes sense. The odd thing is that I am doing exactly the same search twice. The first fails, the second succeeds, so can it really be a credential problem? I'm going to chase down what our intermediate proxy is; maybe it's returning something bogus to openldap, but if so I haven't been able to capture it in a log.

Regards, Steve

-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Monday, July 15, 2013 10:52 AM To: Steve Eckmann; openldap-technical@openldap.org Subject: Re: need help interpreting "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?"

Steve Eckmann wrote:

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.

You can find the relevant code in back-ldap/bind.c. It means it was trying to do proxy authorization on the connection but doesn't have the required credentials or some other config item so it couldn't authorize to the remote server. So go check your back-ldap configuration again.

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

Thanks, Liam. I will look more carefully at our schema and the search. I thought I had included definitions of all the AD attributes we use, but possibly not, and that would be an easy fix.

Regards, Steve

-----Original Message----- From: Liam Gretton [mailto:liam.gretton@leicester.ac.uk] Sent: Monday, July 22, 2013 9:52 AM To: openldap-technical@openldap.org Subject: Re: need help interpreting "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?"

On 15/07/2013 18:00, Steve Eckmann wrote:

The odd thing is that I am doing exactly the same search twice. The first fails, the second succeeds, so can it really be a credential problem? I'm going to chase down what our intermediate proxy is; maybe it's returning something bogus to openldap, but if so I haven't been able to capture it in a log.

I see similar behaviour with the meta backend. If you don't have a suitable schema defined for the AD attributes, it's necessary to first search with an attribute that OpenLDAP does recognise (e.g. cn). Until then attributes such as sAMAccountName will be unknown. After a successful search that returns (say) sAMAccountName, OpenLDAP will happily use it for auth.

Assuming your issue is the same, try defining a suitable schema for your AD attributes. You can't use the Microsoft one directly unfortunately as MS uses some syntaxes that aren't present in OpenLDAP, and it's not easy to add additional syntaxes. But you can get away with creating a schema just for the attributes you're interested in.

Alternatively the quick and very dirty workaround is to perform a suitable search on initialisation.