Virtual Servers, the Realms Module, and Proxying

[Jacob Dawson]

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>
        }