With minimal information as requested by the moderators multiple times. Why doesn't idassert-bind work as expected? When I try an anonymous query to an "LDAP" server via an OpenLDAP server configured as a proxy (backend meta , or backend ldap), the query fails because the OpenLDAP server does not bind (even when I try setting the "idassert-bind" option).
# sample failed anonymous query to AD via OpenLDAP ldapsearch -H "ldap://localhost/" -b "ou=windows,dc=rfa,dc=org" -x
# expected query to be performed by ldap server ldapsearch -H "ldap://dc1.rfa.org/" -b "cn=users,dc=rfa,dc=org" \ -D "CN=LDAP Proxy user account,OU=Windows,DC=rfa,DC=org" -W \ -x
# using (tcpdump -x -s0 port 389) I never see a bind sent from OpenLDAP, # and instead I see an error returned from the "LDAP" server because a # bind not successful.
# backend meta portion of the slapd.conf file ##database ldap database meta
suffix "ou=windows,dc=rfa,dc=org" uri "ldap://dc1.rfa.org/ou=windows,dc=rfa,dc=org"
suffixmassage ou=windows,dc=rfa,dc=org cn=users,dc=rfa,dc=org
idassert-authzFrom "dn:*" #Xidassert-bind bindmethod=simple binddn="ldap-proxy@rfa.org" credentials="222222" idassert-bind bindmethod=simple binddn="CN=LDAP Proxy user account,OU=Windows,DC=rfa,DC=org" credentials="222222" mode=none dncache-ttl 60
My environment is made up of Debian stable (4.0 Etch) on the workstations and OpenLDAP server, OpenLDAP 2.3.30-5 on the server. "LDAP" Server on the remote end.
thank you, donfede
Your setup, with minor changes (the naming contexts, and the remote server is OpenLDAP as well) works just fine with current re23 and HEAD code, using either slapd-meta(5) (why?) or slapd-ldap(5) with slapo-rwm(5). So the devil must be in the details. In any case, since OpenLDAP 2.3.30 there were at least 10 fixes/ehnahcement to slapd-ldap(5) and at least 6 to slapd-meta(5), so an upgrade might help.
p.
Federico Grau wrote:
With minimal information as requested by the moderators multiple times. Why doesn't idassert-bind work as expected? When I try an anonymous query to an "LDAP" server via an OpenLDAP server configured as a proxy (backend meta , or backend ldap), the query fails because the OpenLDAP server does not bind (even when I try setting the "idassert-bind" option).
# sample failed anonymous query to AD via OpenLDAP ldapsearch -H "ldap://localhost/" -b "ou=windows,dc=rfa,dc=org" -x # expected query to be performed by ldap serverldapsearch -H "ldap://dc1.rfa.org/" -b "cn=users,dc=rfa,dc=org" \ -D "CN=LDAP Proxy user account,OU=Windows,DC=rfa,DC=org" -W \ -x
# using (tcpdump -x -s0 port 389) I never see a bind sent from OpenLDAP, # and instead I see an error returned from the "LDAP" server because a # bind not successful. # backend meta portion of the slapd.conf file ##database ldap database meta suffix "ou=windows,dc=rfa,dc=org" uri "ldap://dc1.rfa.org/ou=windows,dc=rfa,dc=org" suffixmassage ou=windows,dc=rfa,dc=org cn=users,dc=rfa,dc=org idassert-authzFrom "dn:*" #Xidassert-bind bindmethod=simple binddn="ldap-proxy@rfa.org" credentials="222222" idassert-bind bindmethod=simple binddn="CN=LDAP Proxy user account,OU=Windows,DC=rfa,DC=org" credentials="222222" mode=none dncache-ttl 60My environment is made up of Debian stable (4.0 Etch) on the workstations and OpenLDAP server, OpenLDAP 2.3.30-5 on the server. "LDAP" Server on the remote end.
thank you, donfede
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Hello Pierangelo,
First, thank you for the response. I will re-test with the current stable release (2.3.32).
FYI, we chose the slapd-meta backend to allow for redundancy and work with multiple remote servers (I had read in the man page "the ldap backend is intended to proxy operations directed to a single server").
Would you have a sample configuration file for the working situtation? I never see a "simple authentication" bind go out from the OpenLDAP meta server, so something is definitely wrong on that end (either configuration or bug).
best to you, donfede
On Thu, May 17, 2007 at 07:32:03PM +0200, Pierangelo Masarati wrote:
Your setup, with minor changes (the naming contexts, and the remote server is OpenLDAP as well) works just fine with current re23 and HEAD code, using either slapd-meta(5) (why?) or slapd-ldap(5) with slapo-rwm(5). So the devil must be in the details. In any case, since OpenLDAP 2.3.30 there were at least 10 fixes/ehnahcement to slapd-ldap(5) and at least 6 to slapd-meta(5), so an upgrade might help.
p.
Federico Grau wrote:
With minimal information as requested by the moderators multiple times. Why doesn't idassert-bind work as expected? When I try an anonymous query to an "LDAP" server via an OpenLDAP server configured as a proxy (backend meta , or backend ldap), the query fails because the OpenLDAP server does not bind (even when I try setting the "idassert-bind" option).
# sample failed anonymous query to AD via OpenLDAP ldapsearch -H "ldap://localhost/" -b "ou=windows,dc=rfa,dc=org" -x # expected query to be performed by ldap serverldapsearch -H "ldap://dc1.rfa.org/" -b "cn=users,dc=rfa,dc=org" \ -D "CN=LDAP Proxy user account,OU=Windows,DC=rfa,DC=org" -W \ -x
# using (tcpdump -x -s0 port 389) I never see a bind sent from OpenLDAP, # and instead I see an error returned from the "LDAP" server because a # bind not successful. # backend meta portion of the slapd.conf file ##database ldap database meta suffix "ou=windows,dc=rfa,dc=org" uri "ldap://dc1.rfa.org/ou=windows,dc=rfa,dc=org" suffixmassage ou=windows,dc=rfa,dc=org cn=users,dc=rfa,dc=org idassert-authzFrom "dn:*" #Xidassert-bind bindmethod=simple binddn="ldap-proxy@rfa.org" credentials="222222" idassert-bind bindmethod=simple binddn="CN=LDAP Proxy user account,OU=Windows,DC=rfa,DC=org" credentials="222222" mode=none dncache-ttl 60My environment is made up of Debian stable (4.0 Etch) on the workstations and OpenLDAP server, OpenLDAP 2.3.30-5 on the server. "LDAP" Server on the remote end.
thank you, donfede
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Federico Grau wrote:
Hello Pierangelo,
First, thank you for the response. I will re-test with the current stable release (2.3.32).
After reading the CHANGES in re23, you should rather use 2.3.35.
FYI, we chose the slapd-meta backend to allow for redundancy and work with multiple remote servers (I had read in the man page "the ldap backend is intended to proxy operations directed to a single server").
If by "redundancy" you mean that in case of failure of a server another one will be contacted, then it has nothing to do with the difference between back-meta and back-ldap. The way both handle lists of multiple servers in case of failure is identical. Back-meta assumes that the servers related to each "uri" statement contain different data. So
database ldap uri "ldap://ldap.example.com ldap://backup.example.com"
is redundancy (sort of);
database meta uri "ldap://ldap.example.com/<suffix> ldap://backup.example.com"
is exactly the same level of redundancy (sort of);
database meta uri "ldap://ldap.example.com/<suffix>" uri "ldap://backup.example.com/<suffix>"
is a configuration error...
Would you have a sample configuration file for the working situtation? I never see a "simple authentication" bind go out from the OpenLDAP meta server, so something is definitely wrong on that end (either configuration or bug).
I tested:
database ldap suffix "ou=windows,dc=rfa,dc=org" uri "ldap://:9011/" overlay rwm rwm-suffixmassage "ou=windows,dc=rfa,dc=org" "ou=People,dc=example,dc=com"
idassert-authzFrom "dn:*" idassert-bind bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials="secret" mode=none
database meta suffix "ou=windows,dc=rfa,dc=org" uri "ldap://:9011/ou=windows,dc=rfa,dc=org" suffixmassage "ou=windows,dc=rfa,dc=org" "ou=People,dc=example,dc=com"
idassert-authzFrom "dn:*" idassert-bind bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials="secret" mode=none
where, of course, in both cases ldap://:9011 was pointing to another instance of slapd running on port 9011 as resulting from running test003. To make sure authentication was progressing, I modified the configuration of that slapd with a simple
access to * by * auth
so that the only way data could be read was after successfully binding as the rootdn of the remote server, as configured in both idassert-bind.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-software@openldap.org
-
Federico Grau -
Pierangelo Masarati