Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)

[igor@ipass.net]

On Sat, 13 Dec 2003, Pierangelo Masarati wrote:

>
> >
> > On Sat, 13 Dec 2003, Pierangelo Masarati wrote:
> >
> >> > The parsing of authzid works as expected, however slap_sasl_getdn()
> >> generates DN of the uid=<userid>,cn=<realm),cn=auth form, rather
> >> than uid=<userid>,cn=<realm>,cn=<mech>,cn=auth.  This causes
> >> problems with existing sasl-regexps which expect <mech> in place of
> >> <realm> as described in slapd.conf.  I hope this explains better.
> >> It seems to me the internal sasl operation does not require mech,
> >> therefore
> >> > slap_sasl_getdn()  cannot set cn=<mech> properly in the sasl DN.
> >>
> >> I need to correct myself.  The code should use the same mech
> >> that was used to authenticate the authc id; apparently, a simple bind
> >> took place instead of a sasl bind.  I wonder i this is
> >> the correct behaviour, though.  In fact, I'm not sure it is
> >> correct that the authz id inherits the same mec of the authc id,
> >> because another operation (the proxyAuthz) intercurred.
> >> As such, we could add the "authz" mechanism to the sasl id,
> >> at least if none is present.
> >>
> >> In any case, you shuld check whether a sasl bind takes place.
> >>
> >
> > It does use sasl bind.  In my case I used digest-md5.
>
> You're right.  There actually is a bug; Howard pointed out that
> slap_sasl_getdn() looks for the method in a member that is
> correctly set only during bind.  Try HEAD code right now.
> I also need to chck whether the realm is still handled properly.

It works with changes.

I needed to change sasl-regex because uid now contains full username
(userid@domain) and the format of saslAuthzTo changed.  It appears that
cn=realm is not generated now even though I passed it on the command
line.  ldapwhoami -U root -R realm -X u=igor@ipass.net -Y digest-md5

-- 
Igor