Alternate proxying methods.

[Arran Cudbard-Bell]

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