Section 3.42. <AuthBy RADIUS>

3.42. <AuthBy RADIUS>

<AuthBy RADIUS> forwards all authentication and accounting requests for this Realm to another (possibly remote) RADIUS server. This is called proxying. When the remote RADIUS server replies, the reply is forwarded back to the client that originally sent the request to the server.

This allows Radiator to act as a proxy RADIUS server, possibly running on the firewall of your organisation. You can also use it to set up roaming realms, or to make your RADIUS server act as a multiplexer for multiple realms. You can forward certain realms to other servers within your organisation in order to improve performance or redundancy.

By specifying multiple Host lines the requests can be forwarded to primary/secondary RADIUS server pairs. The normal behaviour is to try to forward the requests to the remote hosts in the order the hosts are listed in the configuration file. This means that it initially tries to forward a request to the first host listed (unless that host was marked as failed recently). If no reply is received from the first host (after Retries), it is marked as failed for FailureBackoffTime seconds, and the request is forwarded to the next Host in the list. This continues until a reply is received, or until all the hosts are tried. This way, if a primary remote server fails, the secondary takes over. After FailureBackoffTime seconds, the primary is tried again. To change this behaviour, choose other load balancing versions of <AuthBy RADIUS>. For more information, see Section 3.57.

Attention

By default, an <AuthBy RADIUS> clause is completed as soon as the request has been forwarded to the remote RADIUS server. In this case,

<AuthBy
                        RADIUS>

returns IGNORE for AuthByPolicy, so take care when using sequences of AuthBy clauses that include <AuthBy RADIUS>. <AuthBy RADIUS> does not wait for a reply before moving on to other AuthBy clauses, or handling new requests. You can change this behaviour with one of these flag parameters: Asynchronous and Synchronous. Be cautious if you enable the Synchronous flag. It can have a significant impact on performance. If you need to continue processing the reply with another AuthBy clause, the correct way to do that is with a ReplyHook or Asynchronous flag that was added to Radiator 4.17.

Tip

If it is required to proxy RADIUS requests to a remote Radiator across an insecure or unreliable network such as the internet, consider using the RadSec protocol, and use

<AuthBy
                        RADSEC>

instead of

<AuthBy
                        RADIUS>

. RadSec provides encrypted, reliable transport of RADIUS requests to a remote Radiator. For more information, see Section 3.83, Section 3.132, and Section 16.

Tip

Perform load balancing as well as simple proxying by using <AuthBy ROUNDROBIN>,

<AuthBy
                        VOLUMEBALANCE>

<AuthBy
                        LOADBALANCE>

instead of

<AuthBy
                        RADIUS>

. For more information, see Section 3.57.

Tip

You can specify your remote RADIUS hosts either with Host parameters or <Host xxxxxx> clauses. For more information, see Section 3.42.2 and Section 3.43. The Host parameter is simpler but less flexible than the <Host xxxxxx> clause. For ease of understanding, do not mix formats in the same

<AuthBy
                        RADIUS>

Tip

Be cautious when using Fork with <AuthBy RADIUS>. It usually results in requests being sent to the remote host, but the replies not received.

Example

In case it is not obvious from the above, there are 2 ways of specifying which remote RADIUS hosts to proxy to. The simplest, but the least flexible, way is to use Host parameters, and have the same secrets, ports etc. for all hosts:

<AuthBy RADIUS>
      # Same secret and timeout for all hosts
      Secret xyzzy
      RetryTimeout 2
      Host host1.bigco.com
      Host host2.bigco.com
</AuthBy>

Example

The other way allows you to customise some parameters on a host-by-host basis by using Host clauses:

<AuthBy RADIUS>
      # Same secret for all hosts
      Secret xyzzy
      <Host host1.bigco.com>
            # But a custom Timeout for this one
            RetryTimeout 2
      </Host>
      <Host host2.bigco.com>
            # And custom ports for this one
            AuthPort 1001
            AcctPort 1002
      </Host>
</AuthBy>

<AuthBy RADIUS> understands also the same parameters as <AuthBy xxxxxx>. For more information, see Section 3.32.