Join InCommon

Administrator’s Guide

The eduroam-US Administrator’s guide aims to provide current and future administrators with all of the information they require to join the confederation and maintain their local RADIUS configurations per eduroam-US policies.

Peering overview

Once an institution has made the decision to join eduroam, the next step is to review the requirements and technical process. In many cases, the necessary infrastructure to begin the process is already in place and can sometimes be completed in as little as a few hours. eduroam offers two distinct services: Identity Provider (“IDP”) and Service Provider (“SP”).

1) Identity Provider (“IDP”)

When an institution is connected to eduroam as an IDP, its students, faculty, and staff can use their personal credentials from their institution to join eduroam anywhere around the world.

An academic institution begins the process of connecting to eduroam by peering its RADIUS servers to the eduroam federation RADIUS servers. Next, the institution’s RADIUS servers are connected to its directory-services such as LDAP, AD, SQL DB, and others. This allows users of the institution to connect to eduroam anywhere, simply by providing their username and a password.

eduroam uses the Extensible Authentication Protocol “(EAP”) to transfer information between parties. EAP methods required by eduroam encrypt information between the user’s device and the RADIUS servers of the user’s institution. EAP-TTLS and PEAP are the two most common EAP methods used by institutions. With eduroam, the forwarding RADIUS server(s) cannot intercept user’s credentials. Institutions can elect to provide authentication with certificates by using EAP-TLS, rather than username and password.
As an eduroam IPD, an institution’s community is able to enjoy eduroam when traveling. However, being an IDP does not allow eduroam visitors access to your institution’s Wi-Fi or wired network. To have this capability, an institution must also be an SP.
Guidelines to configure institution’s RADIUS servers to become an IDP are available, and also additional tips for Directory Services and Firewall rules.
* It is important to note, when deploying eduroam as an IDP (or as Service provider) the configuration of firewalls can lead to delays, especially when different groups control RADIUS servers and Firewalls.

2) Service Provider (“SP”)

Unlike an IDP, which is restricted to academic institutions, any organization can become an eduroam SP. In practice, most IDPs are also SPs; however, the contrary is not always true.
When an organization is connected to eduroam as an SP, students, faculty, and staff from around the world can join the eduroam network as visitors of that organization. An organization becomes an SP when

  1. the service provider broadcasts the eduroam1 network name, also known as the service set identification (“SSID”) on one if its locations, such as a campus;
  2. an IP network is configured and routed to the internet and assigned to the eduroam SSID with DHCP and DNS functions and,
  3. the RADIUS server(s) of the institution are configured to forward authentication requests up the eduroam chain for users that are not part of the institution.

Broadcast the eduroam SSID

With today’s managed Wi-Fi systems, pushing an additional SSID to wireless access-points can be done in a few clicks. This functionality is not universal or standard and is device and manufacturer2 dependent. Be aware, that most manufacturers advise against having more than five SSIDs per wireless access-point. In the case of WiFi, less is better when it comes to the number of SSIDs.

802.1X, the main protocol upon which eduroam is built, provides a great deal of convenience when it comes to role based networking. For instance, in a managed Wi-Fi system, roles can be created based on the outer-identity of the 802.1X authentication request. A user with an outer identity that matches the realm (i.e. domain) of the organization can be assigned to VLANs with access to sensitive resources, while all other users’ with realms that do not match the organization will be assigned to VLANs with less privileged access. Using this technique, it is possible to use eduroam as the sole secure SSID for a campus and still provide managed access levels previously provided with multiple SSIDs. Many schools, for example UCLA, LSU, Clemson, and Uiowa have elected to use eduroam as their sole secure SSID and differentiate levels of access between local users or visitors authentication based on their assigned roles. Roles can also be created based on directory services attributes, for example date of birth, affiliation, clearance level, that can be returned to RADIUS and create even more granular role based networking.

Look for role based access or identity based access in your vendor documentation for details on how to implement it.

Enable Internet connectivity

Enabling Internet connectivity can be the most time consuming step of the peering process. The process requires the selection of subnets to assign to the eduroam network and the configuration of those subnets on routers. In addition, decisions for firewall rules for subnets selected. A guideline for the minimum set of ports eduroam requires is included in the eduroam-U.S. User Access Requirements.

Fortunately, a shortcut to this lengthy process, used by many eduroam members, can help accelerate the process. Because eduroam is a complement to a visitor access system and not a replacement, if a school already has a visitor network (e.g. web based access, or open) and its VLAN(S) comply with the minimum set of ports required, the eduroam SSID can be assigned to the same VLAN(s) as the existing visitor network. Without the need to create additional subnets.

VLAN assignment is done directly in the Wireless Systems (Controllers, Access-Points). By assigning those visitor network VLANs directly to the eduroam SSID, one bypasses web gateways that could be in the way of eduroam and prevent the instant connectivity aspect of the service. eduroam requires that no interruption of traffic (Web gateway, …) be placed between a successful authentication and access to the Internet. Even if a location provides open Wi-Fi access, it is worth configuring eduroam to provide the benefit of encryption over the air (WPA2-enterprise), the instant connectivity, and the avoidance of rogue Wi-Fi for phishing/Man-in-the-Middle-Attacks.

Indeed, when connecting and authenticating to eduroam, a user also verifies the validity of the network since that network has to be connected to the eduroam federation to be operational and challenge the user for the infrastructure certificate (provided by the user’s institutional RADIUS server). If the certificate is incorrect, the connectivity will either fail or the user will receive a certificate warning depending on the operating system.

Configure RADIUS for SPs and SP+IDPs

An organization that is SP only has very little to configure in RADIUS. Just forward requests to the IP address of eduroam-US top level servers and use a shared secret. The RADIUS configuration for organizations that are both SP and IDP is slightly more complicated. Local authentications must be sent to directory services and visitors will be sent up the RADIUS chain (IP address and Shared Secret).
Be sure to read paragraph 5 and annexes of the following document for SP and IDP requirements: https://www.eduroam.org/downloads/docs/eduroam_Compliance_Statement_v1_0.pdf

Advice for supporting users

Advertisement

It is not uncommon for an institution to enable eduroam and not spend much time informing the community about the availability of the service. eduroam visitors will discover your network very quickly, but your own users will not. Plan a target communication campaign about the eduroam service. Including students and faculty in the rollout is a key contributor to success.

Configuration

Automate the configuration of user’s devices through installers.
Free:

  • http://cat.eduroam.org

Commercial:

  • Cloudpath Networks – XpressConnect
  • Aruba Networks – Quick Connect
  • SecureW2 – SafeConnect

Properly configuring user’s credentials (username@institution) and installing the RADIUS infrastructure certificate will greatly reduce help desk support requests.

Help Desk

The number one rule of eduroam: always contact your home institution’s help desk first. In case of DMCA complaints or complex troubleshooting contact support@anyroam.net or submit a request at www.eduroam.us (send us a message)

Example of an acceptable use policy (“AUP”) for eduroam
(to be included to the IDP, not to SP … remember, no web portal)

  1. When using the eduroam service, you shall always comply with local laws that regulate the use of the service.
  2. You shall not use the eduroam service for any unlawful purpose and not (attempt to) breach or circumvent any administrative or security controls.
  3. You shall respect intellectual property and confidentiality agreements.
  4. You shall protect your access credentials (e.g. private keys or passwords).
  5. Use of the eduroam service is at your own risk. There is no guarantee that the service will be available at any time or that it will suit any purpose.
  6. Logged information is used for administrative, operational, accounting, monitoring and security purposes only. The logged information may be disclosed under lawful order to law enforcement or other entities.
  7. The access-granting bodies and Resource Providers are entitled to regulate, suspend or terminate your access, within their domain of authority, and you shall immediately comply with their instructions.
  8. You are liable for the consequences of you violating any of these conditions of use.

[1] eduroam SSID is always lowercase
[2] For tips on how to configure particular equipment the following link can be useful: https://wiki.terena.org/display/H2eduroam/How+to+deploy+eduroam+on-site+or+on+campus – Howtodeployeduroamon-siteoroncampus-eduroamsetuponCampus:IdPandSP

Technical overview

As described in the introduction the eduroam project is “A worldwide federation of RADIUS servers facilitating network access for roaming academic affiliates using IEEE 802.1x as the vehicle. eduroam’s use of 802.1x in concert with RADIUS means the network is built around well understood, established, and easy to manage standards which are often already deployed within the network infrastructure of educational institutions.”

The goal of this documentation is to give a more complete technical explanation of the way the various components of eduroam fit together to provide a seamless authentication and user experience for users of the eduroam network.

Fundamentally eduroam relies on standard wireless authentication tools including 802.11, 802.1x, and RADIUS.  When a user associates to the eduroam SSID (or any 802.1x protected SSID or wired connection for that matter) the client computer is not able to pass any traffic other than 802.1x until granted further access by the access-point (or switch in the wired case).  The client software on the client computer is called the supplicant (though you may refer to the client computer itself as the supplicant as well); The network hardware to which the computer is associated or physically connect is called the authenticator and the authenticator directs communication with the authentication infrastructure, here referred to as the “authentication server”.  The authentication server itself may actually be multiple servers and/or authentication components such as LDAP, ActiveDirectory (or Samba acting as a Primary Domain Controller and interacting with LDAP behind the scenes).  The basic authentication scheme is described below (fig. 1)


Figure 1: Basic Authentication with 802.1x over 802.11

The 802.1x authentication process is more complicated than simply “exchanging credentials” as alluded to above.  The actual exchange between the supplicant and authenticator involves an Extensible Authentication Protocol (EAP) conversation.  The EAP request is forwarded to the authentication server, generally in the form of a RADIUS request.  The actual security of EAP comes from the use of SSL with one of the many EAP sub-protocols, the most common of which are listed here:

  • EAP-TLS – requiring both client and server SSL/TLS certificates
  • EAP-PEAP – requiring only a server certificate but also an ActiveDirectory or Samba PDC authentication server.  This is the default for Windows supplicants and requires no external software, and is also supported natively by Apple’s OSX, and some Linux supplicants
  • EAP-TTLS – this sub-protocol also requires only a server certificate and is supported natively by Apple’s OSX, iPhone OS, and most Linux supplicants.  To use EAP-TTLS in Windows requires an external supplicant such as Secure-W2

For a detailed comparison between common EAP methods see the EAP method comparison matrix.

During authentication via of any of the EAP protocols described above, an SSL tunnel is created between the supplicant and the authentication server, inside of which the actual credentials are exchanged.  This protects the user from a compromise of their credentials by any third party during authentication.  In the case of RADIUS, the SSL tunnel is constructed by the use of RADIUS attributes carrying the encrypted data.


Figure 2: Authentication with 802.1x over 802.11 with EAP details

An additional option that users may configure their supplicant to use is the so-called “outer-identity” which is passed outside of the encrypted tunnel to the authenticator and authentication servers. By default this identity is simply their username, or more often in the case of eduroam username@realm (such as joe@example.edu where “joe” is the username or “netid” and “example.com” is the so-called realm). Since, as we will see in the next sections, only the realm is used for routing of the request users may optionally set their outer-identity to be anything they like as long as the realm is their actual realm, and their inner-identity is configured correctly. For purposes of etiquette it is expected that if the outer-identity is not set to their inner-identity then it is set to anonymous@realm.edu. The ability to properly anonymize the authentication sequence means that intermediate authentication servers (which are very important in the next section) cannot observe and track authentication attempts of eduroam-ers using the system.


Figure 3: Authentication with 802.1x over 802.11 with an anonymous outer-identity

Routing in eduroam

As discussed to in the prior paragraph, the local authentication server may not be the final destination for a given authentication request. If the realm of the user is not the local realm then the request may be forwarded to a remote RADIUS server which is authoritative for that realm, or simply knows where the request must go to be answered authoritatively. RADIUS supports this forwarding in its proxy mode as seen below.  When a RADIUS request is forwarded the SSL tunnel protecting the privacy of the requestor is propagated throughout the RADIUS infrastructure, thus preventing administrators not responsible for the handling of the request from intercepting and/or manipulating the contents of the EAP exchange.  The only information an intermediate RADIUS server has is the outer-identity of the requestor, the state of the EAP request (accept-request, access-challenge, access-accept, or access-reject) and any RADIUS attributes passed outside of the tunnel.


Figure 4: Authentication with 802.1x over 802.11 with RADIUS proxying

eduroam-US is authoritative for the .edu TLD, and handles routing to other TLDs including those handled by eduroam in Europe (for all European members of the federation), eduroam in the Asia-Pacific region (including Australia, China, Hong Kong, Japan, New Zealand, and Taiwan), and Canada.  Within the US the eduroam-US Top-Level RADIUS Server (TLRS) handles routing to .edu member institutions.


Figure 5: eduroam-US routing

 

Notes:

Glossary:
  • Supplicant – The client software on an computer associating to an 802.1x secured network. Often the computer itself (or even the user) is referred to as the supplicant but generally without ambiguity.
  • Authenticator – The authenticator is the piece of network equipment to which a supplicant is connected and attempting to perform an 802.1x authentication. This may be a wireless access point, a switch, or another variety of hardware made for 802.1x. The authenticator will only pass 802.1x traffic to an authentication server until such point as the user has been authenticated and granted access to the network.
  • Authentication Server – an authentication server is a server or network appliance which is able to accept 802.1x authentication requests and respond appropriately based on credentials passed it it.  It may be a server running a RADIUS server and a directory service or simply know how to forward requests to another server which is itself connected to LDAP/RADIUS.  This abstraction is the strength of the 802.1x architecture.
References:

EAP Method Feature Comparison

The following is a comparison of the most common EAP methods deployed in the eduroam-US ecosystem.

EAP-TLS

Native Supplicant Support:
Windows (XP, Vista, 7), Mac OS X, Linux, iOS (iPhone, iPod Touch, iPad), Android (v1.6+)

Pros:

  • Validates client as well as infrastructure
  • Reduced risk of being Phished
  • Blocking user access is via certificate revocation

Cons:

  • PKI infrastructure is required
  • Users must configure supplicant to use certificate*
  • Identity may be exposed in TLS exchange depending on contents of certificate
EAP-TTLS

Native Supplicant Support:
Windows (8, 10), Mac OS X, Linux, iOS (iPhone, iPod Touch, iPad), Android (v1.6+)

Pros:

None

Cons:

  • No native supplicant support on Microsoft Windows XP or 7
  • Potential for Man-in-the-Middle attacks*
EAP-PEAP

Native Supplicant Support:
Windows (XP, Vista, 7), Mac OS X, Linux, iOS (iPhone, iPod Touch, iPad), Android (v1.6+)

Pros:

  • Works on many platforms

Cons:

  • Potential for Man-in-the-Middle attacks*
  • Identity may be exposed during Phase-1 of exchange
  • This may be mitigated using configuration tools such as the iPhone Configuration Utility for iOS devices (iPhone, iPod Touch, iPad), Active Directory for Windows devices (XP, Vista), etc.
  • Man-in-the-Middle attacks may be perpetrated against any SSL/TLS protected service in which the used server certificates are not validated. This validation comes from the signing Certificate Authority’s (CA) certificate being in the root-store of a given device. For common CAs the certificate is often bundled with the operating system. If an institution opts to use either a CA which is not shipped with common OSs or their own CA which is not an intermediate CA for a well-known CA, then they must take the responsibility of distributing their CA certificate, and installing it correctly on end-user devices. The same configuration tools discussed to mitigate the complexity of configuring TLS certificates for end-user devices may sometimes be used to install necessary CA certs for those devices, even while using EAP methods other than EAP-TLS (or PEAP-TLS).

RADIUS server configuration for eduroam-US

Here you will find many example configurations for institutions joining eduroam-US.  We intend to include configurations and/or HowTos for as many RADIUS servers as possible.  At this time Radiator and FreeRADIUS are the two RADIUS server generally used in eduroam-US.  In addition to these two servers, thanks to the contributions of various institutions involved in eduroam-US we now have configurations for Microsoft NPS and Juniper’s Steel-Belted RADIUS. Soon we hope to include Microsoft IAS, Cisco Secure-Access, Avenda, and other RADIUS servers.

Another good source of eduroam configuration information is the European eduroam consortium’s documentation site.

The eduroam-US top level RADIUS servers are tlrs1.eduroam.us and tlrs2.eduroam.us. It is preferred to use the name where possible.

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.

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.
  • 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 user@institution.edu 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. You can find it at the following link.

https://community.cisco.com/t5/security-documents/configuring-eduroam-on-cisco-identity-services-engine-ise-2-1/ta-p/3655770


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 document, 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 their reference manual.


Configuring FreeRADIUS

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
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:

Configuring FreeRADIUS for Authentication against Active Directory

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
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 your 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 the eduroam-US Team and we will work with you to assist as much as possible.

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 Components.
      4. Application Server.
      5. 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 -> Secure Communications -> 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 -> Secure Communications -> 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 -> 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 -> 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 -> 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 -> 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. -> eduroam.
    12. To make sure that the IAS server is using your Certificate Authority-issued SSL certificate, go to Remote Access Policies -> Wireless eduroam Users -> Edit Profile -> Authentication -> EAP Methods -> 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 the eduroam-US Team and we will work with you to assist as much as possible.

Update: Thanks to James Macdonell at CSU San Bernardino, we have even better and more detailed instructions for NPS. You can find then here. The older instructions 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 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 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 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>

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


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 the eduroam-US Team and we will work with you to assist as much as possible.

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 team has been working hard on enhancing the eduroam-US test infrastructure including experimentation with new features such as EAP-TLS authentication. During the 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.

File Attachment:

Attachment (Size)
eduroam-US-root-CA.crt (2.15 KB)
eduroam-US-infra-CA.crt (7.19 KB)

non-RADIUS configurations

There are many possible configuration decisions that may come up during the planning of an eduroam deployment at your institution.  This section will provide How-Tos and tips for configuring your servers and services for federation.


eduroam-US User Access Requirements

Because eduroam is authenticated via 802.1X we encourage participating institutions to allow users access as many services as possible. For a consistent user experience for travelers, eduroam-US follows the European policies (p. 29) regarding minimum service support for all users joining the eduroam SSID:

  • HTTP/HTTPS [tcp/80, tcp/443]
  • SSH [tcp/22]
  • Email:
    • IMAP(2+4,3,S) [tcp/143, tcp/220, tcp/993]
    • POP(3S) [tcp/110, tcp/995]
    • SMTP(S/STARTTLS) [tcp/465, tcp/587]
  • VPN
    • Standard IPSec VPN [IP proto 50 (ESP), IP proto 51 (AH), udp/500 (IKE)]
    • OpenVPN 2.0 [udp/1194]
    • Cisco IPSec VPN over TCP [tcp/10000]
    • PPTP VPN [IP proto 47 (GRE) and tcp/1723]
  • Miscellaneous
    • IPv6 Tunnel Broker Service [IP proto 41]
    • IPSec NAT-Traversal [udp/4500]
    • Passive (S)FTP [tcp/21]
    • RDP [tcp/3389]

Samba as a Domain Controller with OpenLDAP

Samba combined with OpenLDAP can be used to allow PEAP and TTLS authentication with free tools. This provides an alternative to Microsoft’s Active Directory for institutions wishing to support PEAP natively under Windows without the use of Secure-W2.

Before getting Started

There are several things to consider before implementing OpenLDAP as the Identity Provider (IdP) for eduroam-US at your institution. The first is that if you already have an existing directory service (AD, LDAP, etc…) then trying to interface Samba with that server will be more difficult than simply implementing a Domain Controller in Samba as is described below. If you happen to be using OpenLDAP as your IdP Samba does provide tools to convert your existing LDAP schema into the format required for it to operate as an PDC. This process should be undertaken with care and is not described within this document.

Setting up OpenLDAP

The first step in the process is to install OpenLDAP. Depending on your underlying platform the specific steps may vary. We recommend the following links for Ubuntu (Debian should be extremely similar) and RedHat Linux distributions. We welcome recommendations for further reference sites to configure other Linux distributions, various BSDs, or other *NIX variants (See the references for several).

Configure Samba as a Primary Domain Controller (PDC)

We assume Samba is installed and configured but not acting as a PDC. Add the following to your smb.conf (generally /etc/samba/smb.conf) to configure Samba as a PDC:

workgroup = institution.edu
security = user
domain logons = yes
domain master = yes #for a secondary (backup PDC) set this to no

To allow Windows machines to join the domain you also need to setup the following

logon path = \\%N\%U\profile
logon drive = H:
logon home = \\%N\%U
logon script = logon.cmd
add machine script  = sudo /usr/sbin/smbldap-useradd -t 0 -w "%u"

Setup Shares

For Samba to act as a PDC we must also setup various shares including [homes], [netlogon], and [profiles]

[homes]
   comment = Home Directories
   browseable = no
   read only = no
   create mask = 0700
   directory mask = 0700
   valid users = %S

[netlogon]
   comment = Network Logon Service
   path = /srv/samba/netlogon
   guest ok = yes
   read only = yes
   share modes = no

[profiles]
   comment = Users profiles
   path = /srv/samba/profiles
   guest ok = no
   browseable = no
   create mask = 0600
   directory mask = 0700

Other useful Samba options may be found in the Domain Control section of the Samba documentation. Some potentially useful options may be found below:

wins support        = no  #disable WINS (WINS is needed for pre-Win2k machines)

unix password sync  = yes #keep the UNIX passwords the same
pam password change = yes #with the above, use PAM and not a passwd(1) program

#Ensure that samba will remain the master browser
local master     = yes
preferred master = yes
os level = 33

#disable printing
load printers = no
printing =

Testing your Configuration

To test your configuration you should use the ntlm_auth(1) tool on the command-line. This tool acts as an intermediary between a domain controller (Samba or ActiveDirectory) and UNIX applications. An example command-line would be: ntlm_auth –domain=INSTITUTION –username=eduroam_tester

References

Firewall Configuration Guidelines

RADIUS traffic is carried by UDP with various port pairs. Current conventions call for udp/1812, udp/1813 (for authentication and accounting respectively) where the now deprecated ports of udp/1645, udp/1646 are used by some RADIUS servers. The eduroam-US TLRS responds to both sets of authentication and accounting ports.

Your firewalls must allow all RADIUS traffic between the eduroam-US Top-Level RADIUS Server(s) (TLRS) and your RADIUS server(s) on the ports you choose during configuration.


Monitoring RADIUS infrastructure with Nagios

Monitoring of RADIUS from Nagios can be complicated but is possible with the right collection of plugins and configurations. The following are a few methods of doing so:

The check_radius.pl plugin provides two methods for checking your RADIUS infrastructure’s status. The first is to do non-authenticated monitoring by using Status-Server packets (see RFC 5997 for more details). This was first implemented in FreeRADIUS by Alan DeKok and then adopted by Radiator (and maybe other servers). When the RADIUS server receives such a request (without a username or password for authentication but it does require a valid RADIUS secret to construct the request) it responds with various status and statistics about that RADIUS server. You may also use that plugin with a credentials to verify that Authentication is working on the remote host.

Another method you can use to monitor RADIUS is to use the rad_eap_test.sh shell script as described and linked to in the Testing your connection to eduroam section of the Administrator’s Guide. This script was designed to be a Nagios plugin as well. This allows you to test EAPoL authentication (with the combination of inner and outer methods as appropriate) against the remote site and is more appropriate than the above Nagios plugin if you want to test the state of the AAA infrastructure.

Since the eduroam-US TLRS(s) run Radiator the Server-Status method should generally be sufficient for most institutions to test their connections to the top-level. The EAPoL method will catch issues with forwarding but requires a test account on the target infrastructure.

RadSec

RADSEC is next-generation RADIUS transport which relies on TCP and TLS for reliable and secure transport with integrity verification.  Deployment of RADSEC will likely come in two phases:  Initially the eduroam infrastructure will deploy RADSEC for infrastructure validation, in which case TLS replaces shared RADIUS secrets.  The second-phase of RADSEC deployment will replace the current hierarchical structure of eduroam with a Peer-to-Peer model as outlined in [5].

Currently RADSEC support is integrated into Radiator [2], and FreeRADIUS support is forthcoming.  To aid in integration of RADSEC with existing infrastructure the radsecproxy tool [3] has been created by UNINETT (Norway) to provide RADSEC infrastructure while proxying to non-RADSEC aware RADIUS servers.

For technical information on RADSEC and dynamic discovery for RADSEC please see [4] and [5] below:

  1. GEANT2 report on RADSEC
  2. Open Source Consultants Whitepaper on RADSEC
  3. radsecproxy homepage
  4. TLS encryption for RADIUS over TCP (RadSec)
  5. NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS

eduroam security

Client Security:

Teaching eduroam users to securely use the eduroam infrastructure is complicated and must be done on a home-institutional basis due to varying configurations. There are several details in the use of eduroam which can be confusing as well.  The eduroam-US site plans to maintain a “best-practices” for client configuration document which we encourage other institutions to contribute to, as well as link to or copy to their own knowledge-bases to support their users.

Infrastructure Security:

The security of the eduroam infrastructure as a whole is a top-priority.  Enhancing and maintaining the security of the infrastructure is of particular interest to the eduroam-US team.

Research:

Research in the security of eduroam is within the scope of the eduroam-US team’s goals as we proceed.  If users or administrators from other institutions find security issues within the system or have suggestions on ways to solve known problems we are interested in hearing from you.  Please contact us directly with any inquiries or post them to the (soon-to-be announced) eduroam-US listserv!

eduroam-US End-User Configuration Guide

The eduroam-US End-User Configuration Guide strives to provide member institutions of eduroam-US with a template for their own documentation and to guide eduroam administrators on proper configuration of their eduroamers’ end-stations.  It should contain the basic information on how an end-user joins the eduroam network with various supplicants; how to verify the integrity of their home institution’s certificate; and the work-flow for reporting any difficulties they have with the network to the appropriate entities.

Each institution in the eduroam-US federation will have specific configuration needs and are welcome to copy this information and images to their home website, or contribute any missing details to this one.  Please contact the eduroam-US Team with any comments or contributions on this material.


Configuring Linux
This document assumes the Gnome desktop shipped with many common Linux distributions.  To join eduroam with the Gnome windowing system you must configure the NetworkManager with an eduroam profile.  When asked for your credentials provide credentials based on the following.  If you are from example.edu (your “realm”) and your username (sometimes called NetID) is traveler then your login name is traveler@example.edu.  Your password is your normal password at your home institution.

Creating an eduroam Profile
Open the NetworkManager as seen below, select the Wireless tab and click “Add”.

In the dialog that appears change the “Connection Name” to eduroam.  You may opt to check the “Connect automatically” check box.  Then fill the Wireless configuration tab as seen in the image below.  The SSID should be “eduroam” (without quotes) and the Mode should be set to “Infrastructure”.  Next select the “Wireless Security” tab.

In the Wireless Security tab there are many settings to configure.  In the “Security” drop-down box select “WPA & WPA2 Enterprise”.  In the Authentication drop-down menu select the PEAP or TTLS authentication method, whichever is used by your home institution.  In the “Anonymous identity” box enter anonymous@<your realm> (i.e. anonymous@example.edu in the case described at the top of this document).  Unless your home institution provides a CA certificate leave that drop-down empty.  If they do provide a certificate select it by clicking the file icon on the right side of the widget.  If you are using PEAP leave the “PEAP version” drop-down set to “Automatic”.  TTLS users have no analogous setting.  In the “Inner authentication” drop-down select the appropriate option for your home institution (often MSCHAPv2).  Finally provide your username and password from your home institution.  See below for completed forms.  Once the forms look correct (something like those below) press “Apply”.


Finally, if you have not selected a CA Certificate in the previous step you will be warned (as seen below). Simply select “Don’t warn me again” and press “Ignore” unless you have a certificate, at which point please select it.

After these settings are configured, you should be able to connect by pressing “Connect” in the following dialog.  In the future, you may connect via the NetworkManager icon in the task-bar.


Configuring Mac OSX
This Howto is specifically written for OSX Leopard (10.5)  and Snow Leopard (10.6) and may vary for versions prior.

To join eduroam on OSX simply select the eduroam SSID from the Airport menubar icon.  When asked for your credentials provide credentials based on the following.  If you are from example.edu (your “realm”) and your username (sometimes called NetID) is traveler then your login name is traveler@example.edu.  Your password is your normal password at your home institution.

Security Information
If you have not already added the SSL/TLS certificate from your home institution to your keyring you will be asked to do so now.  You should then be connected to eduroam and be able to surf as normal.

Hint:  To view your home institution’s RADIUS certificate and allow the Keychain to verify the certificate of your home institution before providing your username and password you can use a two-step verification process:  First provide the username anonymous@example.edu (where example.edu is your home institution as above), and an empty password.  If you have not stored the certificate in your keyring you will be presented your home institution’s RADIUS server certificate.  If it is correct you can store then it to your Keychain (you will be asked for the computer’s administrator password if you are not running as administrator).  It is recommended you do this the first time while at your home institution, and if possible verify the certificate’s fingerprint with your IT staff.  This simple check is the foundation of all security within the eduroam network.

If you have previously verified and stored the certificate for your home institution this step allows the Keychain to verify the certificate before you provide your real credentials mitigating the damage from a rogue man-in-the-middle attack.  Once the certificate has been verified (and possibly stored) you will be asked for your credentials a second time.  This time provide your real credentials as above and you will be connected to the network.

Storing your credentials in an eduroam profile
To create a permanent eduroam profile for connecting to the network with the correct settings, including “inner” and “outer” identities follow the following instructions:

In Network Preferences (the bottom menu item in the Airport menu), with the Airport card selected, click “Advanced…” in the lower right-hand corner.  In the advanced settings select the 802.1X tab.

As seen below please create a new 802.1x “User Profile” and fill in your username and password as shown in the second image.  If you would prefer to be prompted for your password each time you connect to eduroam leave the password field blank.  Select the appropriate authentication methods (TTLS or PEAP generally), and select the eduroam network in the “Wireless Network” drop-down list.

To configure your “outer-identity”, which is what the institution you are visiting and the other eduroam servers between the visited institution and your home institution, will see do the following.  Select the PEAP or TTLS authentication method, whichever is used by your home institution (both may be allowed so follow the instructions for both in that case).  Click on “Configure…” just below the Authentication methods list.  In the dialog box that pops up entire anonymous@<your realm> (i.e. anonymous@example.edu in the case described at the top of this document).  If you are using TTLS then make sure to configure your “TTLS Inner Authentication” as appropriate for your home institution as well.  When you are done you should have filled out the appropriate forms similarly to the images below.


The next step is to configure your home institution’s RADIUS server certificate.  For help with this please contact your home-institution helpdesk as they will have the information on your certificate.  If you have previously joined the eduroam network, preferably from home the first time, and accepted the certificate provided then it should be in your Keychain.  If not you may need to add it from a file per the instructions from your home institution.

Assuming the certificate is in your Keychain we will allow that certificate to be used by default for eduroam:  Click the “Configure Trust” button (bellow the Authentication Methods list).  Click the “+” in the lower-left corner of the dialog and select either “Select Certificate File” (if you have downloaded the certificate file to your hard drive previously) or “Select Certificate from Keychain” if you’ve previously accepted it (see the first image below).  In the prior case, navigate your hard drive to find the file, select it, and click “Ok”.  In the latter case (the second image below) find your home institution’s certificate in the list, select it, and click “Ok”.  Your home RADIUS server should now be listed in the “Certificates” tab of the dialog (the third image below).  You may optionally list RADIUS servers to trust (the fourth image below).  If you wish to do so select the “Servers” tab, click the “+” and provide the DNS name or IP address of the RADIUS servers you wish to trust.  Please consult your home institution for help with this step.  Once you have selected certificates and/or servers click “Ok” to return to the 802.1X configuration tab.




After completing all of the steps above your preferences screen should look similar to the image below.  If so please click “Ok” to return to the Network Preferences pane.

Upon returning to the main Network Preferences pane click “Apply” in the lower-right corner of the dialog.  Then select the eduroam network from the “Network Name” drop-down list.  After connecting you should see your 802.1X authentication status below the network name.  If all went well in your configuration you should now be connected to the eduroam SSID and able to surf as usual!

For further information please see the Apple Knowledge Base article on configuring 802.1x networks in OSX 10.5.


Configuring Windows 7
To join the eduroam network from Windows XP you must first setup your preferred networks to use the correct encryption settings for your home institution.

Setting up the Network and Sharing Center for Windows 7
Right-click the network icon on the lower right side of the screen and then click Open Network and Sharing Center.

Click Manage wireless networks.

Click “add” then click “Manually connect to a wireless network.”

Click “Manually create a network profile” and populate the information as shown below.


Click Next and you should see a Successfully added eduroam window.

Click “Change connection settings” and select the Security tab and then click “Settings” after verifying that “Microsoft: Protected EAP (PEAP)” is selected in the drop-down menu labeled “Choose a network authentication method:”

Click the configure button next to the Select authentication method drop down box.

Uncheck “Automatically use my windows username and password” and click Ok.

Click the advanced settings button.

Check the Specify authentication mode box and select User authentication from the drop down box.

Click Ok then click Ok again on the eduroam Wireless Network Properties window.

Close the Manage Wireless Networks window.

Click the network icon on the lower right-hand side of the screen.

Click eduroam and click connect.

When you see the “additional information is needed to connect to eduroam” balloon click on it.

When you see the Network Authentication box, provide your credentials in the form of username@<your institution>.  If you are from example.edu (your “realm”) and your username (sometimes called NetID) is traveler then your login name is traveler@example.edu.  Your password is your normal password at your home institution.

Congratulations. You should now be connected to eduroam.

Thank you to Lindsey Chesnutt at UTK for gathering these directions


Configuring Windows XP

To join the eduroam network from Windows XP you must first setup your preferred networks to use the correct encryption settings for your home institution.

Setting up the Windows Network Manager for Windows XP

From the view available wireless networks window click Change the order of preferred networks on the left-hand side.

Click the Add button under “Preferred networks”.

In the Association tab make sure your settings are as below. Verify that the Network name (SSID) is set to eduroam, Network Authentication is set to WPA2, and Data Encryption is set to AES.

Select the Authentication tab. Make your settings are as below. Verify that EAP type is set to Protected EAP (PEAP).

Click the Properties button then verify that the Select Authentication Method drop-down box is set to Secured password (EAP-MSCHAP v2).

Click the Configure button. Uncheck the checkbox labeled Automatically use my Windows Logon name and password (and domain if any).

Click the OK button on all of the windows.

Join the network called “eduroam” and when prompted provide your credentials in the form of username@<your institution>.  If you are from example.edu (your “realm”) and your username (sometimes called NetID) is traveler then your login name is traveler@example.edu.  Your password is your normal password at your home institution.

Example of an Acceptable Use Policy (AUP)

(These AUP items are designed for users of an institution registering for eduroam before traveling. No AUP should be requested to eduroam visitors of the institution)

By joining the eduroam service as a user you shall be deemed to accept these conditions of use:

  1. When using the eduroam service, you shall always comply with local laws that regulate the use of the service.
  2. You shall not use the eduroam service for any unlawful purpose and not (attempt to) breach or circumvent any administrative or security controls.
  3. You shall respect intellectual property and confidentiality agreements.
  4. You shall protect your access credentials (e.g. private keys or passwords).
  5. Use of the eduroam service is at your own risk. There is no guarantee that the service will be available at any time or that it will suit any purpose.
  6. Logged information is used for administrative, operational, accounting, monitoring and security purposes only.  The logged information may be disclosed under lawful order to law enforcement or other entities.
  7. The access-granting bodies and Resource Providers are entitled to regulate, suspend or terminate your access, within their domain of authority, and you shall immediately comply with their instructions.
  8. You are liable for the consequences of you violating any of these conditions of use