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. > 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. ... > # 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. > 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. :) > 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. 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". Hope this helps. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
