Cisco AP 1200 Series (802.11g Radio).
The configuration examples used in this document were tested and made on a Cisco Series 1200 with an 802.11g Radio Module and with the following Cisco software:
Setting the Name and IP address
First, an IP address on the BVI interface (the IP address that this Access Point will have for accessing
resources like the RADIUS server) needs to be configured. Also a unique name for this Access Point (ap1200)
will be configured.
In the authentication, authorisation and accounting configuration parameters (AAA), at least one group needs to
be defined (radsrv), which will be assigned later for the several AAA operations. More groups can be defined if
needed for various purposes; one for authentication, another for accounting, and so on. In this example the
RADIUS server has the IP address 192.168.10.253.
Configuring the SSIDs
For each SSID one dot11 ssid <SSID NAME> must be configured. In this section the default VLAN for the SSID
will be configured as well as the authentication framework, the accounting and, if desired, the SSID to be
More SSIDs can be configured. An open SSID for giving information about the institution and/or how to
connect to the eduroam SSID:
The Radio Interface
Now the configured SSID's will be mapped to the radio interface, and it will be specified what ciphers will be
used/allowed on each VLAN. If dynamic VLANs are planned, the ciphers for those VLANs must also be
configured even if there is no direct mapping on any SSID (this example shows the usage of the VLANs 906
and 909 for eduroam users)
To bind extra SSID's the previous command, for each SSID to be bound, needs to be repeated.
The following command sets the maximum time (e.g. 300 seconds, which is recommended) for
For each VLAN to be used for wireless clients, two virtual interfaces need to be defined: one on "the air"
(DotRadio) and another on the "wire" (FastEthernet) then they need to be bridged together with the same
bridge group. These VLANs are always tagged with the proper VLAN identifier.
An administrative VLAN needs to be configured as well (for maintenance/management and
authentication/accounting traffic). This VLAN is usually untagged (the command defining the VLAN has to be
suffixed with the keyword "native") and belongs to bridge-group 1. The Radio virtual interface for this VLAN
does not need to be defined since the default will keep the physical interface (Dot Radio 0) in bridge-group 1.
Because VLANs can be from 1 to 4094 and bridge-groups from 1 to 255, it is not necessary to have the same
bridge-group id as the vlan id.
The multiple (dynamic) VLAN assignment
The example configuration above did not configure dynamic VLAN assignment. Availability of this feature varies between models of the 1200 Series, so please exercise caution when procuring if you wish to make use of this feature. If multiple VLANs are configured on the Cisco AP, it is mandatory to associate each SSID to at least one VLAN, otherwise the Access Point will not activate the SSID's. It is possible however, to put different users who are connected to the same SSID (e.g. eduroam) on different VLANs based, for instance, on the user profile. To activate this feature it is necessary to enter
in the Access Point's configuration. The AP then gives priority to the VLANs returned by RADIUS over the ones statically associated with the SSID. This enables the feature dynamic VLAN assignment.
Cisco's Access Points require that two virtual interfaces (a radio and an Ethernet port interface) are configured for each VLAN. If, for example, four VLANs are to be used for eduroam users (for students, admin staff, teachers and visiting eduroam users from other institutions for example) then it is necessary to define one Dot11Radio0.vlanID, and one FastEthernet0.vlanID, and ensure that both have the same encapsulation dot1Q vlanID and the same bridge-group for each VLAN.
Two commands that are also needed are the below, otherwise the access point will not change the user to the received VLAN:
The required configuration can be downloaded as a file fromhttp://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip. You must then amend the file as indicated by the comments in the file, and then copy and paste the commands into the Access Point in configuration mode (telnet or console access).
(obsolete section) Appendix A: RADIUS servers
As the eduroam infrastructure is build upon RADIUS servers, the following picture depicting the message flow
inside an institutional RADIUS server might be helpful.
Figure A 1: Message flow in RADIUS server Identity Management System
A.2.6 User authentication: configuring an eduroam IdP
Configuring an IdP involves:
- Configuring the server as EAP endpoint.
- Configuring the local database backend.
EAP configuration happens in the file eap.conf (downloadable from
http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip). This example, eap.conf file is
configured to accept both TTLS and PEAP requests and process them with the same backend. For a
discussion of when to use TTLS and when PEAP, please refer to section 22.214.171.124 of this document. The
following notes refer to different modules within the file:
- In the tls section, the server certificate that is presented to the users while they authenticate is defined.
certdir, private_key_... have to point to the appropriate files on the server. It appears confusing for most
new administrators that tls needs to be defined even though EAP-TLS is not a desired authentication
method. This is because the ttls and peap sections share the certificate parameters and rely on the
existence of the tls stanza. Unwanted EAP-TLS authentication can be prevented by pointing cadir to a
dummy Certification Authority (like the one that is created on first server startup) which never issues
proper client certificates.
- The ttls and peap sections denominate a dedicated virtual server to handle the inner tunnel request
(which happens after the TLS handshake with the supplicant has completed). Note that there needs to
be an empty mschapv2 stanza in eap.conf to make PEAP work – this is due to internal server workings
- To include EAP into the virtual server eduroam (see section A.2.4 "Virtual server definition for eduroam:
sites-enabled/eduroam"), only two lines need to be added; the new virtual server "eduroam-innertunnel"
(which we defined in eap.conf before) needs be set up to do the actual user authentication, and
the module eap must be listed at the end of the authorise and authenticate sections.: The most notable difference between the inner server and the outer is that the inner tunnel does not do
EAP. Instead, it uses the ldap module in the authorize and authenticate sections to authenticate users
against the ldap backend. Note that the ldap module is configured in radiusd.conf. You have to enter
the appropriate connection details to your LDAP server there and open firewall ports from the RADIUS
server to the LDAP server if need be.
Also note that this virtual server does not call the suffix module. This means the inner request does not
get proxied elsewhere. This is a standard security measure in eduroam.
The virtual server definition also includes the files module. When doing LDAP authentication, this is
optional. In the example file, we use this module to have test users in the flat file "users" in order to
have a possibility of debugging authentication. Once the authentication against the file works and the
LDAP connection is set up properly, the files module is only needed for advanced topics like VLAN
• For an initial setup of the users file, administrators should delete all existing entries and add only the
following line in the file:
This creates a test user with the name "firstname.lastname@example.org" and a password. It can be used to test authentication.
- In case a VLAN assignment should be done, the users file needs to contain the corresponding RADIUS
attributes, like in the following example for VLAN 313:
- The configuration of the ldap module itself happens in radiusd.conf. This config stanza is extensively
documented in the file, so below just a simple example of a sample configuration (based on an
eduPerson LDAP schema).
- If logging of accounting requests to a database is desired (see below), it is also wise to extend the
accounting key in the acct_unique module to make accounting more robust.
A.2.7 Setting up accounting in the SQL database
All accounting information is logged into the MySQL database. The configuration is in the file
/etc/raddb/sql.conf. The content of this file should be replaced with that found in http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip.
A.2.8 Logging the client IP address as Service Provider (Optional)
The client IP address is logged in the DHCP log file. However this information can also be stored in the
ACCOUNTING table with other accounting data and thus provide easy access to that data. A Sysadmin needs
to set-up a script to update the SQL database information with the assigned IP address. The client IP address
is determined by tailing the DHCP log file and monitoring all IP assignments. The script also monitors active
connections and cleans up accounting (closes accounting) for stale connections. SNMP access to Access
Points is required.
The script is available from here: http://www.eduroam.si/uploads/CN/eC/CNeCC3Uc7XI9Tw_dLtwYZg/eduroam_monitor-20060809.tar.bz2
The access points need to be registered with the script. This is done by entering the needed access point data
into the database:
create table access_points (
`IP address` varchar(100) PRIMARY KEY NOT NULL,
`snmp secret` varchar(100) NOT NULL default '',
`radius secret` varchar(100) NOT NULL default '',
`root username` varchar(100) NOT NULL default '',
`root password` varchar(100) NOT NULL default ''
A.2.9 More information
The original Slovenian Eduroam technical specifications and sample configuration site:http://www.eduroam.si
ARNES AAI technical support e-mail address: email@example.com
Eduroam-in-a-box web configuration tool:http://eduroam.sourceforge.net
(obsolete section) Appendix B: Access Points
This section describes the configuration of the Access Points:
- Cisco Aironet 1200 series.
- Lancom L-54.
These Access Points have been used extensively by JRA5 activity members, and so their configuration and
suitability for eduroam are well established.
B.1 Cisco Aironet 1200 Series example setup
The required configuration can be downloaded as a file fromhttp://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip. You must then amend the file as
indicated by the comments in the file, and then copy and paste the commands into the Access Point in
configuration mode (telnet or console access).
B.2 LANCOM L-54 Series Access Points
This series of Access Points offers a wide range of features for a mid-range price. One of the outstanding features in its price class is the ability to use ARP sniffing to determine a client's IP address even if it changes during a user session. Activating this feature fulfils the requirement for MAC to IP correlation from the confederation policy and obsoletes logging of DHCP leases.
The following steps are needed to set up eduroam on a Lancom L-54 or L-300 series access point. It describes the setup via the web interface and is current as of LCOS Version 8.0. The starting point of this tutorial is a factory-reset device, i.e. it is not configured at all and set up to its defaults.
Many operating systems support IEEE 802.1X and EAP authentication, but the user interfaces in supplicants differ significantly. For some supplicants, manually clicking through a series of GUI pages is the only option. This is sometimes tedious for end users.
If possible, an IdP administrator should prepare pre-configured packages which contain the necessary information to securely connect to eduroam:
- the SSID: "eduroam"
- the crypto setting: WPA2/AES
- the EAP type setting
- the CA that issued the eduroam IdP server's EAP server certificate
- the Common Name in the eduroam IdP server's EAP server certificate
The following sections describe a series of tools that can be used to create such auto-installers. The use of one these windows 10 drivers update is recommended, because it will likely have a positive effect on user uptake, and reduce helpdesk load.
PLEASE ADD TEXT
PLEASE ADD TEXT
PLEASE ADD TEXT
Devices that are compatible with eduroam
The following list is sorted alphabetically by vendors. The table notes which EAP methods are supported. Legend:
CAT - this device/EAP type combination is supported by eduroam CAT; can probably also be configured securely manually
Yes - the device can be configured securely manually for this EAP type
Deficient - the device lacks important security features, but workarounds exist which can make its use safe
Insecure - the device can be configured manually for this EAP type, but not all security parameters can be set up
No - device is known not to support IEEE 802.1X/EAP
? - Unknown
TPS - supported with Third-Party Software (possibly commercial)
Samsung Galaxy S2
Huawei Sonic u8650
|Apple||Mac OS X||10.7+||CAT||CAT||CAT||Yes||No||?||Yes|
|Apple||Mac OS X||10.4-10.6||Yes||Yes||Yes||Yes||No||?||Yes|
|Microsoft||Windows||8 / 8.1||CAT||CAT||CAT||CAT||CAT||?|
 Installation and pinpointing of CA possible; verification of expected server name (CN) not possible. A secure configuration is only possible if the Identity Provider deploys a private CA which issues exclusively server certificates for his own eduroam EAP servers. All other Identity Provider deployments are INSECURE.
 Version 1.0 or higher required
 Verifying that the server is signed by the proper CA is not possible; this means users will not be able to detect fake hotspots and might send their username/password to an unauthorised third party.
 Only with 10.6.x (Snow Leopard) and later does OSX allow the configuration of of CA/server trust settings (Pinning 802.1X to specific CA and RADIUS server CommonName)
Reporting a new device
Please let us know in the "Comments" field what device you have, and what EAP method(s) you have found working. We will update the list periodically.