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

Re: Bug in LDAP_CONTROL_PROXY_AUTHZ (ITS#2871)



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

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it