skip to content

IT Help and Support

University Information Services

University Information Services (UIS) operates a RADIUS infrastructure for the purpose of authenticating, authorising and accounting network access requests. This service is federated with eduroam(UK) which is, in turn, linked to the international eduroam federation. Access to the RADIUS service is available to University and College institutions running their own internal RADIUS proxies and servers.

The service is also used by institutions using the University Wireless Service with a locally-bridged SSID: the institution must set up a server peering.

This page explains the RADIUS infrastructure, how it interfaces with other systems (within the UIS, to university institutions and outside the university) and how it can be used by institutions to control network access. A degree of familiarity with RADIUS and associated protocols (e.g. EAP) is required to understand some of the information explained here.



The RADIUS service is provided by a pair of servers running the FreeRADIUS open-source RADIUS server software. These servers perform two main functions:

  • Authenticate and Authorise access for local Cambridge users from both local and remote locations (e.g. from another eduroam-enabled site) against the Network Access Tokens database.
  • Proxy authorisation requests to other RADIUS servers, both inside and outside the university network, for remote users visiting the university (or users from institutions within the university with their own authentication database).

To perform these functions, the RADIUS servers maintain relationships with other RADIUS-capable devices:

  • Clients from inside and outside the university send messages to the servers to request that a connection is authenticated and authorised; these may be handled locally (for usernames) or proxied on to other servers.
  • Servers handle requests for authentication and authorisation from the UIS servers on behalf of clients for remote users (usernames NOT - either institutions within the university [] or outside the university) to the eduroam network.
  • Proxies pass requests from clients on to other servers or even other proxies.  A client doesn't need to know that the server it is sending to is actually going to proxy the request to another server or proxy.

A particular server can perform one, two or all of the above functions.  Institutional RADIUS servers are typically only clients, whereas the UIS RADIUS servers are all three.

The following diagram illustrates how the UIS RADIUS infrastructure interfaces to other systems:

University of Cambridge RADIUS
infrastructure diagram

(click on the image for a larger version)

RADIUS has inherent redundancy when multiple servers are configured: a RADIUS client, such as an institutional RADIUS server or wireless access point, will automatically detect failed upstream RADIUS servers and resend the request to the remaining available server(s). Periodically, the client will retest the connection to the server, and reestablish it when it become available again.  RADIUS clients can also send periodic status requests to servers or proxies, to determine if they are up or down.

Network Access Tokens database

To provide the backend authentication and authorisation for usernames, a pair of servers hold the Network Access Tokens database. Accounts for users are automatically created upon their first visit to the network authentication token website, which is protected by Raven; there is no need to explicitly apply for a separate account.

The database itself is only accessible to the UIS RADIUS servers; these take requests from RADIUS clients (as described here) to authenticate user access. Direct access to the database from other services is not permitted.

Information on configuring devices for connection using these accounts is available on the eduroam for Cambridge users page, along with generic information about supported authentication types.

Wireless visitor tickets realm

In addition to the realm for local users, visitor tickets created in the University Wireless System Console can be authenticated by the RADIUS service.  Tickets are connected in at the '' realm and can be supplied either with or without the separating hyphens - for example either or both of '' and '' can be used to authenticate ticket '123-456-789'.  The ticket password can be authenticated via PAP or any of the normal password-based EAP methods (e.g. EAP/PEAP or EAP-TTLS/MS-CHAP-V2).

The validity dates for a ticket, as well as setting and respecting the 'valid days' value is handled automatically and interchangeably with the University Wireless Service.  If a ticket is invalid due to expiry, the access request will be rejected without further details by the RADIUS service.

Institutions may use this service to allow visitors to authenticate via a local eduroam service.

The supported authentication types and security configuration instructions for client devices are the same as for the Network Access Tokens (in

University Wireless System visitor tickets are only available for authentication from inside Cambridge; if an attempt is made to use one from outside Cambridge, the access request will be rejected.

Note: for legacy reasons, the '' realm is still supported and equivalent to ''.  Both end users and institutional IT staff are advised to migrate to the new '' domain as the old realm will be shut down in the near future.


Any institution wishing to make use of the RADIUS service to provide access for local (university) or external users must run its own RADIUS proxies, which will relay authentication and authorisation messages from their own access points and network switches up to the UIS servers.

The institution should contact  with the following information:

  • The hostnames of their internal RADIUS servers (which can be on public or UDN-wide private IP addresses).  Usually, a maximum of three RADIUS servers can be nominated per institution.
  • Whether IPv4 and/or IPv6 will be used by the institutional servers to talk to the UIS servers.

The UIS will then allocate a unique shared secret passphrase for each server-client pair (so, with three institutional RADIUS servers and two UIS RADIUS servers, there will be a total of six shared secrets) and these will be returned to the institution.  The UIS servers will be configured to accept requests from the IP addresses supplied, using the appropriate shared secrets.

The authentication and authorisation requests will need to be configured to talk to and on UDP port 1812. Institutional firewalls must be configured to permit the outbound traffic and responses.

Service hostname IPv4 address IPv6 address 2001:630:212:8::aaa:0 2001:630:212:8::aaa:1

The UIS currently configures institutional servers by DNS name, with the IP addresses for a particular name being resolved only when the configuration is rebuilt.  This typically happens only when changes are being made to the configuration (for either that institution or another).  As such, changes to the DNS registration are likely not to take effect immediately but some undefined time later (possibly several days/weeks).

The UIS must be kept informed of any changes to the IP address or DNS name of institutional servers - if there are any problems with resolving the name and/or IP address of an institutional server, access to the UIS servers may be disabled without warning and require manual action to reinstate it.

Note: proxying of accounting messages is deprecated in the eduroam federation and these must no longer be forwarded to the UIS servers.

Types of RADIUS client

Theoretically, an institutional wireless controller or access point could be configured as a direct client of the UIS service. However, this is discouraged for a number of reasons:

  • The institution will need to perform accounting for connections made into their network. The UIS RADIUS servers will log requests sent to them but must be relied on to produce this information for other institutions' services;
  • Local authorisation decisions (e.g. based on ESSID, interface number, etc.) cannot be handled by the UIS RADIUS servers;
  • In the future, it is likely there will be a need to amend the RADIUS requests before passing them on to the UIS servers;
  • The institution is likely to need to return custom attributes such as 'user VLAN' to the network access server; this is especially the case for wired 802.1X connections;
  • RADIUS is a complex protocol and it is necessary to have a degree of local debugging (possibly with test account provision) to determine the request sent to the UIS servers, rather than require the UIS to resolve issues with local access points or other servers.
  • It may be necessary to run test queries or other clients and not having a full proxy (which can support additional clients within the institution) may make this impossible, without setting up a separate set of proxies outside the normal chain.

It is strongly recommended that institutions use a RADIUS proxy between the Network Access Server (NAS) and the UIS RADIUS servers: in the event that local debugging logs cannot be produced or tests run, the UIS cannot typically help diagnose faults. Also, the inability of an institution to produce suitable log information is typically a violation of the eduroam terms of access and can result in the service being terminated.

Terms of access to the RADIUS service

The RADIUS service is provided exclusively for the purpose of network access: the service (both local and eduroam accounts) must not be used as a general authentication service for services such as email, filestore, websites, etc. In particular, this service must not be used to protect any personal information.

Institutions must not interfere with the authentication protocols themselves; they must not perform activities such as local EAP termination.  The secure tunnel providing the exchange of password and inner tunnel attributes must be maintained, end-to-end (between the user's supplicant device and the RADIUS service itself): user or other credentials must not be exposed to any intermediate system.

In addition, if the use of this service is for the local provision of university or external services (e.g. eduroam), the terms of use of those services must be adhered to.  In the case of eduroam, the eduroam(UK) Technical Specification from Jisc must be followed, including any support requirements.

Institutions must maintain appropriate levels of local logging to determine the handling of an authentication attempt.

Any violations of these rules are likely to result in client (and server) relationships between the UIS and institutional RADIUS servers being terminated. If in doubt, an institution should consult Network Support before using the service to provide any particular facility.

Operator-Name setting

When client requests are sent to the UIS servers, the RADIUS Operator-Name attribute is automatically populated with the institution's realm name, as per the eduroam specification.  This is sent back to the user's home institution to indicate the location from which they are connecting.  Institutions need not set this themselves and; if it is provided, it must equal the value defined by the UIS, else the request may be rejected.

The realm name is typically the DNS domain used by the institution (e.g. ''; the leading '1' indicates the DNS namespace is used). However, there are situations where alternate names may be used; institutions should check with the UIS about their assigned realm. The University Wireless Service uses the realm name of ''.


An institution only needs to be configured as a RADIUS server, with the UIS servers as clients, if it wishes to authenticate users itself against a local authentication database. Ordinarily, there is no need to do this as the UIS Network Access Tokens database can provide authentication for users within the university who have a Raven account.  If authorisation decisions need to made against the username, note that the UIS servers make the user's identity available in the outer-identity upon successful authentication.

However an institution will need to run its own servers, connected to a suitable backend account database, if it wishes to provide accounts to authorised users who are not eligible for a UIS-provided Network Access Token, or an alternative method of authentication is desired (such as EAP-TLS, or against an institutional user account directory).  This is also necessary for locally-bridged SSIDs on the University Wireless Service with federated authentication.

If an institution wishes for this to be configured, they should contact Network Support with the following information:

  • The hostnames of their RADIUS servers (up to a maximum of three, including any clients already allocated).
  • Whether IPv4 and/or IPv6 should be used by the UIS servers when proxying requests to the institutional servers.
  • If their RADIUS servers support the Status-Server message type.  If this is not supported, the UIS servers will be less able to detect whether an institutional server is working and may result in increased timeouts and connectivity problems for their users, when an institution suffers an outage on some of their servers.  However, if Status-Server is configured for a server which does not support it, that server can become permanently marked as down.  In this situation, the UIS servers need to be configured not to use this message.  Microsoft Windows NPS is an example of a server which does NOT support Status-Server.
  • If the institution wishes for the server(s) to be connected into the global eduroam federation and, if so:
    • The desired eduroam realm which is to follow the '@' sign in usernames. This realm must correspond to a DNS domain name to which the institution is entitled, as allocated by the UIS Institution Strategy team.  This will typically be something of the form ''.

The UIS will then supply a set of shared secret passphrases for each server-client pair (which will be the same as the corresponding ones for RADIUS client access to the UIS servers) and the UIS servers will be configured to forward all requests for that institution (ending in by their outer-identity) to the institutional RADIUS servers.

If/when the institution wishes their realm to be connected into the eduroam hierarchy, this should be stated in the request and the UIS will contact eduroam(UK) to set up the appropriate forwarding.  It should be noted that, unlike DNS domains, there is at present no automatic forwarding of subdomains to the university servers and there is a manual overhead with each additional realm.  If this is not done, the realm will only be available for authentication and authorisation from inside Cambridge.

Realm names ending in '' should be set up through the UIS RADIUS service and not directly with eduroam(UK).  This is by agreement with eduroam(UK) and a directly-configured realm will not work elsewhere in Cambridge.

The normal procedure for setting up a RADIUS home server is to first set it up internally within Cambridge and test it from another institution within Cambridge other outside the home institution (by visiting another institution, for example) and checking everything works correctly (including logging) before connecting it to the global eduroam federation.

eduroam CAT

The eduroam CAT (Configuration Assistance Tool) is a service which can provide a pre-configured installation utility for various major operating system platforms, to streamline the configuration of eduroam.  Typically, a user will simply need to download the tool, run it and enter their username and password.

The UIS already provides this tool for Network Access Tokens users, but it is also available to institutional eduroam service providers (i.e. ones with their own realm under '') to configure and offer to their users.

The procedure for providing access to this is a little convoluted and relies on an email with an activation cookie which must be used with an hour or so.  If institutions with a subrealm wish to make use of this, they should contact Network Support for more information.

Inner- and outer-identity handling

It is important to understand, when proxying RADIUS authentication and authorisation messages using EAP (used for network authentication using 802.1X over both wired and wireless connections), that requests typically have two usernames: the inner-identity and outer-identity:

  • The inner-identity is the connecting user's real username and is usually protected using SSL such that it can only be read by the user's home site RADIUS servers. The UIS RADIUS servers are the home site servers for usernames.
  • The outer-identity is the public username that the connecting user supplies to the network access server (e.g. wireless access point) and intermediate hierarchy of RADIUS proxy servers to allow them to route the request to the correct home server.

Normally the realm part of a username (the part after the '@' sign) is the same for both the inner- and outer-identity. However, the username part in the outer-identity can also be something different, to anonymise the request (e.g. ''), or even blank (e.g. just ''); the UIS recommends this is how local users configure their devices).  The inner-identity is the real username from the site, e.g. ''. This allows the visitor to hide their real identity from a visited site. In the event of misuse, matching up authentication records from the visited and home sites allows the real user to be determined.

For Cambridge users, the UIS servers require that the local part of the outer-identity must be either blank (i.e. '') OR the username (e.g. ''). If a non-blank username is supplied as the outer-identity that does not match the username in the inner-identity, the access request will fail.  This policy is such that a user can choose to keep their identity anonymous, or reveal it to an external visited site, but they cannot supply a misleading identity.

The UIS servers will rewrite the outer-identity to be the inner-identity when accepting a request for access proxied by an internal (to the university) RADIUS client for a local ( user.  This allows an institution within the university to determine the real identity of the user for authorisation and accounting purposes.  For example, a college or department may wish to use the UIS server to authenticate the user (prove they are who they say they are) but use the returned identity to authorise their access (perhaps based on a local list of valid users).

In addition to this, institutions should log the returned username from the UIS servers to streamline the process of identifying local users in response to CSIRT incidents, avoiding the need to refer the query back to UIS to determine the inner-identity.

Logging and debugging

The UIS servers log all requests received (including interim ones, as part of a multi-stage EAP authentication) and what they did with each (responded locally, in the case of usernames, rejected them due to being invalid, or proxied them on to other servers).  This is useful to debug problems with authentication.

Institutions using the service directly should configure appropriate logging on their own systems to determine what happened to an authentication request on their own systems.  Only after consulting these local logs and confirming that a particular request has been proxied to the UIS servers should they contact the UIS to investigate the problem further.

Information required to investigate logs on the UIS servers is:

  • The date(s) and time(s) of the authentication attempt.
  • The Calling-Station-Id of the supplicant (i.e. the MAC address of the connecting device), in the format used by the local NAS (e.g. colon-separated, hyphen-separated, upper- or lower-case, etc.).
  • The outer and inner identities attempted.
  • The institution where the authentication attempt is taking place.
  • The nature of the problem: timeout, Access-Reject returned (when this is unexpected, etc.
  • What is being reported in their local RADIUS proxy's logs.

It is important to note that the RADIUS service cannot actively disconnect a device from the network, nor can it affect the network connection, once a device is connected: it can only reject (or fail to respond to) an authentication attempt.  As such, if a user is reporting frequent disconnections, or there are rapid reauthentications, this is unlikely to a problem with the RADIUS service (either locally or at the UIS or wider eduroam level) but a local issue to do with the user's connection (e.g. poor WiFi).

Last updated: 9th October 2020

Phone padded  Service status line: (01223 7)67999
Website  Sign up for SMS/email status alerts
Website  Read major IT incident reports

UIS bITe-size bulletin

A regular newsletter aimed at the University's IT community, highlighting service and project news from UIS.

Sign up >

Latest news

Your University GoogleDrive: 20GB quota limit from December 2022

19 January 2022

Google is replacing its G Suite for Education model licensing model in October 2022. As a result, there will be a new limit of 20GB on personal GoogleDrive spaces provided with G Suite@Cambridge accounts. If your GoogleDrive usage exceeds 20GB after 1 December 2022, your University account GoogleDrive will become read-only until your usage is brought below 20GB.

Moodle offline for upgrade during 06:00–12:00 on Tuesday 11 January

10 January 2022

Moodle will be unavailable from 06:00 to 12:00 on Tuesday 11 January while we upgrade it to version 3.9. During the upgrade, you won’t be able to view or upload sessions on Panopto because access is managed via your Moodle login. Assessment Moodle, ICE Moodle and Clinical School Moodle users will be unaffected. An outline...

HEAT authentication method changing to Azure on 13 January

7 January 2022

We're changing the authentication method for the IT service management system, HEAT, to Microsoft Azure on Thursday 13 January 2022. What is changing? You should continue to use the same URL for accessing HEAT: However, the 'Sign in' screen you'll be directed to will look slightly different,...