skip to content

IT Help and Support

University Information Services

Who is this for

This page is for IT staff working at the University who are familiar with RADIUS and associated protocols, such as EAP. It explains:

  • the University RADIUS infrastructure
  • how it interfaces with other systems within UIS, to university institutions and outside the university
  • how it can be used by institutions to control network access

This page is not intended for end users. For more information on configuring end user devices, see the eduroam setup instructions.


What is RADIUS

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.


What this information covers



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

  • Authenticate and authorise access for local Cambridge users from both local and remote locations (for example, 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 to the eduroam network. Remote users include usernames that do not include, institutions within the university ( or users from outside the university.
  • 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:

(Select 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 servers. Periodically, the client will retest the connection to the server, and re-establish it when it becomes 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 managed on the network authentication token website, which is protected by University of Cambridge single sign-on (formerly Raven). There is no need to explicitly apply for a separate account.

The database itself is only directly accessible to the UIS RADIUS servers, these take requests from RADIUS clients (as described here) to authenticate user access. 

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.



A RADIUS client is either another RADIUS server/proxy or a NAC (Network Access Control) device such as a switch or wireless system. An end user device is known in RADIUS as a supplicant and talks to the RADIUS server through the NAC.

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 either of both IPv4 and 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. For example, with 3 institutional RADIUS servers and 2 UIS RADIUS servers, there will be a total of 6 shared secrets. These secret passphrases 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 sent to and on UDP port 1812. They must use some method of load sharing when forwarding messages upstream (but ensure that a particular authentication sequence is passed to the same upstream server, consistently), rather than using one server exclusively, unless failover in a fault condition. Institutional firewalls must be configured to permit the outbound traffic and responses.

  • IPv4 address:
  • IPv6 address: 2001:630:212:8::aaa:0

  • IPv4 address:
  • IPv6 address: 2001:630:212:8::aaa:1

UIS currently configures institutional clients 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 could take several days or weeks.

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 either or both the name and IP address of an institutional server, access to UIS servers may be disabled without warning and require manual action to reinstate it.

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 NAC could be configured as a direct client of the UIS service. This is discouraged for a number of reasons:

  • The institution will need to perform accounting for connections made into their network. 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 (for example, based on ESSID or interface number) cannot be handled by UIS RADIUS servers.
  • In the future, it is likely there will be a need to amend the RADIUS requests before passing them on to 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 UIS RADIUS servers. In the event that local debugging logs cannot be produced or tests run, UIS cannot typically help diagnose faults. If institutions are unable to produce suitable log information this 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 or websites, etc. This service must not be used to protect any personal information.

Institutions must not interfere with the authentication protocols themselves, for example 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.

If the service will be used for the local provision of university or external services, such as 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 UIS Networks 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 should not set this themselves, If this attribute is provided, it must match the value defined by UIS, otherwise the request may be rejected.

The realm name is typically the DNS domain used by the institution, for example ''. The leading '1' indicates the DNS namespace is used. However, there are situations where alternate names may be used. Institutions should check with 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 University account (formerly Raven).  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.

An institution will, however 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 UIS Networks with the following information:

  • The hostnames of their RADIUS servers (up to a maximum of 3, including any clients already allocated).
  • Whether either or both IPv4 and 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, UIS servers will be less able to detect whether an institutional server is working. It 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 that does not support Status-Server.
  • If the institution wishes for the servers 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 UIS' Institution Strategy team.  This will typically be something of the form ''.

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

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, 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 2 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 (such as, 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 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 (such as ''), or even blank (e.g. just ''). UIS recommends this is how local users configure their devices. The inner-identity is the real username from the site, for example, ''. 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 (such as '') or the username (such as ''). 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 be rejected.  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. This avoids the need to refer the query back to UIS to determine the inner-identity.


Logging and debugging

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 UIS to investigate the problem further.

Information required to investigate logs on UIS servers is:

  • The dates and times of the authentication attempt.
  • The Calling-Station-Id of the supplicant (such as the MAC address of the connecting device), in the format used by the local NAS (for example, colon-separated, hyphen-separated, uppercase or lowercase).
  • The outer (in the case of local users) and inner identities attempted.
  • The institution where the authentication attempt is taking place.
  • The nature of the problem, for example, timeout, Access-Reject returned when this is unexpected.
  • What is being reported in their local RADIUS proxy's logs.

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.  If a user is reporting frequent disconnections, or there are rapid reauthentications, this is unlikely to a problem with the RADIUS service. It is more likely to be a local issue to do with the user's connection such as poor wifi.

Last updated: April 2023