Virtual Servers, the Realms Module, and Proxying
Our goal here is to use a variety of virtual servers in our FreeRADIUS instance to allow us to isolate handling of a variety of different sorts of users. As such, there's a fair bit of proxying going on, but much is just going to the virtual servers, and we'd like to be able to use the behavior of the realms module to make this work for us. Unfortunately, I haven't seen any way to get some of those attributes that the Realm module inserts to continue through after being proxied, as they're 'internal' attributes and not wire attributes. I'd like for the Stripped-User-Name and Realm attributes to be available to the far side of the proxy (so I send it from the default virtual server to, say, the generic_realm virtual server), so that it can make decisions based on that information. I obviously can't use the realms module for parsing again in the first layer of virtual server, as I'll just end up creating a loopback on itself, but at the same time, I'd like to avoid having to do all that parsing and thinking in unlang. Since there seems to be some special config for virtual servers, is there any way to achieve this behavior (not stripping the 'internal' attributes when proxying to virtual servers) without a patch? It seems to be consistent with the idea behind virtual servers, but I may be misinterpreting it. Thoughts? I feel like we're trying a little too hard to get what we want, here, but I'm not seeing how to do it the 'right' way. Jacob M. Dawson Network Research Engineer Virginia Tech --- For context: I have an arbitrary number of FreeRADIUS servers providing my AAA service. I have an arbitrary number of NASs all talking to the FreeRADIUS servers, and they all provide the same suite of services to all possible users, so I can't do this proxying based on what client it comes in on (like this page suggests: http://freeradius.org/features/virtual_servers.html). My realm module is short and sweet: realm suffix { format = suffix delimiter = "@" ignore_null = yes } realm prefix { format = prefix delimiter = "\\" } I have the following virtual servers linked in sites-enabled: ad.vt.edu default ed.vt.edu generic-realm proxy-inner-tunnel ad.vt.edu is to handle our Domain users ed.vt.edu is to handle folks authenticating against our Enterprise Directory default is, of course, where they come in to start with generic-realm is intended to handle people who come in with SOME non-vt realm. Could be guests (authenticated against our AAA-related database, access via the sql module), could be eduroam folks. proxy-inner-tunnel is used largely by the ad.vt.edu module to handle proxying the MS-CHAPv2 part of PEAP to our IAS machines. default is simple: authorize { update request{ User-Name := "%{tolower:%{User-Name}}" } preprocess auth_log chap mschap perl suffix prefix eap { ok = return } expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } ldap eap } <other stanzas don't seem relevant> In proxy, we defined these home_servers: home_server ed.vt.edu { type = auth ipaddr = 127.0.0.1 port = 1816 secret = <redacted> } home_server ad.vt.edu { type = auth ipaddr = 127.0.0.1 port = 1815 secret = <redacted> } home_server generic_realm { type = auth ipaddr = 127.0.0.1 port = 1817 secret = <redacted> } home_server_pool ad_virtual_pool { home_server = ad.vt.edu } home_server_pool ed_virtual_pool { home_server = ed.vt.edu } home_server_pool generic_virtual_pool { home_server = generic_realm } realm "~HOKIES" { auth_pool = ad_virtual_pool nostrip } realm "DomainUser" { auth_pool = HOKIES_authen nostrip } realm "~.*w2k\\.vt\\.edu$" { auth_pool = ad_virtual_pool nostrip } realm "~vt.edu$" { auth_pool = ed_virtual_pool } realm LOCAL { } realm NULL { auth_pool = ed_virtual_pool } realm DEFAULT { auth_pool = generic_virtual_pool } Our virtual servers then start off like this, and then include the usual appropriate stanzas: listen { ipaddr = 127.0.0.1 port = 1815 type = auth } client 127.0.0.1 { secret = <redacted> }
On Fri, Aug 5, 2011 at 2:39 AM, Jacob Dawson <dawson@vt.edu> wrote:
I obviously can't use the realms module for parsing again in the first layer of virtual server, as I'll just end up creating a loopback on itself, but at the same time, I'd like to avoid having to do all that parsing and thinking in unlang. Since there seems to be some special config for virtual servers, is there any way to achieve this behavior (not stripping the 'internal' attributes when proxying to virtual servers) without a patch? It seems to be consistent with the idea behind virtual servers, but I may be misinterpreting it.
Thoughts? I feel like we're trying a little too hard to get what we want, here, but I'm not seeing how to do it the 'right' way.
Try raddb/modules/attr_filter -- Fajar
The whole realms/ suffix/ prefix methodology has been obsoleted by Unlang. If you load up policy.conf in the master branch (use GitHub) there's an example of proxying using unlang. Just re-parse the User-Name string each time a request comes into one of the Virtual Servers. Incidentally, been down that route many years ago. I think you're maybe the second or third person on the list who's asked about this. Yes it's a brilliant way to organise the server. No it won't work out like you want it to. FreeRADIUS does not have unlimited internal proxy hops. So if you have an outer listen server, which proxies to another outer server, with un-encapsulates EAP and proxies to an inner server, which proxies to another inner server, somewhere in that line of proxying you'll hit a random error and the request will fail. I keep poking Alan to fix it, but he says its hard. -Arran
Our goal here is to use a variety of virtual servers in our FreeRADIUS instance to allow us to isolate handling of a variety of different sorts of users. As such, there's a fair bit of proxying going on, but much is just going to the virtual servers, and we'd like to be able to use the behavior of the realms module to make this work for us.
Unfortunately, I haven't seen any way to get some of those attributes that the Realm module inserts to continue through after being proxied, as they're 'internal' attributes and not wire attributes. I'd like for the Stripped-User-Name and Realm attributes to be available to the far side of the proxy (so I send it from the default virtual server to, say, the generic_realm virtual server), so that it can make decisions based on that information. I obviously can't use the realms module for parsing again in the first layer of virtual server, as I'll just end up creating a loopback on itself, but at the same time, I'd like to avoid having to do all that parsing and thinking in unlang. Since there seems to be some special config for virtual servers, is there any way to achieve this behavior (not stripping the 'internal' attributes when proxying to virtual servers) without a patch? It seems to be consistent with the idea behind virtual servers, but I may be misinterpreting it.
Thoughts? I feel like we're trying a little too hard to get what we want, here, but I'm not seeing how to do it the 'right' way.
Jacob M. Dawson Network Research Engineer Virginia Tech
---
For context: I have an arbitrary number of FreeRADIUS servers providing my AAA service. I have an arbitrary number of NASs all talking to the FreeRADIUS servers, and they all provide the same suite of services to all possible users, so I can't do this proxying based on what client it comes in on (like this page suggests: http://freeradius.org/features/virtual_servers.html).
My realm module is short and sweet: realm suffix { format = suffix delimiter = "@" ignore_null = yes } realm prefix { format = prefix delimiter = "\\" }
I have the following virtual servers linked in sites-enabled: ad.vt.edu default ed.vt.edu generic-realm proxy-inner-tunnel
ad.vt.edu is to handle our Domain users ed.vt.edu is to handle folks authenticating against our Enterprise Directory default is, of course, where they come in to start with generic-realm is intended to handle people who come in with SOME non-vt realm. Could be guests (authenticated against our AAA-related database, access via the sql module), could be eduroam folks. proxy-inner-tunnel is used largely by the ad.vt.edu module to handle proxying the MS-CHAPv2 part of PEAP to our IAS machines.
default is simple: authorize { update request{ User-Name := "%{tolower:%{User-Name}}" } preprocess auth_log chap mschap perl suffix prefix eap { ok = return } expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } ldap eap } <other stanzas don't seem relevant>
In proxy, we defined these home_servers: home_server ed.vt.edu { type = auth ipaddr = 127.0.0.1 port = 1816 secret = <redacted> } home_server ad.vt.edu { type = auth ipaddr = 127.0.0.1 port = 1815 secret = <redacted> } home_server generic_realm { type = auth ipaddr = 127.0.0.1 port = 1817 secret = <redacted> } home_server_pool ad_virtual_pool { home_server = ad.vt.edu } home_server_pool ed_virtual_pool { home_server = ed.vt.edu } home_server_pool generic_virtual_pool { home_server = generic_realm }
realm "~HOKIES" { auth_pool = ad_virtual_pool nostrip } realm "DomainUser" { auth_pool = HOKIES_authen nostrip } realm "~.*w2k\\.vt\\.edu$" { auth_pool = ad_virtual_pool nostrip } realm "~vt.edu$" { auth_pool = ed_virtual_pool } realm LOCAL { } realm NULL { auth_pool = ed_virtual_pool } realm DEFAULT { auth_pool = generic_virtual_pool }
Our virtual servers then start off like this, and then include the usual appropriate stanzas: listen { ipaddr = 127.0.0.1 port = 1815 type = auth } client 127.0.0.1 { secret = <redacted> }
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Half the complexity of Diameter
Well, we can certainly finagle that in Unlang, with a little thinking. I played with that earlier in this project. Happy to leave module/realm if that's the best route, and that means I can probably pull all of that out of proxy.conf, too. I don't think we'll run into the internal proxy chain problem, since we're sending the inner tunnel off to IAS. I'll keep this in mind if it seems to be randomly breaking, though. Thanks for the prompt response. - Jacob On 4 Aug 2011, at 15:54, Arran Cudbard-Bell wrote:
The whole realms/ suffix/ prefix methodology has been obsoleted by Unlang.
If you load up policy.conf in the master branch (use GitHub) there's an example of proxying using unlang. Just re-parse the User-Name string each time a request comes into one of the Virtual Servers.
Incidentally, been down that route many years ago. I think you're maybe the second or third person on the list who's asked about this. Yes it's a brilliant way to organise the server. No it won't work out like you want it to.
FreeRADIUS does not have unlimited internal proxy hops. So if you have an outer listen server, which proxies to another outer server, with un-encapsulates EAP and proxies to an inner server, which proxies to another inner server, somewhere in that line of proxying you'll hit a random error and the request will fail.
I keep poking Alan to fix it, but he says its hard.
-Arran
Arran Cudbard-Bell a.cudbardb@freeradius.org
RADIUS - Half the complexity of Diameter
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Arran Cudbard-Bell -
Fajar A. Nugraha -
Jacob Dawson