[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: back_ldap, rwm & saslautheticated users
Dieter Kluenter wrote:
> Hello,
> how can a sasl_authz created identity be rewritten, that is, that die
> generated DN matches the DN on the remote server.
>
> The search string is
>
> ldapsearch -Ydigest-md5 -Udieter -w secret \
> -H ldap://localhost:9004 -b "dc=dkluenter,dc=de" -s sub \
> $filter
>
> My configuration:
>
> ,----[ slapd.conf for back_ldap ]
> | ...
> | authz-regexp uid=(.*),cn=.*,cn=auth
> | ldap:///dc=dkluenter,dc=de??sub?uid=$1
> | access to * by * read
> | database ldap
> | suffix dc=dkluenter,dc=de
> | rootdn cn=admin,dc=dkluenter,dc=de
> | uri ldap://localhost:389
> | acl-bind
> | bindmethod=sasl
> | saslmech=digest-md5
> | authcId=admanager
> | credentials=xxx
> | idassert-bind
> | bindmethod=sasl
> | saslmech=digest-md5
> | authcId=admanager
> | credentials=mailer
> | mode=self
> | overlay rwm
> | rwm-rewriteEngine on
> | rwm-suffixmassage "dc=dkluenter,dc=de" "o=avci,c=de"
> `----
>
> The following log shows that the DN string from back_ldap
> "cn=dieter kluenter,ou=partner,dc=dkluenter,dc=de"
> is not rewritten to
> "cn=dieter kluenter,ou=partner,o=avci,c=de"
> which would be the desired result.
>
> ,----[ slapd.log on Master ]
> | slapd[4169]: => acl_mask: access to entry "cn=Dieter Kluenter,ou=Partner,o=avci,c=de", attr "entry" requested
> | slapd[4169]: => acl_mask: to all values by "cn=dieter kluenter,ou=partner,dc=dkluenter,dc=de", (=0)
> | slapd[4169]: <= check a_dn_pat: cn=$1,ou=Partner,o=avci,c=de
> | slapd[4169]: <= check a_group_pat: cn=administratoren,o=avci,c=de
> | slapd[4169]: => bdb_entry_get: found entry: "cn=administratoren,o=avci,c=de"
> | slapd[4169]: <= check a_dn_pat: *
> | slapd[4169]: <= acl_mask: [3] applying auth(=xd) (stop)
> | slapd[4169]: <= acl_mask: [3] mask: auth(=xd)
> | slapd[4169]: => slap_access_allowed: search access denied by auth(=xd)
> `----
>
> How can rewriting of the DN be achieved.
Perhaps you show more of your logs. What I see is that the original
identity (i.e. not rewritten) is used in the operation at the remote
server. If this, as I infer, occurs because of a proxyAuthz performed
by the idassert line you configured above, that's expected: the bind
succeeds, and the identity is the result of an internal search, so it's
rewritten with the virtual naming context. Then, proxyAuthz does not
rewrite the identity that's being asserted. To have the rewritten
identity used in the proxyAuthz, you should craft the internal search
rewriting so that the DN of the response is not rewritten.
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
---------------------------------------