I'm trying to get Eduroam working on our existing Freeradius service. There are myriad instructions for getting Eduroam working. Unfortunately a majority of them assume you are configuring it to only do Eduroam and nothing else. Currently I am proxying Successfully to Eduroam with the following setup: realm concordia.ca { } realm LOCAL { nostrip } realm NULL { nostrip } realm DEFAULT { pool = EDUROAM-FTLR nostrip } I won't show the pool config for the "DEFAULT" realm. But suffice to say that's working. Also, our legacy users who are authenticating with no realm are working as well. What isn't working are local connections using our local real (user@concordia.ca) and distant AAA requests from Eduroam. The Eduroam cookbook provides some configs that appear to be helpful. But unfortunately they're so broken I can't even put them in my configuration. What the below configs appear to do is check if they are of realm domain.tld and then switch the Proxy-Realm. But the configs are too broken to work.
From what I understand at the first "if" is missing a double quote, and the second one isn't even evaluating and I can't fix it enough to get the server to restart. I have included my fixes, but as I said the preacct if statement still does not allow the server to restart after the config is included.
ORIGINAL authorize { auth_log suffix if (("%{control:Proxy-To-Realm} == "DEFAULT") && (User-Name =~ /.*@.*.domain.tld$/)) { update control { Proxy-To-Realm := NULL } } preacct { detail suffix if ((Proxy-To-Realm = DEFAULT) && (User-Name =~ /.*@.*.domain.tld$/)) update control { Proxy-To-Realm := NULL } } FIXED (???) authorize { auth_log suffix if (("%{control:Proxy-To-Realm}" == "DEFAULT") && (User-Name =~ /.*@.*.domain.tld$/)) { update control { Proxy-To-Realm := NULL } } preacct { detail suffix if ((Proxy-To-Realm == "DEFAULT") && (User-Name =~ /.*@.*.domain.tld$/)) update control { Proxy-To-Realm := NULL } } Nathan Van Fleet Telecommunications Analyst Network Assessment and Integration IITS Concordia University (514) 848-2424 Extension:5434
hi, whilst I can give you snippets of random bits of config too (a bit of unlang and proxy.conf to do what you want), can I suggest you check out a document that we produced somwe time back (written by Arran Cudbard-Bell) - its getting slightly dated now but the general ideas should suffice. I would say one thing, do NOT use DEFAULT (in fact, dont EVER use it ...always have policies to deal with everything) - use unlang to set the realm - local, or 'eduroam' and then only have those entries in proxy.conf http://www.ja.net/documents/services/janet-roaming/sussex-freeradius-case-st... alan
Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
I would say one thing, do NOT use DEFAULT (in fact, dont EVER use it ...always have policies to deal with everything) - use unlang to set the realm - local, or 'eduroam' and then only have those entries in proxy.conf
...I would say *do* use DEFAULT...so there. :) My thinking is that there is no difference in effect if your eduroam unlang policy sends everything it does not know about upstream so why not just reuse the built in FreeRADIUS stuff that does the same. I guess it all depends on how you prefer to think about your packet flow. I have the following in my proxy.conf file: ---- realm NULL { } realm LOCAL { } realm soas.ac.uk { } realm DEFAULT { pool = eduroam nostrip } # blackhole routing realm myabc.com { nostrip } realm "~\\.3gppnetwork\\.org$" { nostrip } ---- Then in my authorize section I use: ---- # handle realmless authentications if ((EAP-Message) && Realm == NULL) { update reply { Reply-Message := "No Realm" } reject } # handle blackhole'd realms if (Realm != "NULL" && Realm != "DEFAULT" && Realm != "soas.ac.uk") { update reply { Reply-Message := "Realm Blackholed" } reject } ---- For me, it means blackholing domains is a lot more straight forward and the packet flow is more 'natural' (as you are not 'forcing' a proxying). However, this parses in my brain, does not mean it will parse in anyone elses :) Cheers -- Alexander Clouter .sigmonster says: If you knew what to say next, would you say it?
Nathan McDavit-Van Fleet <nmcdavit@alcor.concordia.ca> wrote:
Currently I am proxying Successfully to Eduroam with the following setup: realm concordia.ca { }
realm LOCAL { nostrip }
realm NULL { nostrip }
realm DEFAULT { pool = EDUROAM-FTLR nostrip }
I won't show the pool config for the "DEFAULT" realm. But suffice to say that's working. Also, our legacy users who are authenticating with no realm are working as well. What isn't working are local connections using our local real (user@concordia.ca) and distant AAA requests from Eduroam. The Eduroam cookbook provides some configs that appear to be helpful. But unfortunately they're so broken I can't even put them in my configuration.
What the below configs appear to do is check if they are of realm domain.tld and then switch the Proxy-Realm. But the configs are too broken to work.
From what I understand at the first "if" is missing a double quote, and the second one isn't even evaluating and I can't fix it enough to get the server to restart. I have included my fixes, but as I said the preacct if statement still does not allow the server to restart after the config is included.
ORIGINAL authorize { auth_log suffix if (("%{control:Proxy-To-Realm} == "DEFAULT") && (User-Name =~ /.*@.*.domain.tld$/)) { update control { Proxy-To-Realm := NULL } }
'Realm' not 'control:Proxy-To-Realm' (although they probably in effect have the same thing).
preacct { detail suffix if ((Proxy-To-Realm = DEFAULT) && (User-Name =~ /.*@.*.domain.tld$/)) update control { Proxy-To-Realm := NULL } }
FIXED (???) authorize { auth_log suffix if (("%{control:Proxy-To-Realm}" == "DEFAULT") && (User-Name =~ /.*@.*.domain.tld$/)) {
Am I being blind, I'm not seeing any difference here...?
update control { Proxy-To-Realm := NULL }
For 'eduroam' auths, make sure you from *day one* reject Realm-less authentications. If you do not, your helpdesk *will* make shortcuts, and prime laptops that work fine locally, but fail to authenticate when roaming as the visited site will know know where to proxy the authentication to. The reason it is not work is that 'Realm'/'control:Proxy-To-Realm' for your own users is actually 'concordia.ca' (check the output of 'radiusd -X' for hints). So your logic needs to be more (with sanity checking, there is a lot of rubbish out there and that passes through): ---- authorize { preprocess auth_log # handy, the '1' is meant to be there # N.B. ignore the grumbles from IAS sysadmin, 'crime and punishment' update request { Operator-Name := "1concordia.ca" } # Reject Calling-Station-Id-less authentications if (!(Calling-Station-Id)) { update reply { Reply-Message := "No Calling-Station-Id" } reject } if (!(User-Name)) { update reply { Reply-Message := "No User-Name" } reject } suffix # handle realmless authentications if (Realm == NULL) { update reply { Reply-Message := "No Realm" } reject } # handle blackhole'd realms if (Realm != "NULL" && Realm != "DEFAULT" && Realm != "concordia.ca") { update reply { Reply-Message := "Realm Blackholed" } reject } if (!(EAP-Message)) { update reply { Reply-Message := "No EAP-Message" } reject } EAP { ok = return } # 'handled' after EAP so we can record what guests are using if (Realm == DEFAULT) { # workaround crappy load-balancing update control { Load-Balance-Key := "%{NAS-IPv6-Address} %{NAS-IP-Address} %{NAS-Port} %{User-Name} %{Calling-Station-Id}" } handled } } ---- -- Alexander Clouter .sigmonster says: I live the way I type; fast, with a lot of mistakes.
Nathan McDavit-Van Fleet wrote:
I won’t show the pool config for the “DEFAULT” realm. But suffice to say that’s working. Also, our legacy users who are authenticating with no realm are working as well. What isn’t working are local connections using our local real (user@concordia.ca) and distant AAA requests from Eduroam. The Eduroam cookbook provides some configs that appear to be helpful. But unfortunately they’re so broken I can’t even put them in my configuration.
You can define concordia.ca as a LOCAL realm. realm concordia.ca { } That means it won't get proxied. The rest of the realms look OK. You shouldn't need much in the way of complex "if" statements. Once you define the realms correctly, it should work: * concordia.ca -> local * no realm -> local * default -> eduroam proxying Alan DeKok.
Thanks to everyone for the pointers. I'm just wondering, but is there an issue for my local "concordia.ca" realm because sometimes it's local and sometimes it is coming from Eduroam? I've seen many configs where realms are given secrets, which seems somewhat strange to me because I imagined that a secret would be part of a client configuration and not necessarily a realm? -- Nathan Van Fleet
-----Original Message----- From: freeradius-users- bounces+nmcdavit=alcor.concordia.ca@lists.freeradius.org [mailto:freeradius-users- bounces+nmcdavit=alcor.concordia.ca@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, February 18, 2011 4:09 AM To: FreeRadius users mailing list Subject: Re: Eduroam with a Local Radius Config?
Nathan McDavit-Van Fleet wrote:
I won’t show the pool config for the “DEFAULT” realm. But suffice to say that’s working. Also, our legacy users who are authenticating with no realm are working as well. What isn’t working are local connections using our local real (user@concordia.ca) and distant AAA requests from Eduroam. The Eduroam cookbook provides some configs that appear to be helpful. But unfortunately they’re so broken I can’t even put them in my configuration.
You can define concordia.ca as a LOCAL realm.
realm concordia.ca { }
That means it won't get proxied.
The rest of the realms look OK. You shouldn't need much in the way of complex "if" statements. Once you define the realms correctly, it should work:
* concordia.ca -> local * no realm -> local * default -> eduroam proxying
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 18/02/11 14:02, Nathan McDavit-Van Fleet wrote:
Thanks to everyone for the pointers.
I'm just wondering, but is there an issue for my local "concordia.ca" realm because sometimes it's local and sometimes it is coming from Eduroam?
Eduroam logically consists of two separate functions: 1. "Home" site. This is where your users are somewhere else, and authentication is inbound from eduroam. 2. "Visited" site. This is where other users are at your site, and you are sending their authentication outbound. These can, and should, be implemented as two separate FreeRadius virtual servers. Case #2 has the special situation of your own users using eduroam at your own site (e.g. to test it). You should make sure that you "short-circuit" the request, and authenticate it locally. The link Alan posted contains good examples of doing this.
participants (5)
-
Alan Buxey -
Alan DeKok -
Alexander Clouter -
Nathan McDavit-Van Fleet -
Phil Mayers