You may be aware that the University of Oxford will shortly be mandating fully qualified usernames for eduroam, explained and for reasons discussed in a previous blog post. This post is intended as a followup, highlighting how we’re intending on enforcing it and helping to reassure ITSS with fears about the impending change.
How is this change enforced just for eduroam?
Technically the remote authentication is not a service as defined in the IT Services service catalogue. However we cannot just unplug our RADIUS servers because that will take out the eduroam service which most definitely is in the catalogue. Said in a less tactful way, using the central RADIUS servers for anything other than eduroam is not covered under any SLA and this change could in principle be a blanket change for all services which depend on remote access password authentication. Of course this is the real world and we’re aware of a number of colleges and departments making use of remote access accounts for their own SSIDs.
The question that I’m surprised nobody (as of today [a Tuesday]) has asked us is “will this impending change affect these other SSIDs?” If you’re not one for rambling blog posts I can say now that no, this change will not affect other SSIDs.
How does the central RADIUS server know which SSID was connected to?
In a RADIUS packet is an attribute called “Called-Station-Id”, its value usually looks something like “01-02-03-04-05-06:eduroam”. You can probably guess that what comes after the colon is the SSID.
Using this attribute and the User-Name attribute, this is how we’re rejecting users without a realm, in our FreeRADIUS2 configuration:
if( "%{Called-Station-Id}" =~ /:eduroam$/ && "%{User-Name}" !~ /@/ ) {
update reply {
Reply-Message = "missing @ before realm"
}
reject
}
But my proxying NAS is not appending :eduroam to the “Called-Station-Id”. What will happen?
In your case we will not be able to enforce the fully qualified username and you will still be able to authenticate without a realm. I am certain that there are eduroam setups out there which do not do this. Instead these access points and controllers send attributes like “Aruba-Essid-Name”. We will not be acknowledging proprietary attributes and we would like to make an impassioned plea to custodians of affected controllers (Aruba controllers is one notable offender) to configure them to support RFC 3580. If you don’t the experience may be confusing for end users. Aruba has something on their community forum with the steps required.
I’m manually appending :eduroam to the Called-Station-Id but it isn’t for eduroam. How do I exempt myself from the change?
Why on earth would you be doing that?
Which username will need changing, the inner or outer?
The inner username, if it works currently, will not require changing. We will only be enforcing the change on the outer identity.
Has the communication with end users been effective?
Yes. Before the initial email was sent to relevant users, 30% of devices were unqualified. It is closer to 20% after three weeks.
Conclusion
There isn’t any conclusion, but please please please ensure your Called-Station-Id attributes contain an SSID where appropriate.