Alan DeKok wrote:
Arran Cudbard-Bell wrote:
The obvious solution is to actually direct users at a realm, instead of relying on DEFAULT entries... But as soon as a user hits the rlm_realm they will be proxied...
Only if you define "authhost" and "accthost". If those don't exist (or are set to LOCAL), then the realm will be recognized, but the request will not be proxied.
Yes well in my case there would be realms defined, one for JRS and one secondary RADIUS servers.
The solution I found is to ignore the standard front end for rlm_realm, and instead use the Proxy-To-Realm and Replicate-To-Realm in the users file.
Replicate-To-Realm does something? I don't think so. It's not referenced in the source anywhere.
Oh... damn I saw someone had submitted a patch for it a long time ago during my google searching, and had assumed it had been included.
# Shorthand sussex DEFAULT Pre-Proxy-Realm =~ ".*susx.ac.uk.*", Auth-Type := Reject Reply-Message = "Please use %{Stripped-User-Name}@sussex.ac.uk as your user ID", Fall-Through = no
It's probably time for a "regex map", like Postfix has. That would simplify this configuration quite a bit.
Yeah that would be nice, make this kind of stuff much neater , especially if your checking for loads of Regexp based conditions.
Just thought it was quite a neat way or doing it, as opposed to all the weirdness with prefixes and suffixes and using rlm_realm in the authorize and accounting section.
The realm module is there to handle the people who need it's functionality. :)
Bless their little cotton socks.
Also heard talk to deprecating Proxy-To-Realm and Replicate-To-Realm... which is a really bad idea as using Proxy-To-Realm and Replicate-To-Realm is far more powerful , and can be configured from sql :)
Replicate-To-Realm doesn't do anything... Proxy-To-Realm is useful, but wrong. Let me explain.
RADIUS proxies send packets to RADIUS servers... not to realms. So the simplest way to set proxying is "proxy to server X". Note that there's no mention of a realm.
But we also want fail-over and load-balancing. So in 2.0, we have the concept of "server pools", which aggregate many RADIUS servers into one pool. The pool is then treated as one logical server. So we can also set "proxy to server pool Y". Note that there's no mention of a realm.
Finally, servers and/or pools often handle realms. So it's useful to say that "this realm is handled by server X, or server pool Y". It's also useful to say "proxy the request to the server/pool that handles realm FOO." That is a logical abstraction that simplifies the administrators thinking. It's a layer of indirection that means he can work conceptually with what the user types in (name + realm), and what he sees in the packet (name + realm), rather than dealing with the details of the protocol.
Historically, FreeRADIUS did not have home_servers or server_pools. They were shoved into realms, which was wrong. But it's what we had, which is where the confusion between realms & pools & servers comes from.
So... Replicate-To-Realm doesn't work. I'd be curious to know what it does for you.
Well obviously nothing :( , I hadn't got around to testing it yet I just assumed it would as acct_users didn't have any parsing errors thrown. But that would be because it's defined as attribute 1049 in dictionary.freeradius.internal ATTRIBUTE Replicate-To-Realm 1049 string Damn.. Well obviously someone wanted to implement it once, but never got round to it *sigh*. I had assumed that it would copy the incoming packet to the realm specified but also continue processing locally. This would really only be of use for accounting packets.
Proxy-To-Realm won't be going away, it's still useful. But Proxy-To-Server-Pool && Proxy-To-Home-Server are useful, too. Once we have those, Proxy-To-Realm becomes "look up realm, find auth/acct server, and then use that for Proxy-To-Server-Pool".
Yes so the actual function is fine, it's just the terminology. A more accurate name might be 'Assign-To-Realm', and then once it's been 'assigned' the internet logic of the realm will decide where it's actually proxied to. Well thanks for explaining all that, had a pretty good idea of what was happening, but you helped solidify it. If you do feel like adding replicate-to-realm in.. would be most appreciated :) Thanks, Arran