Configuring Radiator for eduroam-US

If you have any questions or comments regarding these instructions please contact the eduroam-US Team and we will work with you to assist as much as possible.

Description

Radiator is a robust commercial RADIUS server written by Open System Consultants.  The Radiator server is used by the eduroam-US Top-Level server as well as the European Top-Level servers. Below is a basic configuration to get Radiator to handle requests from your local wireless infrastructure as well as requests from eduroam-US.

Instructions

The Radiator configuration for an eduroam-US institution can be seen as four major components:  The general configuration, the client configuration, the outer and inner handlers, and the eduroam handler.

The general configuration sets up paths, logging details, and IPs/ports to bind the RADIUS server to:

# Sample Radiator configuration of a US Institution called example.edu
LogDir /var/log/radius
DbDir /etc/radiator
LogFile %L/%Y/logfile.%y%m%d
PidFile %L/radiusd.pid

# Use a low trace level in production systems. Increase
# it to 4 or 5 for debugging, or use the -trace flag to radiusd
Trace 3

AuthPort 1812
AcctPort 1813
The client configuration allows for incoming connections to the RADIUS server. At minimum an eduroam-US institution must handle connections from the eduroam-US Top-Level server(s). If your Radiator instance also handles other RADIUS responsibilities you will require client handlers for each those devices making requests:

# Client handler for connections from US Top-Level
<Client [eduroam-US top level server 1]>
   IdenticalClients [eduroam-US top level server 2]
   Secret <SECRET>
   Identifier from_eduroam
</Client>

The inner and outer-tunnel handlers are the most complicated portions of the Radiator configuration for eduroam-US.  The outer-handler terminates the SSL tunnel and defines inner-authentication methods.  This is where you configure your certificates and set some inner-tunnel specific settings.  The AutoMPPEKeys directive instructs the server to pass back necessary key material to your NAS. 

Please Note: The inner-tunnel handlers must be defined before the outer-handler in your Radiator configuration file because handlers are matched by order of definition in comparing the handler checklist.  Because the outer-handler is less specific it matches the more-specific inner-handler checklist as well and will mask the inner-handler.  See section 5.17 of the Radiator handbook for more details.

# Outer Handler, forwards based on tunnel type, to above handlers for TTLS or PEAP
<Handler Client-Identifier=from_eduroam, Realm=/^(?:.+\.)*example\.edu$/i>
   <AuthBy FILE>

      # file containing the word "anonymous" w/o quotes on its own line
      Filename %D/dot1x_anon

      # your institution may not support both PEAP and TTLS but can
      EAPType TTLS, PEAP 
      EAPAnonymous %0

      EAPTLS_CAFile /etc/pki/tls/certs/cacert.pem
      EAPTLS_CertificateFile /etc/ssl/certs/radius.example.edu.pem
      EAPTLS_CertificateType PEM
      EAPTLS_PrivateKeyFile /etc/ssl/private/radius.example.edu.pem
      EAPTLS_PEAPVersion 0
      EAPTTLS_NoAckRequired
      AutoMPPEKeys
   </AuthBy>

   AcctLogFileName %L/%Y/eduroam_detail.%y%m%d
</Handler>

For each inner-handler type (TTLS and/or PEAP) a separate tunneled inner-handler block is required.  Within these blocks local authentication policies are handled, which may include authentication against LDAP, Active Directory (for PEAP handlers), local files, or another directory service supported by Radiator.

Below is an example of a PEAP handler.  The only difference between a PEAP and TTLS handler in terms of the handler block is the TunnelledByPEAP directive is replaced by TunnelledByTTLS. In the below example we have samples of NTLM (Active Directory), LDAP authentication, and authentication by a plaintext file (this is an easy way to create temporary or permanent test accounts).

<Handler Client-Identifier=from_eduroam, TunnelledByPEAP=1, Realm=/^(?:.+\.)*example\.edu$/i >
   <AuthBy GROUP>
      AuthByPolicy ContinueUntilAcceptOrChallenge

      # For ActiveDirectory backed IdP's
      <AuthBy NTLM>
         Domain EXAMPLE
         UsernameMatchesWithoutRealm
         EAPType MSCHAP-V2
      </AuthBy>

      # For LDAP backed IdPs
      <AuthBy LDAP2>
         UseSSL
         SSLCAClientCert /etc/ssl/certs/ldap.example.edu.pem
         SSLCAClientKey /etc/ssl/private/ldap.example.edu.pem
         SSLCAFile /etc/ssl/certs/cacert.pem
         Host ldap.example.edu
         BaseDN ou=People,dc=example,dc=edu
         ServerChecksPassword
         AuthAttrDef radiusReplyItem, GENERIC, reply
         HoldServerConnection
         Version 3
      </AuthBy>

      # For temporary test credentials (if necessary)
      <AuthBy FILE>
         Filename %D/eduroam_test_users
         EAPType MSCHAP-V2
      </AuthBy>

   </AuthBy>

   AcctLogFileName %L/%Y/eduroam_detail.%y%m%d
</Handler>

The final block is the default eduroam-US handler which passes non-institutional users to the Top-Level server.  Just as above the AutoMPPEKeys directive passes necessary keying information to the appropriate NAS.

# Default Handler forwards to eduroam-US Top-Level
# This will load balance requests bewteen multiple RADIUS servers.
<Handler>
   <AuthBy HASHBALANCE>
      Secret <SECRET>
      AuthPort 1812
      AcctPort 1813
      RetryTimeout 8
      Retries 0
      MaxFailedRequests 1
      <Host [eduroam-US top level server 1]>
      </Host>
      <Host [eduroam-US top level server 2]>
      </Host>
      AutoMPPEKeys
  </AuthBy>
</Handler>

For complete documentation on configuration of Radiator please see their reference manual.