Hello list, thanks for version 3.0.4. On our test system here I encountered the following issues regarding the ldap module: 1. rlm_ldap: Falling back to build time libldap version info. Query for LDAP_OPT_API_INFO returned: -1 rlm_ldap: libldap vendor: OpenLDAP version: 20423 Is this an error/warning/info? Should I act on this? 2. lots of: (0) ERROR: ldap : Failed tokenising attribute string: Expecting operator (0) WARNING: ldap : Failed parsing 'radiusAttribute' value "reply:Xylan-Access-Priv += Xylan-Read-Priv" as valuepair, skipping... What have changed regarding generic radiusAttribute in ldap? Thanks in advance, Tobias Hachmer
On 11 Sep 2014, at 03:01, Hachmer, Tobias <Tobias.Hachmer@stadt-frankfurt.de> wrote:
Hello list,
thanks for version 3.0.4. On our test system here I encountered the following issues regarding the ldap module:
1. rlm_ldap: Falling back to build time libldap version info. Query for LDAP_OPT_API_INFO returned: -1 rlm_ldap: libldap vendor: OpenLDAP version: 20423
Is this an error/warning/info? Should I act on this?
You should tell the libldap guys to implement LDAP_OPT_API_INFO. I'll switch it to a debug message.
2. lots of: (0) ERROR: ldap : Failed tokenising attribute string: Expecting operator (0) WARNING: ldap : Failed parsing 'radiusAttribute' value "reply:Xylan-Access-Priv += Xylan-Read-Priv" as valuepair, skipping...
What have changed regarding generic radiusAttribute in ldap?
Nothing interesting. I wonder if something changed in the tokeniser. /* * Retrieve any valuepair attributes from the result, these are generic values specifying * a radius list, operator and value. */ if (inst->valuepair_attr) { char **values; int count, i; values = ldap_get_values(handle, entry, inst->valuepair_attr); count = ldap_count_values(values); for (i = 0; i < count; i++) { value_pair_map_t *attr; RDEBUG3("Parsing attribute string '%s'", values[i]); if (map_from_vp_str(&attr, request, values[i], REQUEST_CURRENT, PAIR_LIST_REPLY, REQUEST_CURRENT, PAIR_LIST_REQUEST) < 0) { RWDEBUG("Failed parsing '%s' value \"%s\" as valuepair, skipping...", inst->valuepair_attr, values[i]); continue; } if (map_to_request(request, attr, map_to_vp, NULL) < 0) { RWDEBUG("Failed adding \"%s\" to request, skipping...", values[i]); } talloc_free(attr); } ldap_value_free(values); } The fact that the debug output shows valid values, probably means it's not the LDAP code. I'll have a look at it later. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
The fact that the debug output shows valid values, probably means it's not the LDAP code. I'll have a look at it later.
Yes, it was the map_from_vp_str code. It's now been fixed to allow list qualifiers. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hello Arran, On 09/11/2014 11:45 PM, Arran Cudbard-Bell wrote:
The fact that the debug output shows valid values, probably means it's not the LDAP code. I'll have a look at it later.
Yes, it was the map_from_vp_str code. It's now been fixed to allow list qualifiers.
Thanks for the fix! Would there be a bug fixed verion 3.0.4 or do I have to patch 3.0.4 manually? Regards, Tobias
On 12 Sep 2014, at 01:42, Tobias Hachmer <tobias@hachmer.de> wrote:
Hello Arran,
On 09/11/2014 11:45 PM, Arran Cudbard-Bell wrote:
The fact that the debug output shows valid values, probably means it's not the LDAP code. I'll have a look at it later.
Yes, it was the map_from_vp_str code. It's now been fixed to allow list qualifiers.
Thanks for the fix! Would there be a bug fixed verion 3.0.4 or do I have to patch 3.0.4 manually?
Patch it manually. It's not a critical issue for the vast majority of users. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Arran Cudbard-Bell -
Hachmer, Tobias -
Tobias Hachmer