Le 5 septembre 2011 00:09, masarati@aero.polimi.it a écrit :
Hello,
I am using OpenLDAP 2.4.26 on GNU/Linux. I would like to configure a simple proxy with identity assertion and suffix massage and assert identity for the rootdn of my LDAP backend, to match the rootdn of the proxied backend (on port 390).
Here is my configuration :
database ldap suffix "ou=am,dc=local" rootdn "cn=manager,ou=am,dc=local" rootpw secretproxy
uri ldap://127.0.0.1:390
idassert-bind bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials="secret" mode=none idassert-authzFrom "dn.exact:cn=manager,ou=am,dc=local"
overlay rwm rwm-suffixmassage "ou=am,dc=local" "dc=example,dc=com"
When I try to authenticate with "cn=manager,ou=am,dc=local" on the proxy, the bind is forwarded to the proxied directory directly, as "cn=manager,dc=example,dc=com". It seems the rwm overlay has done the substitution, so the idassert-authzFrom does not match. This ended with an LDAP error 48, as we can see here:
dnPrettyNormal: <cn=manager,ou=am,dc=local>
=> ldap_bv2dn(cn=manager,ou=am,dc=local,0) <= ldap_bv2dn(cn=manager,ou=am,dc=local)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,ou=am,dc=local)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,ou=am,dc=local)=0 <<< dnPrettyNormal: <cn=manager,ou=am,dc=local>, <cn=manager,ou=am,dc=local> conn=1001 op=0 BIND dn="cn=manager,ou=am,dc=local" method=128 do_bind: version=3 dn="cn=manager,ou=am,dc=local" method=128 ==> rewrite_context_apply [depth=1] string='cn=manager,ou=am,dc=local' ==> rewrite_rule_apply rule='((.+),)?ou=am,[ ]?dc=local$' string='cn=manager,ou=am,dc=local' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'cn=manager,dc=example,dc=com'} [rw] bindDN: "cn=manager,ou=am,dc=local" -> "cn=manager,dc=example,dc=com"
dnPrettyNormal: <cn=manager,dc=example,dc=com>
=> ldap_bv2dn(cn=manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> ===>slap_sasl_match: comparing DN cn=manager,dc=example,dc=com to rule dn:cn=manager,ou=am,dc=local slap_parseURI: parsing dn:cn=manager,ou=am,dc=local <===slap_sasl_match: comparison returned 48 send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=48 matched="" text="" send_ldap_response: msgid=1 tag=97 err=48
Do you have any suggestion for using the idassert-authzFrom parameter with the suffixmassage?
There are many orders of problems in your configuration, essentially related to rewriting. First of all:
- the bind as the rootdn of the proxy cannot be successful, unless the
mapped identity exists on the remote server. In fact, the bind request is rewritten, but the rootdn string it is compared against is not. So despite binding as "cn=manager,ou=am,dc=local", what back-ldap's bind sees is "cn=manager,dc=example,dc=com", which of course does not match the value of the rootdn parameter. As a consequence, the bind gets proxied.
- in order for idassert-authzFrom to work as intended, you need to write
it with the massaged naming context. In fact, all back-ldap sees is mapped. I suggest, as a series of workarounds, to do something like this:
database ldap suffix "cn=manager,ou=am,dc=local" rootdn "cn=manager,ou=am,dc=local" rootpw secretproxy
database ldap suffix "ou=am,dc=local" uri ldap://:390
that is: first you add a fake ldap database that simply allows to bind locally as the "cn=manager,ou=am,dc=local" identity, which is the intended rootdn; note that there is no URI, so any other operation within that naming context will fail (any other database type that honors the rootdn without requiring too much configuration is fine).
Then you configure the ldap database serving the "ou=am,dc=local" naming context with no rootdn. Requests with "cn=manager,ou=am,dc=local" will authenticate locally, using the fake slapd-ldap; other requests will be handled by the real proxy backend, with that identity. So now your idassert-authzFrom rule works as intended.
Hope this helps. p.
Hello,
thanks a lot for this answer, the LDAP backend for the local authentication is a great idea and works like a charm!
For those interested, I updated my little multiple SASL delegation How-To, with a solution based on the meta backend, and the other with the ldap backend : http://ltb-project.org/wiki/documentation/general/sasl_delegation
Clément.