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
