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