[Date Prev][Date Next]
Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)
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 email@example.com -Y digest-md5