Do you recognize the following web form?

If you don’t then you can stop reading. If you do then, even if you haven’t had occasion to fill it in often, please read on as there are changes coming.

Above is the registration form to permit a device (probably a NAS but could be an individual AP; these are not laptops or phones) at a given IP to make RADIUS auth and acct requests against the central Remote Access RADIUS servers, the authentication mechanism currently used for University of Oxford eduroam accounts. The page also allows you to see your existing registrations and remove them.

Over the years this web page has been given the odd spruce but its roots as a CGI Perl script (thus referred to as the “CGI version” from now on) haven’t changed and it very much is a product of its generation. They haven’t changed yet, I should say.

Ready for an imminent release is a new page that will take over the duties of the existing form. It’s still written in Perl (because Perl is the best programming language in existence) but is now not based on CGI.pm, which is probably a good thing. Here’s the new form:

Why should you care? Under normal circumstances we probably would just roll this out without much fanfare. However there are some necessary yet fundamental changes under the hood that probably will affect you. You need to know about them before we release it.

Permissions

Perhaps the largest change that will affect you is permissions. The CGI version bases its ACLs around your ITSS affiliation. If you’re ITSS for Aardvark College say, then you have permission to add an IP address. What range of IP addresses are available for you, the ITSS of Aardvark, to add? Well this system is an old system so for reasons I will elaborate shortly, any IP address within the University will be accepted, belonging to any unit. That’s not ideal. [As an aside, please do not take the opportunity to register every one of our ~130k IP addresses, for jokes. I will know who you are, and I will come find you.]

Permission to deregister is similarly done by ITSS affiliation. Here you need to be a member of the unit that was assigned to the device at registration time. This makes it awkward when another ITSS accidentally registered something on your subnet range. In this case you can neither see the registration nor delete it. I should note that to the best of my knowledge this has not come up as an issue, and please let’s keep it that way.

At the heart of the problem is the fact that when this tool was originally written (decades ago) nothing existed that mapped a subnet to a college or department. Today though, a system exists which maps University subnets to Hydra Groups in Groupstore, and each unit (college and department) has a Hydra Group associated with them. So, can we just check you are an ITSS for the Group in question and carry on as before, adding constraints that you can only add IPs belonging to your Group? No, because there is a problem:  Groupstore contains more Hydra Groups than just those affiliated with units. In addition subnets have been assigned to teams within units (small case teams, not Microsoft Teams). These Groups exist outside of OakLDAP and thus do not have any ITSS.

The solution is fairly obvious: the Hydra Groups in Groupstore contain members which we can reuse. The downside is that not everyone who is an ITSS is in their unit’s Groupstore group. In practice I do not think this list will be large, but it needs explictly saying, hence the blog post.

Perhaps now is a good place to point out that Groupstore is a rather powerful and flexible beast. Inside its belly is a large chunk of CUD and OakLDAP data, and as such if you wish to have Groups dynamically update as, for example, your ITSS membership changes, that’s a one-off configuration change. Said another way, if you wish for a Group to contain the ITSS for a particular Unit, you inherit memberships and thereafter this Group will be up-to-date and you don’t need to do anything.

Summary: CGI system uses ITSS affiliation for ACLs. New system will check for Group membership in Groupstore, and also check permissions against the IP address being registered.

Autocleaning

An overhaul of the system affords us to look at what’s not working with the current system. One thing is the proliferation of unused or abandoned registrations. We’ve made some efforts to highlight them where we can (a telltale sign is the lack of a DNS record) but it’s come to the stage when some kind of automated housekeeping is in order. Thus, with the new system, we will be removing registrations that have not contacted our central RADIUS servers within 120 days. If you wish to subsequently make use of RADIUS via that IP you will need to reregister.

In practice 120 days should be a large enough window to send something. I cannot imagine a NAS lying dormant that whole time.

Summary: Registrations will be autoremoved after 120 days of device inactivity.

Extra features

On their own, the following enhancements do not merit a blog post, but since you’re here and still reading, I will mention them:

• The new page will allow you to bulk remove registrations. Just click the [X] next to the registrations you wish to remove and then confirm at the top of the page.
• For the registration form, you will notice that there is now no option to select the unit/group. The group will be inferred based purely on the IP being registered.
• Better error messages will tell you exactly what the problem is if you add an invalid IP address
• Not relevant today, but the new system is IP version agnostic, although there are some issues currently around this still, the main one being we do not yet have a production IPv6 RADIUS service address.

Timescales

The new system is done, tested and ready for deployment. If there is any comment or question that you wish to pass on then please do get in touch via the appropriate channels. We have nominally pencilled in 30th November 2022 for the upgrade, and this is coordinated in CR#20015059

Conclusion

To restate the summaries above:

• RADIUS deviceauth registration currently uses ITSS affiliation for its ACLs. The new system will check for Group membership in Groupstore, and also check permissions against the IP address being registered.
• Registrations will be autoremoved after 120 days of device inactivity.

These are minor, but visible changes so please do make a note of them and update your Groupstore Groups accordingly.