Issue with VSA Attributes with Tags and 3.0x
Hi I'm trying to pass a number of Tunnel-Type VSAs from RFC2868 back that have multiple tags to a NAS using LDAP generic mapping attributes. This used to work in 2.x, but no longer works in 3.0.x In LDAP I have a multi-valued attribute that contains all the VSAs I want to return: Tunnel-Type:1 = L2TP Tunnel-Type:2 = L2TP Tunnel-Medium-Type:1 = IP Tunnel-Medium-Type:2 = IP Tunnel-Server-Endpoint:1 = 1.2.3.4 Tunnel-Server-Endpoint:2 = 2.3.4.5 Previously in 2.x I had the ldap.attrmap to set the $GENERIC$ point to the ldap attribute I have defined replyItem $GENERIC$ ReplyProfile Received Access-Accept Service-Type = Outbound-User Tunnel-Type:1 = L2TP Tunnel-Type:2 = L2TP Tunnel-Medium-Type:1 = IPv4 Tunnel-Medium-Type:2 = IPv4 Tunnel-Server-Endpoint:1 = "1.2.3.4" Tunnel-Server-Endpoint:2 = "2.3.4.5" Doing the same thing in 3.0.x I have set the update reply to the same LDAP Attribute. update { reply: += 'ReplyProfile' } Received Access-Accept Service-Type = Outbound-User Tunnel-Type:0 = L2TP Tunnel-Type:0 = L2TP Tunnel-Medium-Type:0 = IPv4 Tunnel-Medium-Type:0 = IPv4 Tunnel-Server-Endpoint:0 = "1.2.3.4" Tunnel-Server-Endpoint:0 = "2.3.4.5" The issue I can see is in rlm_ldap it is calling map_to_vp to convert the map into a Value Pair, but the tag never gets added to the VP. In main/map.c under map_to_vp case TMPL_TYPE_LITERAL: Needs to pass back the tag new->tag = map->lhs->tmpl_tag; I've created a pull request here: https://github.com/FreeRADIUS/freeradius-server/pull/1191 Hopefully that's all correct? Cheers Peter
On 15 Aug 2015, at 18:17, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
Hi
I'm trying to pass a number of Tunnel-Type VSAs from RFC2868 back that have multiple tags to a NAS using LDAP generic mapping attributes.
This used to work in 2.x, but no longer works in 3.0.x
In LDAP I have a multi-valued attribute that contains all the VSAs I want to return:
Tunnel-Type:1 = L2TP Tunnel-Type:2 = L2TP Tunnel-Medium-Type:1 = IP Tunnel-Medium-Type:2 = IP Tunnel-Server-Endpoint:1 = 1.2.3.4 Tunnel-Server-Endpoint:2 = 2.3.4.5
Previously in 2.x I had the ldap.attrmap to set the $GENERIC$ point to the ldap attribute I have defined
*sigh* that was a a hack for backwards compatibility. You should really use the generic attribute, and qualify your attributes in LDAP with list prefixes. I guess it should still be fixed though. It's feeling a lot like map_to_request and callbacks should be altered in v3.1.x so that they produce a list of maps with the rhs resolved to TMPL_TYPE_DATA, instead of producing VPs. We then get rid of the 'op' field from VALUE_PAIRs and remove all the pairmove functions and switch everything to operate on map lists. That's a lot cleaner where the destination is a list, or looking forward, a grouping attribute. I've merged your changes for v3.0.x, and done a similar thing for map_exec_to_vp which should fix the same issues when passing back pairs using backtick expansion and a list on the LHS. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sun, Aug 16, 2015 at 11:01 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On 15 Aug 2015, at 18:17, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
Hi
I'm trying to pass a number of Tunnel-Type VSAs from RFC2868 back that have multiple tags to a NAS using LDAP generic mapping attributes.
This used to work in 2.x, but no longer works in 3.0.x
In LDAP I have a multi-valued attribute that contains all the VSAs I want to return:
Tunnel-Type:1 = L2TP Tunnel-Type:2 = L2TP Tunnel-Medium-Type:1 = IP Tunnel-Medium-Type:2 = IP Tunnel-Server-Endpoint:1 = 1.2.3.4 Tunnel-Server-Endpoint:2 = 2.3.4.5
Previously in 2.x I had the ldap.attrmap to set the $GENERIC$ point to the ldap attribute I have defined
*sigh* that was a a hack for backwards compatibility. You should really use the generic attribute, and qualify your attributes in LDAP with list prefixes. I guess it should still be fixed though.
Yep... The $GENERIC$ was used in 2.x in the ldap.attrmap and $GENERIC$ was a beautiful thing. Now in 3.0.x I am now using: ldap { update { ... control: += 'proxyControl' request: += 'proxyRequest' reply: += 'proxyReply' } And that works a treat for me now that I have fixed the tag issue :) It's feeling a lot like map_to_request and callbacks should be altered in
v3.1.x so that they produce a list of maps with the rhs resolved to TMPL_TYPE_DATA, instead of producing VPs. We then get rid of the 'op' field from VALUE_PAIRs and remove all the pairmove functions and switch everything to operate on map lists.
That too would make more sense, since there would be less steps in the translation and places things like tag and other esoteric VSAs types that get missed in code from when the data is sucked out of the database whatever flavour that database maybe until it's on the wire.
That's a lot cleaner where the destination is a list, or looking forward, a grouping attribute.
I've merged your changes for v3.0.x, and done a similar thing for map_exec_to_vp which should fix the same issues when passing back pairs using backtick expansion and a list on the LHS.
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 16 Aug 2015, at 17:39, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
On Sun, Aug 16, 2015 at 11:01 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On 15 Aug 2015, at 18:17, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
Hi
I'm trying to pass a number of Tunnel-Type VSAs from RFC2868 back that have multiple tags to a NAS using LDAP generic mapping attributes.
This used to work in 2.x, but no longer works in 3.0.x
In LDAP I have a multi-valued attribute that contains all the VSAs I want to return:
Tunnel-Type:1 = L2TP Tunnel-Type:2 = L2TP Tunnel-Medium-Type:1 = IP Tunnel-Medium-Type:2 = IP Tunnel-Server-Endpoint:1 = 1.2.3.4 Tunnel-Server-Endpoint:2 = 2.3.4.5
Previously in 2.x I had the ldap.attrmap to set the $GENERIC$ point to the ldap attribute I have defined
*sigh* that was a a hack for backwards compatibility. You should really use the generic attribute, and qualify your attributes in LDAP with list prefixes. I guess it should still be fixed though.
Yep... The $GENERIC$ was used in 2.x in the ldap.attrmap and $GENERIC$ was a beautiful thing. Now in 3.0.x I am now using:
ldap { update { ... control: += 'proxyControl' request: += 'proxyRequest' reply: += 'proxyReply' }
And that works a treat for me now that I have fixed the tag issue :)
You know generic got even more beautiful and generic and can now represent any list in the server, right? That's what the valuepair_attribute configuration item sets, the one true generic LDAP attribute who's values can represent any request/list and value in the server. You can even do things like: radiusAttribute: outer.request: += `/my/script/that/makes/multuple/attributes` radiusAttribute: request:User-Name := 'foo' radiusAttribute: disconnect:Acct-Session-Id := &outer.request:Acct-Session-Id Code path is similar to update blocks in config files.
It's feeling a lot like map_to_request and callbacks should be altered in
v3.1.x so that they produce a list of maps with the rhs resolved to TMPL_TYPE_DATA, instead of producing VPs. We then get rid of the 'op' field from VALUE_PAIRs and remove all the pairmove functions and switch everything to operate on map lists.
That too would make more sense, since there would be less steps in the translation and places things like tag and other esoteric VSAs types that get missed in code from when the data is sucked out of the database whatever flavour that database maybe until it's on the wire.
It also allows atomic updates again :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Mon, Aug 17, 2015 at 10:06 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
You know generic got even more beautiful and generic and can now represent any list in the server, right?
That's what the valuepair_attribute configuration item sets, the one true generic LDAP attribute who's values can represent any request/list and value in the server.
You can even do things like:
radiusAttribute: outer.request: += `/my/script/that/makes/multuple/attributes`
radiusAttribute: request:User-Name := 'foo'
radiusAttribute: disconnect:Acct-Session-Id := &outer.request:Acct-Session-Id
Code path is similar to update blocks in config files.
Ohhh I did not know that. Very cool. This will make my config even simpler than before. One multivalued LDAP Attribute to rule them all. That then drives me to do something... Update the wiki page: http://wiki.freeradius.org/modules/Rlm_ldap As the wiki is missing so much on v3 changes and niceites on how to setup dynamic clients plus examples of LDIF files on the server side to get people going. Probably worth splitting the page in two for a v2 vs v3 config, as there are still plenty of folks running v2 out there (myself included) that keep on asking the same questions in -users that would probably benefit from reading the wiki.
On 16 Aug 2015, at 20:55, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
On Mon, Aug 17, 2015 at 10:06 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
You know generic got even more beautiful and generic and can now represent any list in the server, right?
That's what the valuepair_attribute configuration item sets, the one true generic LDAP attribute who's values can represent any request/list and value in the server.
You can even do things like:
radiusAttribute: outer.request: += `/my/script/that/makes/multuple/attributes`
radiusAttribute: request:User-Name := 'foo'
radiusAttribute: disconnect:Acct-Session-Id := &outer.request:Acct-Session-Id
Code path is similar to update blocks in config files.
Ohhh I did not know that. Very cool. This will make my config even simpler than before. One multivalued LDAP Attribute to rule them all.
That then drives me to do something... Update the wiki page: http://wiki.freeradius.org/modules/Rlm_ldap As the wiki is missing so much on v3 changes and niceites on how to setup dynamic clients plus examples of LDIF files on the server side to get people going. Probably worth splitting the page in two for a v2 vs v3 config, as there are still plenty of folks running v2 out there (myself included) that keep on asking the same questions in -users that would probably benefit from reading the wiki.
Feel free :) I agree with splitting, possibly add a v3 suffix to the v3 module pages. Between v1/v2 the modules didn't change a great deal, but there are many new features in v3. Let me know if you need any additional information that's not obvious from the code or config file. Also happy to contribute content too, just extremely busy currently, so it'll be limited to paragraphs instead of walk throughs. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Peter Lambrechtsen