[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.