This Wiki is available to view at but still under maintenance. PLEASE DO NOT EDIT THE WIKI UNTIL FURTHER NOTICE. We are attempting to restore missing edits which took place between Monday 8 and Thursday 11 April 2019, therefore the site is likely to be taken off line at any time. Updated 20:43 CEST 16 April 2019.
Child pages
  • radiator-flr
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

3.1 Common FLRS proxy setups

This section covers the configuration of a Federation RADIUS Proxy server. It presents two different software packages to achieve that goal: the Radiator (http://www.open.com.au/radiator/) RADIUS server and the free software package radsecproxy (http://software.uninett.no/radsecproxy/).
Examples in this chapter can be used as a repository of configuration snippets for building complex proxy servers, or can be used as described for simple proxy relations between one organisation and two top-level servers.

3.1.1    Radiator as federation proxy

3.1.1.1 Common configuration

Radiator expects the configuration to be in file /etc/radiator/radius.cfg
LogDir    /var/log/radiator
DbDir    /usr/share/radiator

LogDir defines the directory in which start-up logs and PID file reside. DbDir defines the path to Radiator's data files, such as dictionaries.

Trace 3 logs will be sent to the system syslog, and Trace 4 logs will be stored in the directory /var/log/arch/radiator/

Here the location of logfiles (referred in the configuration as %L) and databases (%D) can be defined, as well as the amount of log output (with Trace).

The log files will be split on a daily basis.

<Log SYSLOG>
      Facility      local7
      LogIdent   log-syslog      
     Trace        3
</Log><Log FILE>
      Filename   /var/log/arch/radiator/radiator.%Y%m_%d.log_
      LogIdent   log-file     
     Trace        4
</Log>
 
SNMP allows remote monitoring of activity on a RADIUS server with tools such as RADAR from OSC (http://www.open.com.au/radar/index.html), or drawing simple graphs of activity by rgraph from CESNET (http://www.eduroam.cz/rgraph/).

<SNMPAgent>
      ROCommunity xxxxxxxxxxxxxxxxxxxxxxxxx
      Managers        localhost 127.0.0.1
</SNMPAgent>

The ports Radiator will use to listen for Authentication and Accounting requests must be defined. The port numbers 1812 and 1813 were assigned to the RADIUS protocol by IANA. Unfortunately, some RADIUS servers (such as CiscoACS 3.x) are still using the old numbers 1645, 1646. For this reason it is suggested to use both numbers.

AuthPort    1645,1812
AcctPort    1646,1813

It is possible to define own logging formats. We suggest using the following log definition – it generates one single line of log output per authentication, which is very parser-friendly if logs need to be evaluated later:
<AuthLog SYSLOG>
      Identifier                defaultAuthLog
      Facility                   local7
      LogIdent                radiator
      SuccessFormat     _access-accept for %u (User-Name=%

Unknown macro: {Reply}

)_ at
_Proxy=%c (CSID=%

Unknown macro: {Calling-Station-Id}

NAS=%

Unknown macro: {NAS-Identifier}

/%N)_
_EAP=%

Unknown macro: {HexAddress}

_
_      FailureFormat        access-reject for %u (User-Name=%

Unknown macro: {Reply}

) at_
_Proxy=%c (CSID=%

NAS=%

Unknown macro: {NAS-Identifier}

/%N)_
      LogSuccess          1
      LogFailure            1
</AuthLog>

3.1.1.2 Client definition

In the client section all possible peers (the "institutional" and the confederation RADIUS servers) have to be listed and a "secret" has to be assigned to them. As this secret is the only thing that protects the communication between the RADIUS servers from eavesdropping, it must be cryptographically strong and well protected.
<Client localhost>
      Secret         mysecret
      DupInterval 0
</Client>

<Client radius.orgA.tld>
      Secret          xxxxxxxxxxxxxxxxxxxxxxxxx
      Identifier       radius.orgA.tld
</Client>

<Client etlr1.eduroam.org>
      Secret          xxxxxxxxxxxxxxxxxxxxxxxxx
      Identifier       etlr1.eduroam.org
</Client>

<Client etlr2.eduroam.org>
      Secret          xxxxxxxxxxxxxxxxxxxxxxxxx
      Identifier      etlr2.eduroam.org
</Client>

It is necessary to mark each host by a unique identifier, which is later used to prevent loops in the hierarchy (note that this identifier is for local use only, therefore select an identifier that is meaningful to your implementation).

etlr1.eduroam.org and etlr2.eduroam.org are the European top-level RADIUS servers.

3.1.1.3 Handling empty realms

Theoretically, empty realms should not reach a National RADIUS Proxy, but if they do this code will prevent the National RADIUS Proxy from sending these empty realms to the international top-level proxy servers. A reply will be added to the rejected requests explaining the reason for rejection. Replace <TLD> with the federation top-level domain you are authoritative for.

<Handler Realm=/^$/>
      AccountingHandled
      StripFromReply         Reply-Message
      AddToReply              Reply-Message="Misconfigured client: empty realm! Rejected by <TLD>."
      AuthLog defaultAuthLog
</Handler>


3.1.1.4 Proxying to an organisation with one RADIUS Server

In the case in which an organisation has only one server, configuration is relatively easy:

<Handler Realm=/^orgA\.tld$/i,
          Client-Identifier=/^(?!radius.orgA.tld$)/>
      <AuthBy RADIUS>
                RetryTimeout             3
                Retries                       1
                FailureBackoffTime    0

                UseExtendedIds

                <Host radius.orgA.tld>
                          AuthPort           1812
                          AcctPort           1813
                          Secret               xxxxxxxxxxxxxxxxxxxxxxxxx
                </Host>

     </AuthBy>
      AuthLog defaultAuthLog
</Handler>

Realms should be pattern matched case-insensitive, because users sometimes type their realms using upper case letters.

The configuration directive "Client-Identifier=/^(?!radius.orgA.tld$)/" blocks RADIUS packets from radius.orgA.tld with realm orgA.tld from entering this Handler.

If such a packet is received it will be rejected by the handler matching realm=/.*\.tld$/i. This prevents loops between the national proxy and the server of orgA.tld.

Servers to proxy should never be marked as dead, because in doing so Radiator will not try to communicate with them until BackoffTime expires, even if that server is already live again.

3.1.1.5 Proxying to multiple RADIUS servers

Top-level RADIUS servers (confederation or federation) are duplicated for better reliability of the eduroam service, as required in the policy document [GN2DJ513,2]. Also some organisations have multiple RADIUS servers for the same reason. To use multiple servers in eduroam, a special setup has to be used. Standard detection of "dead" hosts based on timeout will not work here; timeouts might be caused by the infrastructure behind the direct peer of RADIUS server, so the server cannot assume that its peer is off-line. But if it really is down, a switch to the backup server must be performed. Unfortunately the RADIUS protocol does not provide a clear way to do that.

The problem can be solved by using a special configuration developed at CESNET and described in the article "Dead-realm marking feature for Radiator RADIUS servers" (http://www.eduroam.cz/dead-realm/docs/dead- realm.html).

The idea behind the dead-realm marking is quite simple. Instead of marking the server dead for all realms (as in dead-host marking) just the particular realm on the host is marked dead and requests are routed to another configured host.

The variable dr_timeout controls how long a realm will be marked dead on a particular host. 3600 seconds is the suggested value. Much lower values will cause the system to check the dead primary server too often. Higher values can be considered if the backup server is equally as powerful as the primary server.

_StartupHook sub        

Unknown macro: {   require "/etc/radiator/DeadRealm.pm"; }

_
DefineFormattedGlobalVar    dr_timeout 3600

Following the two AuthBy sections are definitions of the servers, which will be used as a pool for destinations defined later.

NoReplyHook and ReplyHook are necessary for the dead-realm marking feature, a Perl implementation is available online at http://www.eduroam.cz/dead-realm/. A copy version 2.0 of this implementation is in the ZIP file which accompanies this document.

NoReplyHook is called when no reply is received from the RADIUS server after two attempts within six seconds. In this case the processed packet is ignored, the realm is marked as dead on this server and when a subsequent packet with the same realm is received it will be forwarded to the other defined server.

ReplyHook is called when a response from the server is received; if the realm is marked as dead it will be unmarked and thereby identified as live.
<AuthBy RADIUS>
                 Identifier                                etlr1.eduroam.org

                RetryTimeout                         3
                Retries                                   1
                FailureBackoffTime               0

               UseExtendedIds

               <Host etlr1.eduroam.org>
                                AuthPort               1812
                                AcctPort               1813
                                Secret                  xxxxxxxxxxxxxxxxxxxxxxxxx
               </Host>

_               NoReplyHook sub

Unknown macro: { DeadRealm}

;_
_               ReplyHook sub

Unknown macro: { DeadRealm}

;_
</AuthBy>

<AuthBy RADIUS>
              Identifier                               etlr2.eduroam.org

             RetryTimeout                        3
             Retries                                  1
             FailureBackoffTime              0

             UseExtendedIds      

             <Host etlr2.eduroam.org>
                               AuthPort            1812
                               AcctPort            1813
                              Secret                xxxxxxxxxxxxxxxxxxxxxxxxx
             </Host>

_             NoReplyHook sub

Unknown macro: { DeadRealm}

;_
_             ReplyHook sub

Unknown macro: { DeadRealm}

;_
</AuthBy>

3.1.1.6 Handling unknown realms in the own federation

After the last connected realm, it makes sense to reject all known-bad realms and all unknown realms which end in the own federation's top-level domain. One such invalid realm is seen quite often due to supplicant misconfiguration: myabc.com (this is the default realm in an unconfigured Intel PRO/Set Wireless supplicant). The following stanza rejects this realm with an appropriate error message and blindly acknowledges all Accounting requests.

<Handler Realm=/myabc\.com$/i>
          AccountingHandled
                           StripFromReply   Reply-Message
                          AddToReply         Reply-Message=" Misconfigured client: default realm of Intel PRO/Wireless supplicant! Rejected by <TLD>."
                         AuthLog defaultAuthLog
</Handler>

Add the following stanza after the last valid realm to catch and reject all unknown realms that end in the own TLD:

<Handler Realm=/.*\.tld$/i>
         AccountingHandled
                         StripFromReply    Reply-Message
                         AddToReply         Reply-Message=" Misconfigured supplicant or downstream server: uses non-existing realm in <TLD> federation!"
                         AuthLog defaultAuthLog

</Handler>

The following directive (DefineFormattedGlobalVar) defines the variable dr_TOPLEVEL_server_list and assigns a list of servers responsible for the handler marked as TOPLEVEL to this variable.

DefineFormattedGlobalVar          dr_TOPLEVEL_server_list __ etlr1.eduroam.org,etlr2.eduroam.org

The handler with the filter Realm=/.+$/ will receive any request that will not be caught by more specific filters before (Realm=/^orgA.tld$/i, Realm=/.\.tld{*}$/, Realm=/$/). In this example it will be all requests that belong to other TLD's than the ones defined on this server – requests that have to be forwarded to top-level servers.

RequestHook will use the value of Identifier (= TOPLEVEL) defined in this handler to search the variable dr_TOPLEVEL_server_list holding the list of servers. It will forward the request to a server not marked dead, or if all are marked dead the one with the oldest dead-realm mark.

<Handler Realm=/.+$/>                    Client-Identifier=/(?!etlr1.eduroam.org$)/>
                    Client-Identifier=/^(?!etlr2.eduroam.org$)/>

           Identifier TOPLEVEL

           <AuthBy INTERNAL>
_                             RequestHook sub

Unknown macro: { DeadRealm}

_
           </AuthBy>
              AuthLog defaultAuthLog
</Handler>

  • No labels