[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