Filtering non-realm usernames from eduroam
Introduction
The eduroam network globally requires the use of usernames in the so-called Network Access Identifier (NAI) format. This format requires usernames to conform to a [userID]@[realm.tld] syntax. The purpose of this format is that the realm.tld element to the right-hand side of the @-sign is used to route the usernames to the appropriate organisation’s servers to be authenticated. The lack of a realm.tld element effectively requires the national or the organisational proxy to reject the request because it is known that such a request cannot be routed.
One of the biggest issues that the eduroam network globally faces is the proliferation of non-realm usernames, i.e. usernames that do not conform to the NAI format. Examples are below:
fred.bloggsbloemDOMAIN\fredbloemrealm!fredbloemU0123456S01234567host/hostname.ds.university.nl
As can be seen by the examples, none of these contains the crucial @-sign , and thus none should not be sent upstream to the national proxies. Permitting your users to connect to eduroam on campus or at their student accommodation handled by your own RADIUS servers using a non-realm username will only lead to a bad user experience when your users doing so attempt to roam off-site (like at other institutions in your location or even abroad) because the realm-less username cannot be routed by those other institutions.
This means that you must reject any requests not containing a realm element outright to enforce the NAI format, even if they are your own users. This should effectively drive the user to the help desk or the student help pages, and your eduroam documentation should explain clearly why the NAI format is necessary. With appropriate tools and settings (such as the eduroam CAT and the geteduroam app togetherApp together), enforce the correct format from the start and reduce future calls to the help desk from off-site roamers (or roamers at student accommodation facilities where eduroam is provided by a third party).
For EAP-TLS (certificate-based) authentications, the certificate subject should either contain the commonName (CN) portion of the subject in a NAI format, e.g. ‘fred.bloem@university.nl’ or ‘hostname@ds.university.nl’, or the appropriate tools provisioning such certificates onto users’ devices must be configured to provide an identity that is in the correct NAI format. The former is preferred.
Instructions
Most RADIUS server software will support a regular expression (regex) in its configuration. Notably, FreeRADIUS, Radiator, Radsecproxy, Cisco Identity Services Engine (ISE) and Aruba ClearPass do this in either their configuration language, their policy, or their rules. The aforementioned RADIUS products/packages also allow for negative matches, i.e. their configuration language, policies or rules allow the negation of a regex match.
...
The following instructions will contain rough descriptions of FreeRADIUS, Radiator, and Radsecproxy configuration blocks, which can also be applied to Cisco ISE and Aruba ClearPass as appropriate. The instructions will also contain appropriate instructions for NPS.
FreeRADIUS
FreeRADIUS 3.x contains a policy called ‘filter‘filter_username’ username’ in the ‘policy‘policy.d/filter’ filter’ file in the main FreeRADIUS configuration directory. While this policy checks for the most common errors, newer versions of the file do not check for the absence of a realm element. Instead, you may wish to amend the filter file to add this additional policy function:
...
Adjust this condition as appropriate for your local style/format, or for the appropriate WLAN equipment attribute that contains the SSID name.
Radsecproxy
radsecproxy uses a very simple format in its configuration, but it does not support multiple conditions, so a set of simple conditions that applies to all requests has to do:
...
The first condition will specifically only send requests that match the particular format to the eduroam roaming servers, while the condition following will catch all others and reject the requests with the appropriate user message. You can insert any other conditions in between these two realm entries to handle other specific conditions.
Radiator
The Radiator commercial product uses a similar format as radsecproxy, but it does match multiple conditions, a simple format to try is this:
| Code Block | ||
|---|---|---|
| ||
<Handler Realm = /@{1}[-a-zA-Z0-9_]+(\.[-a-zA-Z0-9_]+)+$/, Called-Station-Id = /\:eduroam$/ >
Identifier eduroam-visitors
AuthLog AUTHLOG
AccountingHandled
AuthBy Proxy-To-eduroamUKeduroam
</Handler>
<Handler User-Name = /[^\@]/, Called-Station-Id = /\:eduroam$/ >
AuthLog AUTHLOG
<AuthBy INTERNAL>
AuthResult REJECT
RejectReason Rejected: No @ in User-Name
</AuthBy>
</Handler> |
...
<Realm = /@{1}[-a-zA-Z0-9_]+(\.[-a-zA-Z0-9_]+)+$/ >
Cisco ISE and Aruba ClearPass
Cisco ISE and Aruba ClearPass allow you to specify conditions within their rule sets to use matching and non-matching conditions.
...
NOTE: Aruba ClearPass does case-sensitive matches for regular expressions. This includes matches for your own realms. In this case, please turn your matches into case-insensitive matches by adding (?i) in front of the regular expression (as is already the case in the examples above). This reduces accidental loops that pass realm requests from your own users to the FLR when the username (and/or realm) is not entirely in lower-case.
Microsoft NPS
In NPS, a default Connection Request Policy called 'Use Windows authentication for all users' exists.
...