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.54. <AuthBy ROUNDROBIN>, <AuthBy VOLUMEBALANCE>, <AuthBy LOADBALANCE>, <AuthBy HASHBALANCE>, <AuthBy EAPBALANCE>.

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.71. <AuthBy RADSEC>, Section 3.120. <ServerRADSEC>, and Section 16. RadSec (RFC 6614).

Tip

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

<AuthBy
                        VOLUMEBALANCE>

or

<AuthBy
                        LOADBALANCE>

instead of

<AuthBy
                        RADIUS>

. For more information, see Section 3.54. <AuthBy ROUNDROBIN>, <AuthBy VOLUMEBALANCE>, <AuthBy LOADBALANCE>, <AuthBy HASHBALANCE>, <AuthBy EAPBALANCE>.

Tip

You can specify your remote RADIUS hosts either with Host parameters or <Host xxxxxx> clauses. For more information, see Section 3.42.2. Host and Section 3.43. <Host xxxxxx> within <AuthBy RADIUS>. 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. <AuthBy xxxxxx>.

3.42.1. Failure algorithm

AuthBy RADIUS implements a configurable algorithm to detect failed RADIUS hosts, and to temporarily disregard failed hosts. The algorithm uses the MaxFailedRequests, MaxFailedGraceTime and FailureBackoffTime parameters to customise the operation of the algorithm. It also uses KeepaliveTimeout and UseStatusServerForFailureDetect in order to use only Status-Server requests for failure detection, instead of any request.

AuthBy RADIUS initially assumes that each Host is not failed. After a request is sent to a RADIUS server, if no reply is received after the ReplyTimeout, it is reset up to Retries times. If there is still no reply, that request is deemed to have failed for that Host. AuthBy RADIUS keeps track of how many consecutive requests failed for each Host since the last time a reply was heard from that Host. If more than MaxFailedRequests consecutive requests are deemed to have failed within MaxFailedGraceTime seconds of that last reply heard from that Host, that Host is deemed to have failed.

When the Host is deemed to be failed, AuthBy RADIUS will not attempt to send any requests to it until FailureBackoffTime seconds have elapsed. It will also skip sending requests to that host, and will instead attempt to send to the next Host in its list of Hosts (if any).

The default values for these parameters are:

Retries 3
RetryTimeout 5
MaxFailedRequests 1
MaxFailedGraceTime 0
FailureBackoffTime 0

These values mean that by default AuthBy RADIUS will declare the Host failed after a 3 retries packet transmission failure, but that it will always try to transmit the next request to the Host. This means that AuthBy RADIUS will always try to send every request to the first Host, and if nothing is heard from that Host within (Retries * Retry-Timeout) seconds, it will attempt to send to the next Host.

Tip

Judicious use of these parameters allows you to implement a RADIUS Host fallback policy, where if one RADIUS Host fails to respond to requests, then it will automatically temporarily fall back to the next RADIUS Host and so on.

3.42.2. Host

This parameter specifies the host names where the destination RADIUS server is running. It can be either a DNS name or an IP address. Multiple comma-separated host names can be specified in one Host parameter, or you can use multiple Host lines. Radiator tries up to Retries times to contact each host that you specify. If no response it heard it tries the next host in the list and so on until a reply is received or the list is exhausted. The Host name can contain special formatting characters, which are resolved at startup.

Tip

If the DNS name for any Host resolves to multiple IP addresses, Radiator forwards to those addresses in a round-robin fashion. DNS names are resolved at startup time.

# Send all requests for this realm to 198.51.100.2, if no reply
# try the secondary at 198.51.100.3, if no reply from that, 
# try all the addresses that radiushosts.example.com resolves to
# in round-robin fashion.
Host 198.51.100.2,198.51.100.3
Host radiushosts.example.com

Tip

For greater flexibility, you can also specify the hosts with the

<Host
                        xxxxxx>

clause, which allows you to customise details for each host. For more information, see Section 3.43. <Host xxxxxx> within <AuthBy RADIUS>.

# These are equivalent to the lines in the example above:
<Host 198.51.100.2>
      # Put host-specific values for Secret, ports, 
      # retries etc. in here
</Host>
<Host 198.51.100.3>
</Host>
<Host radiushosts.example.com>
</Host>

Tip

In order to proxy to an IPv6 address, the first IPv6 address listed in LocalAddress is used as the source address. If LocalAddress does not contain any IPv6 address, then the default IPv6 source address for that host is used. A LocalAddress of '::' is equivalent to a locally allocated IPv6 address.

<AuthBy RADIUS>
      # send via IPv6. Packets will appear to come from 
      # the default IPv6 source address for this host
      LocalAddress ::
      Host 2001:db8:100:f101::1
      Secret xxxxxx
      .....
</AuthBy>

Tip

IPv6 addresses are not required to be prefixed with 'ipv6:' with Radiator 4.13 or later.

3.42.3. Secret

The default value of the secret we share with the destination radius servers. Radiator acts like a RADIUS client when it forwards RADIUS request to another RADIUS server.

You must define a shared secret for each Host in AuthBy RADIUS, and it must match the secret configured into the destination RADIUS server. There is no default. The secret can be any number of ASCII characters. Any ASCII character except newline is permitted, but it might be easier if you restrict yourself to the printable characters. For a reasonable level of security, the Secret should be at least 16 characters, and a mixture of upper and lower case, digits and punctuation. You should not use just a single recognisable word. Can be overridden for an individual host inside its Host clause.

# This better agree with the server at
# eric.open.com.au or they wont understand us
<AuthBy RADIUS>
      Host eric.open.com.au
      Secret 666obaFGkmRNs666
</AuthBy>

CAUTION

Some NASs, notably Enterasys Smart Switch Routers support a maximum shared secret length of 16 characters.

3.42.4. AuthPort

Specifies the default UDP port on the destination Hosts to which Radiator will send authentication requests. The argument may be either a numeric port number or an alphanumeric service name as specified in /etc/services (or its moral equivalent on your system). The default port is 1645. Note that the officially assigned port number for RADIUS accounting has been changed to 1812. AuthPort may contain special formatting characters. Can be overridden for an individual host inside its Host clause.

# Send authentication to port 1812 on the remote server
AuthPort 1812

3.42.5. AcctPort

Specifies the default UDP port on the destination Hosts to which Radiator will send accounting requests. The argument may be either a numeric port number or an alphanumeric service name as specified in /etc/services (or its moral equivalent on your system). The default port is 1646. Note that the officially assigned port number for RADIUS accounting has been changed to 1813. AcctPort may contain special formatting characters. Can be overridden for an individual host inside its Host clause.

# Send accounting to port 1813 on the remote server
AcctPort 1813

3.42.6. OutPort

If this optional parameter is set, it forces a particular port number to be used for the forwarding port. Therefore if you have, for example:

OutPort 1001

Then all requests forwarded will appear to come from port 1001 on this Radiator host. This can be useful for implementing strict firewall rules. The argument may be either a numeric port number or an alphanumeric service name as specified in /etc/services (or its moral equivalent on your system). The default is to use a port number determined by your operating system, which will typically be different every time you restart your Radiator. OutPort may contain special formatting characters. A typical use of special formatting characters is with GlobalVar and command line arguments.

Tip

Many operating systems require root or administrator privileges to use a socket with a port number less than 1024.

3.42.7. Retries

If Radiator does not get a reply from the RADIUS server within defined time, it retransmits the request up to this number of retries. The default value is 3, which means maximum of 4 transmissions. This can be overridden for an individual host inside its Host clause.

Here is an example of using Retries:

# It is a poor link, so lots of retries
Retries 10

3.42.8. RetryTimeout

Specifies the default number of seconds to wait for a reply before retransmitting. The default is 5 seconds, which is a common value for most RADIUS clients. If the destination RADIUS server is at the end of a distant or saturated link, you may want to set this to 10 or 20 seconds. Can be overridden for an individual host inside its Host clause.

# It is a poor link, wait 15 seconds before retransmission
RetryTimeout 15

3.42.9. KeepaliveTimeout

This optional integer specifies the maximum time in seconds that a RADIUS connection can be idle before a Status-Server request is sent. The default value is 0 and keepalives are not used. When UseStatusServerForFailureDetect is enabled, KeepaliveTimeout together with MaxFailedRequests and other related parameters defines the minimum time it takes to notice the next hop has failed.

3.42.10. KeepaliveNoreplyTimeout

This is an optional integer that specifies the waiting time, in seconds, for a Status-Server request. If no reply is received within the time KeepaliveNoreplyTimeout defines, the Status-Server request is marked as lost.

If KeepaliveNoreplyTimeout is not defined, the waiting time value depends on the AuthBy you are using:

<AuthBy RADCSEC>: NoreplyTimeout value is used instead.
<AuthBy RADIUS>: RetryTimeout value is used instead.

It is recommended to have a smaller value for KeepaliveNoreplyTimeout and a larger value for NoreplyTimeout or RetryTimeout. The Status-Server responder is always the next hop host and a reply is received quickly. With a short KeepaliveNoreplyTimeout, a possible failure situation is discovered quickly and the request is rerouted to another server. The final destination of an Access-Request or an Accounting-Request message may be located many hops away and for this reason a long NoreplyTimeout may be needed.

Here is an example of using both KeepaliveNoreplyTimeout and NoreplyTimeout in

<AuthBy
                     RADSEC>

:

<AuthBy RADSEC>
      NoreplyTimeout 10
      KeepaliveNoreplyTimeout 3
</AuthBy>

To use this example with <AuthBy RADIUS>, you must use RetryTimeout instead of NoreplyTimeout.

3.42.11. KeepaliveRequestType

This string defines the type of RADIUS request that is sent as a keep-alive request. Any RADIUS request type is allowed. The default value is Status-Server.

Here is an example of using KeepaliveRequestType with AddToKeepaliveRequest:

# Send Access-Request as keepalive probe
KeepaliveRequestType Access-Request
AddToKeepaliveRequest User-Name=mikem,User-Password=fred

3.42.12. AddToKeepaliveRequest

This string adds attributes to the keep-alive request before sending it to Host. The value is a comma-separated list of attribute value pairs on one line, exactly as for any reply item. Special formatting characters are allowed, for more information, see Section 3.3. Special formatters.

Here is an example of using AddToKeepaliveRequest with KeepaliveRequestType:

# Send Access-Request as keepalive probe
KeepaliveRequestType Access-Request
AddToKeepaliveRequest User-Name=mikem,User-Password=fred

3.42.13. UseStatusServerForFailureDetect

If this optional flag is enabled, use only Status-Server requests (if any) to determine that the target server is failed when there is no reply. If this is not enabled, use no-reply to any type of request. This parameter uses NoreplyTimeout, MaxFailedRequests, and MaxFailedGraceTime during failure detection. This is not enabled by default.

FailureBackoffTime has no effect when UseStatusServerForFailureDetect is enabled. Once a Host has been marked as failed, it remains marked as failed until a reply is received from it (typically in response to a subsequent Status-Server request).

If you enable this, ensure that KeepaliveTimeout is set to a sensible interval to balance between detecting failures early and loading the target server.

3.42.14. FailureBackoffTime

This optional parameter specifies for how long time a failed remote server is removed from the forwarding list and marked as failed. The number of retries is defined by MaxFailedRequests. If no reply is received when all retries are used, the host is marked as failed and no requests are sent to it. After FailureBackoffTime time has expired, the Host is again eligible for forwarding. The unit is seconds, and the default value is 0, which means that the host is always regarded as working.

3.42.15. MaxFailedRequests

This optional parameter specifies how many requests must fail to receive a reply before the remote radius server is marked as failed, and the FailureBackoffTime will be applied. The default is 1, which means that one ignored request will cause the Host to be marked as failed for FailureBackoffTime seconds.

3.42.16. MaxFailedGraceTime

This optional parameter specifies the time period in seconds over which MaxFailedRequests failures cause the target host to be assumed to be failed. The default value is 0. After a host is declared to be failed, no request are forwarded to it until FailureBackoffTime seconds have elapsed. The default value lets the AuthBy to choose a reasonable value which is typically very large. Very short values require a high number of failures to set target host as failed. This value should only be changed in special cases.

3.42.17. MaxTargetHosts

This parameter limits the number of different hosts a request is proxied to in the case of no reply. The default value is 0, which means there is no limit. If Radiator does not receive a reply from a host, it keeps trying until all hosts are exhausted.

3.42.18. StripFromRequest

Strips the named attributes from the request before forwarding it to any Host. The value is a comma separated list of attribute names. StripFromRequest removes attributes from the request before AddToRequest adds any to the request. There is no default.

# Remove any NAS-IP-Address,NAS-Port attributes
StripFromRequest NAS-IP-Address,NAS-Port

3.42.19. AddToRequest

Adds attributes to the request before forwarding to any Host. Value is a list of comma separated attribute value pairs all on one line, exactly as for any reply item. StripFromRequest removes attributes from the request before AddToRequest adds any to the request. You can use any of the special % formats in the attribute values. There is no default.

# Append a Filter-ID and host name
AddToRequest Calling-Station-Id=1,Login-IP-Host=%h

3.42.20. AddToRequestIfNotExist

Adds attributes to the request before forwarding to any Host. Unlike AddToRequest, an attribute will only be added if it does not already exist in the request. Value is a list of comma separated attribute value pairs. You can use any of the special % formats in the attribute values. There is no default.

# Possibly add our default Operator-Name
AddToRequestIfNotExist Operator-Name=1example.com

3.42.21. RequireMessageAuthenticator

AuthBy RADIUS clause checks the value of any Message-Authenticator attribute in incoming EAP or other replies. An incorrect authenticator causes the request to be ignored.

The optional RequireMessageAuthenticator flag causes the clause to require a correct Message-Authenticator attribute to be present in all incoming replies that support Message-Authenticator attribute. Most of the message types support Message-Authenticator. Accounting requests and responses do not support Message-Authenticator.

3.42.22. NoForwardAuthentication

Stops AuthBy RADIUS forwarding Authentication-Requests. They are ACCEPTED, but no further action is taken with them. This is different in meaning to IgnoreAuthentication, which IGNOREs them.

# Just ACCEPT Authentication-Requests, do not forward them
NoForwardAuthentication

3.42.23. NoForwardAccounting

Stops AuthBy RADIUS forwarding Accounting-Requests. They are ACCEPTED, but no further action is taken with them. This is different in meaning to IgnoreAccounting, which IGNOREs them.

# Just ACCEPT Accounting-Requests, do not forward them
NoForwardAccounting

3.42.24. HandleAcctStatusTypes

This optional parameter specifies a list of Acct-Status-Type attribute values that will be processed in Accounting requests. The value is a comma-separated list of valid Acct-Status-Type attribute values including, Start, Stop, Alive, Modem-Start, Modem-Stop, Cancel, Accounting-On and Accounting-Off. See your dictionary for a full list.

If HandleAcctStatusTypes is specified and an Accounting request has an Acct-Status-Type not mentioned in HandleAcctStatusTypes, then the request will be ACCEPTed but not otherwise processed by the enclosing clause. The default is to handle all Acct-Status-Type values.

# Only process Start and Stop requests, ACCEPT and acknowledge everything else
HandleAcctStatusTypes Start,Stop

3.42.25. LocalAddress

This optional parameter specifies the local address(es) to bind the proxy forwarding socket. This in turn specifies what the IP source address will be in forwarded requests. Defaults to BindAddress (which defaults to 0.0.0.0, i.e. the default source address). If no appropriate IPv4 or IPv6 address is found in LocalAddress, the default IPv4 or IPv6 source address for the host will be used. This parameter is usually only useful for multi-homed hosts. If you do not understand what this is for, do not set it: the default behaviour is fine for most situations. If BindAddress or LocalAddress are set to multiple comma separated addresses, only the first IPv4 or IPv6 address (as appropriate) will be used for outgoing IPv4 or IPv6 addresses.

Tip

IPv6 addresses are not required to be prefixed with 'ipv6:' with Radiator 4.13 or later.

# We are multi-homed, bind the proxy port so forwarded requests
# appear to come from 203.53.154.27
LocalAddress 203.53.154.27

Tip

You can make forwarded IPv4 requests appear to come from one address, and IPv6 requests appear to come from a different address. In this example, requests will usually be forwarded to 2002:721:1500:1::a101, and will have a source address of 2001:720:1500:1::a100. If 2002:721:1500:1::a101 does not reply, then requests will be forwarded to 210.1.1.5 with a source address of 203.63.154.27.

LocalAddress 203.63.154.27,2001:720:1500:1::a100
Host 2002:721:1500:1::a101
Host 210.1.1.5

Note

AuthBy RADIUS will create and use a separate UDP network socket for each distinct source address used from the LocalAddress list.

3.42.26. ReplyHook

This optional parameter allows you to define a Perl function that will be called after a reply is received from the remote RADIUS server and before it is relayed back to the original client. The following arguments are passed in the following order:

Reference to the reply received from the remote RADIUS server
Reference to the reply packet being constructed for return to the NAS
Reference to the original request from the NAS
Reference to the request that was sent to the remote RADIUS server
Reference to the Radius::Host structure for the remote host
Reference to the redirected flag. If redirected is set by the hook, the ReplyHook has redirected the request to another AuthBy.

The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code will be reported to the log file at start-up time. Runtime errors in your hook will also be reported to the log file when your hook executes. Multiline hooks (i.e. with trailing backslashes (\)) are parsed by Radiator into one long line. Therefore you should not use trailing comments in your hook.

The response type can be enforced when needed. For example, when the remote RADIUS server has rejected the request, the ReplyHook can do any local processing required for rejects and then change the response type to accept.

# Change RadiusResult in the 3rd argument, the original request
ReplyHook sub { ${$_[2]}->{RadiusResult} = $main::ACCEPT; }

ReplyHook Can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things.

# Fake a new attribute into the reply going back to the client
ReplyHook sub { ${$_[1]}->add_attr('test-attr', \
      'test-value');}

3.42.27. NoReplyHook

This optional parameter allows you to define a Perl function that will be called if no reply is received from any remote RADIUS server. A reference to the original request received from the NAS is passed as the first argument. A reference to the request that was forwarded to the remote RADIUS server is passed as the second argument. A reference to the reply packet being constructed for return to the NAS is passed as the third argument (note that the normal behaviour in case of no reply, is for no reply to be sent to the NAS).

The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code will be reported to the log file at start-up time. Runtime errors in your hook will also be reported to the log file when your hook executes. Multiline hooks (i.e. with trailing backslashes (\)) are parsed by Radiator into one long line. Therefore you should not use trailing comments in your hook.

NoReplyHook can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things.

# Call an AuthBy SQL to handle accounting that
# failed to get to the remote server
NoReplyHook sub { Radius::AuthGeneric::find('SQL')\
      ->handle_request(${$_[0]}, ${$_[2]});}

Tip

See NoReplyReject parameter in case you need to return a reject back to the NAS. Setting this parameter may be quicker than creating a hook to trigger a reject.

3.42.28. ForwardHook

This is a Perl hook that is called once for each request before the request is forwarded to a remote RADIUS or RadSec server. It allows you to modify the forwarded request without changing the current one. ForwardHook receives the following arguments:

Current request
Forwarded request

Here is an example of using ForwardHook:

ForwardHook sub { my $p = $_[0]; my $fp = $_[1]; \
                  $fp->add_attr('OSC-AVPAIR', 'Added by ForwardHook'); }

3.42.29. ReplyTimeoutHook

This optional parameter allows you to define a Perl function that will be called if no reply is received from the currently tried remote RADIUS server. A reference to the original request received from the NAS is passed as the first argument. A reference to the request that was forwarded to the remote RADIUS server is passed as the second argument.

3.42.30. IgnoreReject

This optional parameter causes Radiator to ignore (i.e. not send back to the original NAS) any Access-Reject messages received from the remote RADIUS server. This is sometimes useful for authenticating from multiple RADIUS servers. However, you should note that if all the remote radius servers reject the request, then the NAS will receive no reply at all.

# If we get a reject from the remote, do not send it to the NAS
IgnoreReject

3.42.31. NoReplyReject

This is an optional flag parameter. When this parameter is set, it forces <AuthBy RADIUS> and its subclasses to return with result REJECT to trigger an Access-Reject when a proxied request times out. This parameter is not set by default.

When NoReplyReject is enabled, the reject reason is set to 'Upstream timeout'.

# Trigger an Access-Reject back to the NAS
NoReplyReject

Tip

NoReplyReject allows rejecting timed out requests without hooks such as NoReplyHook. For more information, see Section 3.42.27. NoReplyHook

3.42.32. Asynchronous

The default behaviour for

<AuthBy
                     RADIUS>

is to return IGNORE as soon as the request has been forwarded to the remote RADIUS server. It does not wait for a reply before moving on to other AuthBy classes, or handling new requests. You can change this behaviour with the Asynchronous flag. This flag is recommended for all new configurations.

When you enable the Asynchronous flag, Handler continues to evaluate its AuthBy policy after a reply or timeout from the remote proxy. Other requests are processed while the reply is pending. Asynchronous is supported by

<AuthBy
                     RADIUS>

and its subclasses.

For more information about how proxied requests are waited for by Radiator, see Section 3.42. <AuthBy RADIUS> and Section 3.42.33. Synchronous.

# Auth to server1 and continue to AuthBy FILE if server 1 accepts.
# Process other requests while the reply from server 1 is pending.
<Handler>
      AuthByPolicy ContinueWhileAccept
      <AuthBy RADIUS>
            # Evaluate the policy when we get a reply or a timeout
            Asynchronous
            Host server1
            Secret xxxxxx
      </AuthBy>
      <AuthBy FILE>
            Filename %D/users
      </AuthBy>
</Handler>

3.42.33. Synchronous

The default behaviour for

<AuthBy
                     RADIUS>

is to return IGNORE as soon as the request has been forwarded to the remote RADIUS server. It will not wait for a reply before moving on to other AuthBy classes, or handling new requests. You can change this behaviour with the Synchronous flag, but make sure you understand what you are doing before enabling the Synchronous flag.

If you enable the Synchronous flag, Radiator will wait for either a reply, or a timeout from the remote radius server before processing any following AuthBy clauses, or before handling any further requests. This means that handling requests will stop until a reply is received or the reply times out (which might take 15 seconds or more, depending on the settings of your RetryTimeout and retries parameters). This can seriously affect the performance of your RADIUS server, especially if the remote radius server is slow, stopped, or at the end of a slow or unreliable link. You should therefore be very cautious about setting this flag, and you should understand the consequences of remote server failure. The performance impact of the Synchronous flag can be alleviated by use of the Fork parameter (see Section 3.32.42. Fork) at the cost of significant increase in memory requirements.

Nevertheless, Synchronous can be very handy if you wish, for example, to forward a request to remote server only if another server REJECTS the request. See the example below for sample configuration.

# Auth to server2 only if server 1 rejects. Caution: 
# accounting will normally go to server1, unless it rejects
<Realm xxxxxx>
      AuthByPolicy ContinueWhileReject
      <AuthBy RADIUS>
            # Wait here until we get a reply or a timeout
            Synchronous
            Host server1
            Secret xxxxxx
      </AuthBy>
      <AuthBy RADIUS>
            Host server2
            Secret yyy
      </AuthBy>
</Realm>

3.42.34. UseExtendedIds

This optional flag can be used to work around various problem that might arise with remote RADIUS servers in some circumstances.

In the standard RADIUS protocol;, the packet identifier is only 8 bits (0 to 255), which means that a RADIUS server can only have 256 requests pending from a given client at any time. This flag forces AuthBy RADIUS to use a much larger range of identifiers (at least 32 bits) carried in the Proxy-State attribute, meaning that many more requests can be pending at a given time, and that replies from a remote RADIUS server are more accurately matched to their original requests.

One such problem is flooding of remote servers by large number of new requests occurring at the same time, such as after a power failure in a large part of the city, resulting in lots of requests being proxied all at the same time.

Another problem is in the case of some types of remote server which do not send their replies from the same port and address to which they were sent.

Tip

The correct operation of this parameter requires that the remote RADIUS server honours the Proxy-State attribute correctly by replying it back to the sender exactly as it was sent. Most modern RADIUS server (including Radiator) behave correctly in this respect.

3.42.35. UseOldAscendPasswords

Attention

Deprecated. See Section 3.42.34. UseExtendedIds instead.

This optional parameter tells Radiator to encode all passwords sent by this AuthBy using the old style (non RFC compliant) method that Ascend used to use on some NASs. The symptom that might indicate a need for this parameter is that passwords longer than 16 characters are not decoded properly. Can be overridden for an individual host inside its Host clause.

3.42.36. ServerHasBrokenPortNumbers

Attention

Deprecated. See Section 3.42.34. UseExtendedIds instead.

Some RADIUS servers (GoRemote (GRIC) on NT in particular) exhibit broken behaviour in that the reply does not come from the same UDP port that the request was sent to! This broken behaviour would normally cause Radiator to ignore replies from such broken servers. The optional ServerHasBrokenPortNumbers flag will permit interoperation with such broken servers. Can be overridden for an individual host inside its Host clause.

CAUTION

Enabling this for two remote servers at the same host will cause difficult to trace problems.

# We are proxying to a GRIC server on NT
ServerHasBrokenPortNumbers

3.42.37. ServerHasBrokenAddresses

Some RADIUS servers (some rare accounting proxies) exhibit broken behaviour in that the reply does not come from the same address that the request was sent to! This broken behaviour would normally cause Radiator to ignore replies from such broken servers. The optional ServerHasBrokenAddresses flag will permit interoperation with such broken servers. Can be overridden for an individual host inside its Host clause.

WARNING

Enabling this for _two_ remote servers at the same host will cause difficult to trace problems.

ServerHasBrokenAddresses

3.42.38. CachePasswords

This parameter enables a user password cache in this AuthBy RADIUS. It allows proxying to be more robust when the remote server is not available. It can be very useful if the remote server is unreliable, or at the end of a slow, saturated or unreliable link. The exact behaviour of when the password cache is consulted is controlled by the CacheOnNoReply parameter.

Tip

Use of this parameter with a large user population can cause large amounts of memory use by the Radiator process.

Tip

If Radiator is restarted, the password cache is lost.

Note

Matching of cached passwords can never succeed for CHAP or MS-CHAP authentication requests.

3.42.39. CacheOnNoReply

This flag controls when the password cache created by the CachePasswords parameter is consulted.

If CacheOnNoReply is set (the default), then the Access-Request will always be proxied to the remote RADIUS server, and password cache will only be consulted if there is no reply from of any of the remote RADIUS servers. If no reply is received from any of the remote RADIUS servers, and If there is a cached reply that matches the password and has not exceeded the CachePasswordExpiry time limit, then the request will be accepted.

If CacheOnNoReply is not set, then the password cache will consulted before proxying. If there is a cached reply that matches the password and has not exceeded the CachePasswordExpiry time limit, then the request will be accepted immediately without being proxied to any remote RADIUS server.

3.42.40. IgnoreReplySignature

Deprecated. Normally, if a reply from a remote RADIUS server is received with a bad authenticator, the reply will be logged and then ignored. This optional parameter tells AuthBy RADIUS to ignore incorrect signatures in replies from remote RADIUS servers. Some RADIUS servers implement incorrect signature algorithms, and this flag will prevent problems when interoperating with such servers. Can be overridden for an individual host inside its Host clause.

CAUTION

Use of this flag can cause incorrect handling of replies in unusual circumstances.

You know you need this flag if you see an error like this, even when you are sure the shared secret for the RADIUS server is correct.

"Bad authenticator received in reply ....."

3.42.41. IgnoreAccountingResponse

This optional flag causes AuthBy RADIUS to ignore replies to accounting requests, instead of forwarding them back to the originating host. This can be used in conjunction with the AccountingHandled flag in a Handler or Realm (see Section 3.31.6. AccountingHandled) to ensure that every proxied accounting request is replied to immediately, and the eventual reply from the remote RADIUS server is dropped.

3.42.42. AcctFailedLogFileName

The name of a files used to log failed Accounting-Request messages in the standard radius accounting log format. If no reply is ever received from any of the remote hosts, the accounting message is logged to the named file. For more information about log file format, see Section 9.5. Accounting log file. If no AcctFailedLogFileName is defined, failed accounting messages are not logged. The default is no logging. The file name can include special formatting characters as described in Section 3.3. Special formatters, which means that, for example, using the %c specifier, you can maintain separate accounting log files for each Client. The AcctFailedLogFileName file is always opened, written and closed for each failure, so you can safely rotate it at any time.

The user name that is recorded in the log file is the rewritten user name when RewriteUsername is enabled.

Tip

You can change the logging format with AcctLogFileFormat.

Tip

You may want to make the filename depend on the date, so you get one missed accounting file per day.

# Log all accounting to a single log file in LogDir
AcctFailedLogFileName %L/misseddetails

3.42.43. AcctLogFileFormat

This optional parameter is used to alter the format of the failed accounting log file from the standard radius format when AcctLogFileFormatHook is not defined. AcctLogFileFormat is a string containing special formatting characters. It specifies the format for each line to be printed to the accounting log file. A new line is automatically appended. It is most useful if you use the %{attribute} style of formatting characters (to print the value of the attributes in the current packet.

AcctLogFileFormat %{Timestamp} %{Acct-Session-Id}\
%{User-Name}

3.42.44. AcctLogFileFormatHook

This specifies an optional Perl hook that is used to alter the format of the failed accounting log file from the standard radius format when defined. The hook must return the formatted accounting record. A new line is automatically appended. By default no hook is defined and AcctLogFileFormat or the default format is used. The hook parameter is the reference to the current request.

3.42.45. AccountingStartsOnly

If this parameter is defined, it forces AuthBy RADIUS to only forward Accounting Start requests. All other Accounting requests are accepted and acknowledged, but are not forwarded.

Tip

It does not make sense to set AccountingStartsOnly and AccountingStopsOnly.

3.42.46. AccountingAlivesOnly

If this parameter is defined, it forces AuthBy RADIUS to only forward Accounting Alive requests. All other Accounting requests are accepted and acknowledged, but are not forwarded.

3.42.47. AccountingStopsOnly

If this parameter is defined, it forces AuthBy RADIUS to only forward Accounting Stop requests. All other Accounting requests are accepted and acknowledged, but are not forwarded.

You may want to use this parameter if your accounting system does not use or need Accounting Start to do its billing.

# We only want to forward Stops
AccountingStopsOnly

Tip

It does not make sense to set AccountingStartsOnly and AccountingStopsOnly.

3.42.48. ClearTextTunnelPassword

This optional parameter prevents Radiator decrypting and re-encrypting Tunnel-Password attributes in replies during proxying. This is provided in order to support older NASs that do not support encrypted Tunnel-Password.

3.42.49. AllowInRequest

This optional parameter specifies a list of attribute names that are permitted in forwarded requests. Attributes whose names do not appear in this list will be stripped from the request before forwarding.

# Strip everything except username and password
AllowInRequest User-Name,User-Password

3.42.50. DisableMTUDiscovery

If this optional parameter is set, it disables MTU discovery on platforms that support that behaviour (currently Linux only). This can be used to prevent discarding of certain large RADIUS packet fragments on supporting operating systems.

3.42.51. Gossip

The Gossip flag parameter enables this AuthBy to send and listen for notifications (aka. gossip) to/from other Radiator servers when any remote Radius server fails to reply. This is disabled by default.

See Section 3.133. <GossipRedis> for more about the Gossip framework and goodies/farmsize.cfg for a configuration sample.

# Use the configured Gossip implementation for notifications
Gossip

3.42.52. NoKeepaliveTimeoutForChildInstances

If this optional flag is enabled, only the first instance of this server farm will send Status-Server requests. Recommended when Gossip is used to distribute reachability information. This is not set by default.

3.42.53. GossipNoReply

If the GossipNoReply flag parameter is set, then a notification is sent when a remote Radius server fails to reply. Radiator server also increases a counter for failed requests when a notification is received. This is enabled by default.

3.42.54. GossipHostDown

If the GossipHostDown flag parameter is set, then a notification is sent when a remote Radius server is marked down. Radiator server also marks the remote Radius server down when a notification is received. This is enabled by default.

3.42.55. GossipHostUp

If the GossipHostUp flag parameter is set, then a notification will be send when a remote Radius server is marked up and alive again. Radiator server also marks the remote Radius server healthy when a notification is received. This is enabled by default.