Alternate proxying methods.

[Alan DeKok]

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 %{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.

> 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