Child pages
  • 3. RADIUS server configuration for eduroam-US
Skip to end of metadata
Go to start of metadata

Here you will find many example configurations for institutions joining eduroam-US. We intend to include information for as many RADIUS servers as possible. At this time Radiator and FreeRADIUS are the two RADIUS server generally used in eduroam-US. We also have configurations for Microsoft NPS and Juniper's Steel-Belted RADIUS.

Another good source of eduroam configuration information is the documentation at the eduroam.org.

The eduroam-US top level RADIUS servers are tlrs1.eduroam.us and tlrs2.eduroam.us.

The current, and temporary, eduroam-US CA certificate can be found farther down this page. This certificate is used for connecting with @eduroam.us accounts.

Note: After, or preferably before, configuring your RADIUS server, make sure your network and host firewalls are configured to pass RADIUS traffic unhindered to your servers. For more information please see Firewall Configuration Guidelines on the Non-Radius Configurations section of the Administrator Guide.

After you have configured your RADIUS server please read the section on testing your connection to eduroam-US.

eduroam-US Best Practices

Below is a compliation of best-practices for eduroam-US participating institutions. These are meant to be guidelines which will enable members of eduroam-US to stay up-to-date and secure with little extra work by RADIUS administrators.

  • Configure RADIUS servers by DNS name rather than IP to facilitate changes in infrastructure without reconfiguration of local or top-level servers.
  • RADIUS server certificates should be signed by a Certificate Authority with signing certificates already in the trusted store of most operating systems. Examples include Comodo, Thawte, and Verisign. This will ease configuration of user devices.
  • RADIUS secrets should be of the same complexity as strong passwords and greater than 12 characters. Since these will change somewhat infrequently and are only typed when first created or changed the extra complexity should not burden the administrators.</li>
  • Make your client specification as specific as possible and avoid wildcard handlers so that only TLRSs can forward requests to your server with the shared secret.
  • Be sure not to forward sub-domains – i.e. eduroamer@subdomain.realm.edu –  or requests to your main domain, to the TLRS as the request will be dropped. This is to prevent routing loops and generally is the result of a misconfiguration. This can be troublesome for users attempting to test their own forwarding if they are unaware of the filter.
  • Configure your eduroam SSID such that only usernames of the form <em>user@institution.edu</em> are accepted. Often schools will allow simply "user" without a realm for their local users, but when those users travel they cannot join since their configuration does not conform with the eduroam standard. Forcing all local users to include their realm means less debugging later.
  • Configure your RADIUS server to include the Framed-MTU attribute. This attribute should be set to, or slightly less than, the MTU of all hardware which will be passing your EAP traffic. This includes your wireless, or wired infrastructure, any passive (inline) firewalls, IPS, or IDS, and your upstream connection. For example, most hardware has an MTU of at least 1500 bytes. If an eduroamer visiting your institution comes from a school whose RADIUS server's SSL certificate is 2048 bit, then with its encoded overhead in EAP, the frames resulting from transmitting it will be larger that 1500 bytes, and will be silently dropped. If you include the appropriate Framed-MTU attribute the certificate will be appropriately fragmented in the Access-Challenge frame, and succeed.
  • Make sure that any firewalls/router allow fragmmented UDP packets to/from the eduroam-US servers and your servers.
  • Make sure to set your proxy timeout to 10 seconds. We try to guarantee that the eduroam-US servers will always respond within 10 seconds.



Cisco ISE 2.1

Charlie Moreton from Cisco has created a guide for ISE.



Configuring Cisco ACS 5.2

Thanks to Tony Brzoskowski at the University of Wisconsin-Parkside for providing this documentation. 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

Cisco's ACS 5.2 may be configured as a proxying RADIUS server in only a few steps as illustrated below.

Instructions

Create a network device for the eduroam host radius server which will authenticate your clients as they roam to other networks:

Create an external radius server proxy which will be used to authenticate clients which roam on your network:


Create an Access Service which will authenticate the clients based on rules:



Create your Service Selection Policies to route to the proper access:




Note: Per the Best Practices section above, local users should be required to include their realm (e.g. their supplicant should be configured to use user@institution.edu) when using eduroam, even at their home institution. The above configuration allows the @institution.edu to be omitted. This leads to extra debugging later when users, while traveling, do not include their realm.

For complete documentation on configuration of Cisco ACS 5.2 please see the Cisco reference manual.



Configuring FreeRADIUS

If you have any questions or comments regarding these instructions please contact support@anyroam.net.

Description

FreeRADIUS is a robust open-source RADIUS server which runs on a variety of platforms. The following assumes you have a compatible system with all necessary dependencies, have procured, complied, and installed the application on your system, and have at least glanced at the configuration files in the raddb directory in the installation path. For further help with those steps please see the Installation section of Other Resources section at the bottom of this section.

Instructions

There are four files that define the majority of the customization required to configure your system: eap.conf, proxy.conf, clients.conf, and sites-enabled/inner-tunnel. In addition, if you plan on using MS-CHAPv2 (for Active Directory integration) you will need to edit modules/mschap.

Note: Before getting started please be aware that it is often easier to start with a default FreeRADIUS installation and build-up to a working eduroam configuration unless you have extensive experience in FreeRADIUS. It may be easiest to stand-up an experimental server for eduroam, and once it is working with your 802.1x infrastructure, port the changes to your production FreeRADIUS instance.

In eap.conf (ActiveDirectory, Kerberos) you must setup the EAP methods (TTLS, PEAP, or both) that you plan on supporting at your institution. In your eap configuration block specify which EAP outer methods you plan on supporting (TTLS and/or PEAP) with the default_eap_type directive. The TLS configuration is required to define the certificate presented to your users when they create their encrypted tunnel back to the eduroam RADIUS server. For testing it is easiest to simply use the certificates shipped with FreeRADIUS (since the certificate configuration is often the hardest part of this process), so during that time you can leave the tls configuration block alone in the tls section.

proxy.conf (ActiveDirectory, Kerberos) needs to define various radius proxies to route users by realm.

You must also configure your clients.conf to match the and define clients for each server defined in proxy.conf

Other Resources

Documentation

Installation

Configuring FreeRADIUS for Authentication against Active Directory

If you have any questions or comments regarding these instructions please contact support@anyroam.net

Description

The following is a sketch of the changes required to make a default FreeRADIUS instance stand up as an institutional eduroam server with an eye towards integrating with an existing ActiveDirectory instance. These instructions are nearly identical for integrating with a Samba instance operating as a PDC as both use the ntlm_auth utility to perform the authentications.

Instructions

There are four files that define the majority of the customization required to configure your system: eap.conf, proxy.conf, clients.conf, and sites-enabled/inner-tunnel. In addition, if you plan on using MS-CHAPv2 (for Active Directory integration) you will need to edit modules/mschap.

Note: Before getting started please be aware that it is often easier to start with a default FreeRADIUS installation and build-up to a working eduroam configuration unless you have extensive experience in FreeRADIUS. It may be easiest to stand-up an experimental server for eduroam, and once it is working with your 802.1x infrastructure, port the changes to your production FreeRADIUS instance.

In eap.conf you must setup the EAP methods (TTLS, PEAP, or both) that you plan on supporting at your institution (comments removed for brevity).

eap {
   default_eap_type = ttls
   timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 2048  

md5 {
}

leap {
}

tls {
certdir = ${confdir}/certs
cadir = ${confdir}/certs
private_key_file = ${certdir}/serverkey.key
certificate_file = ${certdir}/servercert.cert
dh_file = ${certdir}/dh
random_file = ${certdir}/random
cipher_list = "DEFAULT"
make_cert_command = "${certdir}/bootstrap"
cache {
enable = no
max_entries = 255
}

ttls {
default_eap_type=mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}

peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}

mschapv2 {
}
}


In your eap configuration block specify which EAP outer-method (TLS, TTLS, or PEAP) you default to with the default_eap_type directive

Regardless of your EAP type the TLS configuration is required to define the certificate presented to your users when they create their encrypted tunnel back to the eduroam RADIUS server. For testing it may be easiest to simply use the certificates shipped with FreeRADIUS since the certificate configuration is often the hardest part of this process. If you choose to do so you may leave the tls configuration block alone in the tls section until the rest of the configuration is finished. Before going into production you should plan on updating this configuration with either a production certificate. For greatest compatibility with various devices a certificate signed by a CA that ships with most commercial supplicant key-stores such as Comodo, Thawte, or Verisign should be used. This eases deployment onto user owned devices.

If you plan on supporting TTLS or PEAP then the sub-blocks defined above configure those methods. In both cases we have the default EAP type set to mschapv2 as we use AD as our IdP. If you plan on using a different directory service you will likely need to change the default_eap_type in either the ttls or peap block (or both). In the case that you do use AD as your directory service your eap.conf should also have an empty MSCHAPv2 definition as shown above.

proxy.conf needs to define various RADIUS proxies to route users by realm and should look something like what follows:

proxy server {
default_fallback = no
}

home_server localhost {
type = auth
ipaddr = 127.0.0.1
secret =
}

realm NULL {
}

realm LOCAL {
}

realm realm.edu {
type = radius
secret =

# If you have an existing RADIUS server and are not authenticating
# against ActiveDirectory directly this allows for proxying
# to your current server
authhost = radius1.realm.edu # change to your radius server
accthost = radius1.realm.edu # change to your radius server

# If this server is the termination point for RADIUS requests and
# will authenticate directly against the ActiveDirectory server
authhost = LOCAL
accthost = LOCAL
}

realm DEFAULT {
type = radius
authhost =
accthost =
secret =
nostrip
}



If you are forwarding to a campus RADIUS server which is also FreeRADIUS you will need to create a separate DEFAULT block on it as well to forward the eduroam users (anyone with a realm different from your local realm) to the eduroam FreeRADIUS server you configured above.


You must also configure your clients.conf to match the proxy.conf:

client localhost {
ipaddr = 127.0.0.1
secret =
nastype = other
}

client {
#ipaddr =
secret =
nastype = other
}

client radius1.realm.edu {
secret =
nastype = other
}


In our sites-enabled/inner-tunnel configuration we simply disabled authentication by files and by UNIX password and added ntlm_auth to support our ActiveDirectory. If you plan on proxying your RADIUS requests to an existing RADIUS server, which in turn is already configured to authenticate against your directory-service, this configuration is not necessary and, after fixing the port number (see next paragraph) you should not need to make further changes to the inner-tunnel.

Also note, in the current FreeRADIUS distribution there is a typo leaving the authentication port set to 18120 instead of the standard 1812. In general eduroam-US uses udp/1812,1813 (for authentication and accounting resp.) but sites may opt to use udp/1645,1646 (the old standards) depending on their needs.

In modules/mschap to following settings should be changed. The encryption settings allow for the cryptographic key material to be passed back to the NAS and the ntlm_auth configuration uses the local Samba authentication against the ActiveDirectory. Be sure to change the domain to be appropriate for your institution:


mschap {
# if use_mppe is not set to no mschap will
# add MS-CHAP-MPPE-Keys for MS-CHAPv1 and
# MS-MPPE-Recv-Key/MS-MPPE-Send-Key for MS-CHAPv2
use_mppe=yes

# if mppe is enabled require_encryption makes
# encryption moderate
require_encryption = yes

# require_strong always requires 128 bit key
# encryption
require_strong = yes

# Windows sends us a username in the form of
# DOMAIN\user, but sends the challenge response
# based on only the user portion. This hack
# corrects for that incorrect behavior.
with_ntdomain_hack = yes

# Configure to use your local NTLM authentication mechanism
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{User-
Name:-None}} --domain=%
{%{mschap:NT-Domain}:-} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"

}


Configuring FreeRADIUS for Authentication against Kerberos

Thank you to Jeff Hagley at Internet2 and Joy Veronneau at Cornell for contributing to these instructions.

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

Many institutions use Kerberos authentication on their network and to join eduroam-US they will need to configure FreeRADIUS to interface with their existing Kerberos infrastructure. This document assumes that the FreeRADIUS server you are installing is the primary radius server for your organization.

Instructions

For the following instructions the following RPMs were used for RedHat on a REHL5 machine.

  • freeradius2-2.1.7-7.el5.x86_64.rpm
  • freeradius2-krb5-2.1.7-7.el5.x86_64.rpm
  • freeradius2-utils-2.1.7-7.el5.x86_64.rpm

For Kerberos authentication I needed to make a keytab file for the RADIUS server. This needs to be done with the Kerberos administration tool kadmin. Once that is done export the keytab file to the RADIUS server and make it readable only by root and the user under which the radius server runs (radiusd for the Red Hat RPMs).

Next you must make sure that Kerberos is properly configured on the server. Edit the file /etc/raddb/modules/krb5 so that the keytab and principal fields are properly filled out. At the top of your users file add the following line (without quotes) “DEFAULT Auth-Type = Kerberos”

Under eap.conf you need to properly setup TTLS with PAP authentication since Kerberos authentication will only work with this pairing of EAP methods. The following is how the eap.conf should look. Be sure to verify the paths to the SSL/TLS certificates below and that the files are readable by the radiusd user.

eap {
default_eap_type = ttls
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 2048

tls {
certdir = ${confdir}/certs
cadir = ${confdir}/certs
private_key_file = ${certdir}/serverkey.key
certificate_file = ${certdir}/servercert.cert
dh_file = ${certdir}/dh
random_file = ${certdir}/random
cipher_list = "DEFAULT"
make_cert_command = "${certdir}/bootstrap"
cache {
enable = no
max_entries = 255
}

ttls {
default_eap_type = md5
copy_request_to_tunnel = yes
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}

}


Your proxy.conf file should look like this for eduroam. If you are not configuring FreeRADIUS as the primary RADIUS server for your instittution your proxy.conf file will look different. Be sure to replace the secrets with those secrets you assign for local access and those you exchange with the eduroam-US team (this is particularly easy to overlook and can cause debugging headaches).

proxy server {
default_fallback = no
}

home_server localhost {
type = auth
ipaddr = 127.0.0.1
secret =
}

realm NULL {
}

realm LOCAL {
}

realm realm.edu {
type = radius
authhost = LOCAL
accthost = LOCAL
}

realm DEFAULT {
type = radius
authhost =
accthost =
secret =
nostrip

}


Next you need to modify the inner-tunnel and default files under /etc/raddb/sites-available. In both files under the authenticate section and right below the PAP configuration line add the following:

Auth-Type Kerberos {
krb5

}



Configuring Microsoft IAS for eduroam-US

Thank you to Brian Gibson and Mark Parlan at Wheaton College for contributing these instructions to the documentation.

If you have any questions or comments regarding these instructions please contact support@anyroam.us.

Description

This document outlines how we set up the Windows 2003 Server (SP2) Internet Authentication Service (IAS) software as a campus RADIUS server for implementing eduroam. In our case, the IAS server receives requests from 1 of 2 sources.

  1. Our local wireless controller, if the person is connecting to the "eduroam" network here on campus.
  2. From the US TLRS (Top Level Radius Server), if our user is visiting another eduroam enabled campus.

Instructions

  1. The first thing to do is open up your campus perimeter firewall and the Windows 2003 Server's local firewall so inbound requests from the US TLRSs are allowed through to these UDP ports on the IAS server: 1812, 1813, 1645, 1646.

  2. Join the local Windows 2003 IAS server to your Active Directory domain. This is important because when the Radius server needs to authenticate Wheaton users it will do so against Active Directory.

  3. Before you install Radius you should install Microsoft's Internet Information Services (IIS) so you can easily install an SSL certificate in place (you will not be using IIS for anything else, it just makes it easy to install the certificate).

    Do the following....
    1. Select Control Panel
    2. Add or Remove Programs
    3. Add/Remove Windows ComponentsApplication Server
    4. Select Internet Information Services (IIS) and uncheck any unecessary services underneath like SMTP or FTP

      After IIS is installed and all the current Windows Updates are done go into the properties for the "Default Web Site" and go under Directory Security -&gt; Secure Communications -&gt; Server Certificate and follow the wizard to create a new certificate, create a certificate signing request (CSR) from the new private key, then manually submit the csr file to a trusted certificate authority (ex: GeoTrust, Thawte, Verisign).

      Once they issued you the web server certificate and intermediate CA certificates (usually bundled into one file) just go back into Directory Security -&gt; Secure Communications -&gt; Server Certificate and follow the wizard to import the new SSL certificate. You might want to temporarily open up TCP port 443 on the server so you can test that the SSL certificate is trusted by the various clients (computers, tablets, smartphones etc...). Once you have completed your https testing close off port 443 at the local Windows firewall.

  4. Now install Microsoft's IAS (Internet Authentication Server) which will act as your RADIUS server. IAS is not part of the standard Windows 2003 installation, you must install the IAS separately, as follows:
    1. Select Control Panel
    2. Add or Remove Programs
    3. Add/Remove Windows Components
    4. Networking Services
    5. Select Internet Authentication Server.

      After the install completes the IAS console is located under Control Panel -&gt; Administrative Tools. Make sure that you run Windows Update after you are done to make sure the server is secure.

  5. Go into the IAS console and the first thing to do is add your wireless controller(s) as a RADIUS client. To add a RADIUS client right click on the Radius Client folder and select New -&gt; Radius client. For the Friendly name: enter in "Wireless Controller" and enter in your wireless controller's IP address.Next you will be asked to select a Client-Vendor and to define a shared secret. Use RADIUS Standard as the Client-Vendor (for our case this worked, we use an Aruba controller) and enter in the shared secret your network administrator provided and select Finish.

    Next we have to add the eduroam-US top level server(s) as a RADIUS client. The same process applies as above but use the shared secret that you agree upon with the eduroam-US admin team.

  6. Next we need to create a Remote Access Policy. Right click on Remote Access Policy and select New -&gt; Remote Access Policy. Give the policy a name ex: "Wireless eduroam Users". On the next screen select Wireless. On the next screen select User - User access permissions are specified in the user account. Now you will be asked what EAP type to use. IAS only supports "PEAP" and "EAP-TLS". Select PEAP then next.

    Double click on the new Wireless eduroam Users policy and click the Edit Profile button and on the Authentication tab check off Microsoft Encrypted Authentication version 2 (MS-CHAP v2) and check off Unencrypted authentication (PAP, SPAP). Make sure this Remote Access Policy is number 1 in the order of policies.

  7. Go into the local Windows Firewall on the IAS server and for the UDP exceptions you added earlier (ports 1645, 1646, 1812 and 1813) add an exception for your local Wireless Controller(s).

  8. Go into the Active Directory Users and Computers tool on a Domain Controller and edit the accounts of the people you want to grant eduroam access. To do this go to their Dial-in tab select Allow access. We wrote a script that does an LDAP modify process on every Wheaton account so this option is always allowed.

  9. You should make sure that IAS logging is turned on, you can do this by going to Remote Access Logging inside of IAS then go to LocalFile. We pointed the logs to be created inside of this folder C:\Windows\system32\LogFiles. You can put them where ever you like.

  10. Now we have to create a remote RADIUS group that will contain the eduroam-US top level server(s). This is for when a visiting user on our campus tries to connect to our "eduroam" SSID we know to refer the RADIUS request up the food chain to the eduroam-US top level server(s). Go into the IAS console, located under Control Panel -&gt; Administrative Tools. You need to expand the Connection Request Processing node then right mouse click on Remote RADIUS Server Groups and select New Remote RADIUS Server Group then Next at the initial wizard screen. Keep the default option of Typical and for the Group name (we called ours "eduroam"). You should then be asked for the Primary server: which will be the IP address of the top level us eduroam RADIUS server and for the Server group shared secret you would enter the shared secret that the eduroam-US admin provides for you (then confirm it) then complete the wizard.

  11. Now we have to create Connection Request Policies for the different connection scenarios. They are ....
    1. "USTopLevel (Wheaton users abroad)" - This policy is first in the list and it handles looking for requests coming from the eduroam-US top level server(s) with the person's login name containing "@wheatonma.edu". The policy conditions are...
      User-Name matches ".*@wheatonma.edu" AND
      Client-IP-Address matches ""Under Edit Profile on the Authentication tab select Authenticate requests on this server.
    2. "Wheaton (local Wheaton users on campus using wheatonma.edu)" - This policy is second in the list and it handles looking for requests coming from on campus (our wireless controller) with the person's login name containing "@wheatonma.edu". The policy conditions are...
      User-Name matches ".*@wheatonma.edu" AND
      Client-IP-Address matches "155.47.20.3"Under Edit Profile on the Authentication tab select Authenticate requests on this server.
    3. "External (people visiting Wheaton)" - This policy is last in the list and it handles looking for requests coming from on campus (our wireless controller) and it should get triggered for outside users (since our previous policy handled Wheaton users locally this gets everyone else, like "user@otherschool.edu"). The policy conditions are...
      User-Name matches ".*@.*" AND
      Client-IP-Address matches "155.47.20.3"Under Edit Profile on the Authentication tab select Forward requests to the following remote RADIUS server group for authentication and select eduroam.On the Accounting tab select Record accounting information on the servers in the following RADIUS server group. -&gt; eduroam.

  12. To make sure that the IAS server is using your Certificate Authority-issued SSL certificate, go to Remote Access Policies -&gt; Wireless eduroam Users -&gt; Edit Profile -&gt; Authentication -&gt; EAP Methods -&gt; Highlight "Protected EAP (PEAP)" and click Edit and it should list your SSL certificate.

  13. Create a local user within Active Directory with the name eduroam_test and send that along with the user's password to the eduroam-US admins so they can test from their campus. NOTE: Make sure you set up this Active Directory user so their account is not disabled, they have dial-in acccess allowed, their password never expires, and they cannot change their password. The eduroam-US admins will also create a user on their end (ex: wheatonma_test@eduroamus.edu) so you can test as a 'remote' user on your campus.

  14. Have your network admin configure the wireless newtork for eduroam by pointing the RADIUS requests to your IAS server.

  15. Test the different scenarios...
    1. A wheaton user off campus using eduroam_test@wheatonma.edu as the user name (The eduroam-US team can test this).
    2. A wheaton user on campus using eduroam_test@wheatonma.edu as the user name.
    3. A visiting user on our campus using wheatonma_test@eduroamus.edu as the user name (The eduroam-US team can help troubleshoot issues with logging in).



Configuring Microsoft NPS for eduroam-US

Thank you to Derek O'Flynn at LSUHSC for contributing these instructions and images to the documentation. If you have any questions or comments regarding these instructions please contact support@anyroam.net.

Update: Thanks to James Macdonell at CSU San Bernardino, we have even better and more detailed instructions for NPS.

The older instructions, which appear below, will stay around in case someone still finds them useful.

Description

To configure Microsoft Windows 2008 Server NPS for eduroam-US please follow the following directions. We do not include detailed instructions on general NPS configuration. It is required that the administrator have some knowledge of NPS configuration.

These instructions utilize Cisco WLAN controllers configured with the “eduroam” SSID. The controllers are used to map the configured policies. If your institution has a different 802.11, and thus different 802.1x settings, you will need to accommodate your system's mapping of policies. This may be as simple as only needing to add a forwarding rule and the inbound eduroam-US Top-Level rule.

Instructions

  • Create a Remote RADIUS Group called “eduroam”
  • Define the eduroam-US top-level RADIUS server as a member
  • Configure the following Connection Request Policies:
    • eduroam - <LOCAL>;
      • Replace <LOCAL>" with an appropriate value. This is used to map local realms. In the case of the example images "<LOCAL;" is "LSUHSC".
      • eduroam - External
        • This policy is used to forward the request.
      • eduroam - USTopLevel
        • This policy is used to map the request from eduroam-US. In the example images this profile is called "eduroam-UTK".






Configure the following Network Policies:

  • eduroam - <LOCAL>
    • Replace "<LOCAL>" as described above. This is used to authenticate local realms.
  • eduroam - USTopLevel
    • Used to authenticate requests from eduroam-US.




In network policies you will see MSCHAPv1 and such, but this may be ignored because on the connection policies we are overriding all authentication methods using PEAP.

Add the eduroam-US server as a client:



Configuring Radiator for eduroam-US


If you have any questions or comments regarding these instructions please contact support@anyroam.net

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 innerhandlers, 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
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&gt;

# 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
<AuthByNTLM>
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>

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 &lt;SECRET&gt;
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 the reference manual.


Configuring Juniper Steel-Belted RADIUS

Thank you to Samuel Petreski at Georgetown University for contributing these instructions and images to the documentation. If you have any questions or comments regarding these instructions please contact support@anyroam.net.

Description

Juniper Steel-Belted Radius (SBR) provides uniform security policy enforcement across all network access methods, including WLAN, remote/VPN, dial, and identity-based (wired 802.1X).

The Juniper SBR configuration for an eduroam-US institution can be seen as two major components: the general configuration via modifying the SBR Administrator and editing/creating Radius configuration files. The Global Enterprise Edition of the SBR software is required in order to support the eduroam-US configuration. The Enterprise Edition of the SBR software does not support the configuration of RADIUS proxy and therefore is not compatible with the eduroam-US requirements.

Instructions

The first step is to define a Proxy Target in the SBR Administrator configuration. Click on “Proxy Targets” and click on “Add” and enter the information in the dialog box as shown below.



The Name attribute is important because it will be later referred to in the configuration files, the IP Address field contains the IP/FQDN of the eduroam-US Top-Level server. The shared secret filed should contain the secret configured between the Top-Level eduroam-US server and your institutions.

The second step is to define the eduroam-US Top-Level server as a RADIUS client. Click on ‘RADIUS Client’ and click on ‘Add’ and enter the information in the dialog box as shown below.


The second component involves making RADIUS configuration file modifications.
Open the ‘radius.ini’ file located in the Juniper SBR directory, and enable Extended Proxy by adding the following lines (if you have the section heading then only add the configuration parameters):

[Configuration]
ExtendedProxy=1
AttributeEdit=1

[Self]
homeinstitution.edu



Open the 'proxy.ini' file located in the Juniper SBR directory and add the following directives:

[Processing]
Suffix
Undecorated

[Realms]
eduroam.edu
eduroam.edu = *.edu

[StaticAcct]
7=EduRoamOnOff
8=EduRoamOnOff

[EduRoamOnOff]
realm=eduroam.edu


Open the 'eap.ini' file located in the Juniper SBR directory, add the following directives:


[proxy: EDUROAMUS]
EAP-Only=0
First-Handle-Via-Auto-EAP=0
EAP-Type=
Available-EAP-Only-Values=0,1
Available-Auto-EAP-Values=0,1
Available-EAP-Types=LEAP|MD5-Challenge|MS-CHAP-V2|TLS|TTLS

Create a file named 'eduroam.edu.pro' containing the following directives:

[Auth]
Enable = 1
TargetsSection = AuthTargets
StripRealm = 0
RequestTimeout = 5
NumAttempts = 10
MessageAuthenticator = 0

[Acct]
Enable = 1
TargetsSection = AcctTargets
StripRealm = 0
RequestTimeout = 5
NumAttempts = 3
RecordLocally = 1

[AuthTargets]
EDUROAMUS=1

[AcctTargets]
EDUROAMUS

[FastFail]
MinFailures = 3
MinSeconds = 3
ResetSeconds = 30


Lastly restart the Juniper SBR service for the new file configurations to be read by the RADIUS server.

For complete documentation on configuration of Juniper SBR please see the corresponding reference manual.


Testing your connection to eduroam

Currently testing is done via test accounts between the eduroam-US top-level server and peering institutions. We are pursuing alternative testing systems and methodologies as we go forward and would love input as to testing tools that would help joining institutions.

The simplest way to test eduroam is to use the 802.1x supplicant which ships with your computer and the eduroam SSID itself. This requires configuring at least one wireless access-point to both broadcast the SSID and authenticate against your newly configured RADIUS server. If you plan on doing this, particularly from Windows, you will want the eduroam-US CA certificate installed in your computer's key-store. Moreover, the more modern the Windows version the more sensitive the supplicant appears to be to the certificate being verified. In Windows XP (all service packs that we are aware of) if you unchecked the "Validate Server Certificate" checkbox while configuring the supplicant authentications that had previously silently failed suddenly worked. This does not appear to be the case in Vista, and particularly, Windows 7. When testing with Windows 7 make sure that the eduroam-US CA Certificate is not only imported into your Certificate SnapIn for MMC but is also in your Trusted Root Certification Authorities list.

Testing from the *NIX command-line can currently be performed by using the eapol_test utility (included in the wpa_supplicant package). Further documentation on eapol_test, compiling it, and usage is available from Deploying RADIUS, or for complete examples of eapol_test look at the package's example wpa_supplicant.conf. A handy wrapper for this package is rad_eap_test, the source for which is available here. To use eapol_test or rad_eap_test make sure that the host on which you are conducting the test is a valid client of the RADIUS server you specify to the programs. This is one more place where host firewalls can be a nuisance; if the test test never seems to arrive at the RADIUS server check for those.

If you do not have the rap_eap_test wrapper script the following command-line and sample configuration file should suffice for testing.

%eapol_test -c<config file> -a<IP of your RADIUS server> -p<Port> -s<SECRET>


Example config file:

network={
ssid="eduroam"
key_mgmt=IEEE8021X
eap= pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40
phase2="auth=MSCHAPV2"
identity=<username@realm>"
password="<PASSWORD>"
}


Note: FreeRADIUS includes two tools called radtest and radeaptest. radtest is for testing plain (no EAP involved) RADIUS configurations and radeaptest is only able to test EAP-MD5 connections. This limitation means it and cannot be used to test EAP-TLS/TTLS/PEAP connections.



eduroam-US CA Certificate

The eduroam-US test infrastructure includes features such as EAP-TLS authentication. During testing it became clear that EAP-PEAP on Windows behaves much more nicely when the certificate of the remote RADIUS server can be validated.

Since the certificate for the eduroam.us (eduroam-US' test realm) RADIUS server is self-signed by our internal CA it is clear that the signing certificate should be available to the administrators of eduroam-US institutions.

Attached is the CA certificate that you may import into your local key-store to validate the infrastructure.

eduroam-US-root-CA.crt
eduroam-US-infra-CA.crt


  • No labels