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

Re: rewriting compare ava with overlay rwm

On Sat, 2007-04-28 at 10:44 +0200, Pierangelo Masarati wrote:
Jens Grigel wrote:

> I'm still not sure if this is actually possible with overlay rwm or if
> i'm misunderstanding the manpage of slapo-rwm. 
> Rewriting the cn's in searches, searchresults, bindDN and compareDN
> works, but the AVA from the compared 
> attribute (here: cn) is not changed from rewriteContext compareAttrDN. 
> "man slapo-rwm" says that the rewriteContext compareAttrDN rewrites
> compare AVA, but whatever i try it's not 
> changing anything in the ldapcompare.

The compare AVA is rewritten if it is DN-valued.  That's the reason of
the context name: compareAttrDN.  So slapo-rwm(5) does not rewrite an
arbitrary AVA's value, only DN-valued ones.

Hi Pierangelo,

thank you for clarifying this, that was what I initially understood from the manpage, but I couldn't make rewriting succeed so I got unsure about the format.

But even if I call ldapcompare with a DN-valued AVA and build a regex for compareAttrDN which should match this DN-valued AVA nothing is rewritten. Packet tracing still shows the unchanged AVA gets send to the remote LDAP-Server.

I'm trying:

ldapcompare -x -D "" -H ldap://testproxy.intra.sskm.de cn=99854,o=sskm cn:cn=99854,o=sskm

and have the following slapd.conf:
# suffixmassage
overlay rwm
rwm-suffixmassage "o=sskm" "ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern"
# ldap proxy
database  ldap
suffix "ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern"
uri "ldap://"
network-timeout 3
chase-referrals no
idassert-bind bindmethod=simple binddn="cn=q001ldap,ou=dienstkonten,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern" credentials="ldap.Lebt" mode=none
idassert-authzFrom "dn.regex:.*"
# rewriting for ldap proxy
overlay rwm
rwm-rewriteEngine on
rwm-rewriteContext compareDN
rwm-rewriteRule "cn=99([0-9]{3}),(.+)" "cn=s001x$1,$2"
rwm-rewriteContext compareAttrDN
rwm-rewriteRule "cn=99([0-9]{3}),(.+)" "cn=s001x$1,$2"

Then the packet trace shows the follwing send to the remote LDAP-Server:

    entry: cn=s001x854,ou=benutzer,ou=konten,ou=institut,dc=e001dpk1,dc=e001,dc=intern
        attributeDesc: cn
        assertionValue: cn=99854,o=sskm

The CompareDN gets rewritten by suffixmassage and context compareDN as expected,
but nothing happens with CompareAttrDN. Any hints what I'm still doing wrong?


Jens Grigel

Citysavingsbank Munich, Germany
Dept. of Network/Security