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 [EMAIL PROTECTED] >> 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html