Virtual Servers, the Realms Module, and Proxying

[Arran Cudbard-Bell]

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 at freeradius.org

RADIUS - Half the complexity of Diameter