3.0.4: binary LDAP attributes
aland at deployingradius.com
Thu Mar 23 13:59:41 CET 2017
> On Mar 23, 2017, at 5:23 AM, Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:
> On 12/09/2014 01:51 PM, Nikolai Kondrashov wrote:
>> Our (Red Hat) QA was testing the effect of this entry in 3.0.4 ChangeLog:
>> * Modify pairparsevalue to deal with embedded NULLs better,
>> and use the binary versions of attribute values in rlm_ldap.
>> They have noticed that binary LDAP values get truncated on embedded zero
>> characters (\0) in RADIUS replies, in radiusReplyMessage in particular.
>> I.e. for
>> radiusReplyMessage:: cmVwbHkgd2l0aCBhAGI=
>> The response output by radtest was
>> Reply-Message = 'reply with a'
>> The network capture also showed that RADIUS reply packets contained truncated
> We still see the above behavior in v3.0.13.
> Please excuse me, if you explained it before, but is this intended,
> or is this a bug?
The underlying issue is how strings are dealt with. The various LDAP APIs and rlm_ldap take char* and length pointers, so that works.
The underlying issue is in src/main/map.c, map_afrom_attr_str(). It takes a char* pointer which contains operator and value. e.g. ":= bob". That gets parsed into separate fields, but the length of the underlying string is not used.
I'm not sure why that's done for rlm_ldap, as the operators are already in the "map" config of raddbs/mods-enabled/ldap.
So the short answer is that the values in LDAP are *printable* strings, not *raw* strings. This likely goes back to the origin of the server.
i.e. if you want embedded NULs, double quotes, etc... you've got to escape them.
And on top of that, Reply-Message is usually a UTF-8 string. So putting embedded zeros into a printable string will confuse a lot more products than just FreeRADIUS.
i.e. don't do it.
More information about the Freeradius-Users