[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: need help interpreting "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?"
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
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/