[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP proxy, identity assertion and suffix massage



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.