Frodo Upgrades 2019

FroDo Comware Upgrade

We would like to announce a staged upgrade of the version of Comware running on our HPE 5510 and 5940 FroDos. This blog entry aims to answer the majority of questions that this work will raise. Please, however, feel free to contact the Networks team with any further questions at networks@it.ox.ac.uk

NOTE: This does not include upgrading the dcdist FroDos – these will be upgraded as a separate task in due course.

Why?

As part of ongoing maintenance it is essential that we keep our FroDo software up to date. The new versions of software being deployed address a number of vulnerabilities and bugs. For those interested this upgrade takes us from R1309P06 to R1311P02 for HPE 5510 devices and R2612H01 to R2702 for HPE 5940s. In total this change involves over 330 devices.

Addressed Vulnerabilities

201811140403

  • Symptom: CVE-2018-15473

Condition: OpenSSH is prone to a user-enumeration vulnerability. An attacker may leverage this issue to harvest valid user accounts, which may aid in brute-force attacks. OpenSSH through 7.7 are vulnerable; other versions may also be affected.

 

Information about the detail of vulnerabilities can be found at https://cve.mitre.org/cve/search_cve_list.html

 

Impact

The expected impact is ~5-10 minutes for Option 1 customers during which time the FroDo will reload and external services will not be available. For Option 2 customers the impact is expected to be minimal thanks to the In Service Software Upgrade (ISSU) capability.

We will be carrying out the upgrades between 06:30 and 08:00 to minimise impact.

Timescale

We plan to upgrade approximately 80 FroDo’s on each of the following days:

Group A: Thursday 19th September
Group B: Tuesday 24th September
Group C: Thursday 26th September
Group D: Tuesday 1st October

Schedule

 

We have attempted, where possible, to group devices around main sites and annexes so that those sites will only see one period of disruption from this upgrade schedule. Detailed schedules listing devices and dates can be found at https://docs.ntg.ox.ac.uk/pub/reference/odin-frodo-software-upgrade-september-october-2019

 

Once again, if you have any further queries then please contact us at networks@it.ox.ac.uk

 

Posted in Uncategorized | Comments Off on Frodo Upgrades 2019

What happens to mail you mark as spam?

This blog post hasn’t spun out of any particular instance, but I sometimes get the feeling that clicking the “Mark as SPAM” button in a mail client isn’t completely understood by everyone, which isn’t surprising as everything that follows is what could happen rather than what actually does happen. These scenarios are up to a combination of sending domain and receiving domain policies to bring into force. The take-home message should be to not mark legitimate emails as SPAM. If it’s a mailing list, then unsubscribe; if it’s a hot email thread involving your co-workers, create an inbox rule to mute the thread; if it’s incessant “shared” emails from a relative ask them to stop!

Without further ado, this is what could happen if you mark an email as SPAM:

The email gets deleted in your mailbox

The starter for 10; there’s little point in you marking an email as SPAM if it didn’t get removed from your INBOX. I’m sure many people have clicking the SPAM button and the Delete button as equivalent actions. One particularly nasty UI decision of a web based mail client once required a single click to mark an email as spam, but two to delete the email. Of course people took the path of less resistance and clicked the SPAM button rather than the delete button, which wasn’t great because of the scenarios that follow.

The sending domain/server gets blocked or similar emails to other recipients get emails sent to junk

One person’s SPAM is another person’s genuine enhancement pills newsletter. OK, an email advertising stamina enhancing drugs is perhaps a silly example, but if you’re getting regular emails from a mailing list, you may be doing a disservice to other subscribers who want to receive these emails when you mark them as SPAM. Some mail providers handle this better than others, but there is a risk that if you mark an email as spam when it isn’t, other’s will not receive the email into their INBOX.

Postmaster may get a copy of your email

This is probably the least known aspect of SPAM management. When you mark an email as such, the sending domain potentially has the ability to request information about the spam message, including the full message’s contents. You will have to read the T&Cs of your mail provider, but I wouldn’t be surprised if yours has a clause saying that mail you marked as SPAM has different privacy levels as your legitimate mail.

How does this forwarding back to the sending domain happen? This varies based on receiving domain. Using Microsoft as an example of how you can do it, they have a Junk Mail Reporting Program (JMRP) where you can enroll your sending servers. Any email marked as spam that was sent from these servers is sent a copy to a configurable email address.

Now that the sending server has a copy of the “SPAM”, how is it analyzed? I’ll leave that to your imagination, but not every company has the ability to use just artificial intelligence. Some human interaction may be involved.

Conclusion

Don’t mark genuine email as SPAM! It’s in everyone’s interest.

Posted in Uncategorized | Comments Off on What happens to mail you mark as spam?

The Clam Closes

We use a lot of open source software in our team and we try to contribute a little back to the community when we can.  The central mail relay, Oxmail, had been using ClamAV since sometime between 2003 and 2005 and when we discovered that we could host a public mirror of the signature databases we set one up in 2007.

This was an apache vhost on our team webserver running on a trusty IBM eServer xSeries 336.  That server was only recently decommissioned after having given 12 years of faultless production service.  In 2013, the mirror was moved to a dedicated webserver running in a VM.

The ClamAV project was acquired by Sourcefire in 2007, which itself was acquired by Cisco in 2013.  Over the summer, Cisco changed the DNS records that clients should use to find a mirror to point to Cloudflare’s content delivery network.  Our mirror still received thousands of hits per day from clients that had presumably hard-coded our mirror’s IP address in their config.  We recently learnt that Cisco had silently stopped updating the signature databases on volunteer mirrors and so our mirror was serving stale data.  We considered it better to stop serving altogether rather than to give clients out-of-date signatures and so switched off our mirror today.

In our busiest month over the past 11 years of service, our mirror served up 17 TB of data at a peak transfer rate of 8 Gb/s.

Posted in Services | Tagged , | Comments Off on The Clam Closes

September 2018 – Odin 5940 FroDo Comware Upgrade – Additional full reboots required

From both my last post and my colleague Rob Perkins’ previous post, you’ll see that we’ve had some fun and games recently with updating the software on the FroDos provisioned on the HPE 5940 platform.

Whilst these FroDos represent a relatively small proportion of the Odin FroDo estate (<10%), this has been enough to create a reasonable amount of work for us (and I imagine for you as ITSS also). Sadly this has also resulted in unplanned and unavoidable disruptions to Odin service for affected customers. For this we can only sincerely apologise and rest assured, we are feeding all of this back to HPE in an effort to improve the situation moving forward.

It should perhaps be noted that the vast majority of customers on the HPE 5510 platform (which also happens to be currently undergoing a software update – see my colleague Mike’s post) would not have been subject to the unplanned disruptions mentioned in this post.

 

So what went wrong?

Essentially nothing from a hard-line technical perspective. The update involves both a main code update and a ‘hot’ patch (the latter of these we were provided with by HPE support to fix numerous issues which are documented in our previous posts). There’s nothing particularly extraordinary about any of that.

However what is unusual perhaps, is that the (so called) hot patch actually addresses some resource issues we’ve been seeing with this platform which involves re-juggling TCAM memory allocation on the switch. This is to allocate more resources in favour of some features which were struggling before in our implementation (control plane stuff like PIM multicast routing and OSPFv3 for instance) away from others which we aren’t using.

What we didn’t know until during the update process and as part of the support cases we subsequently opened with HPE, was that only a full reboot would complete the upgrade properly. Sadly it also seems that HPE hadn’t documented this clearly in their release notes which we are working with them to resolve.

Because the aforementioned additional reboot in general hasn’t happened during the upgrades so far, the L2 annexe VSI connectivity problem some units have observed and other issues we’ve seen so far are the result of a lack of resources. This issue can only be resolved permanently via the full reboot.

 

What do you mean ‘full’ reboot?

So a full reboot in this context is a reload of all switches involved in an Odin FroDo provision simultaneously.

This means in practice that regardless of whether your unit opted for Odin provisioning options 0-1 (you have only one switch operating as your FroDo) or if you opted for option 2 (you have two switches logically operating together in an IRF to act as one for resiliency purposes), your 5940 FroDo (or FroDo pair) will be down entirely during the reboot cycle. For option 2 customers this is a rare event as most upgrades can be carried out using the In-Service Software Update (ISSU) capability (as was our original intention with this one).

If you’re unsure of what your unit opted for, then you can check via the Huginn portal here.

If you’re still unclear about what the Odin provisioning options are, or what they mean, you should consult the Odin SLD and associated information here.

 

So what’s the plan moving forward?

A small number of 5940 FroDos have had their upgrade and full reboots already.

The remaining ones will need to have their full reboot and this is scheduled as follows:

Thursday 11th October
frodo-030809    dcdist-br           - 7.00am
frodo-100907    welcome-trust       - 7.00am
frodo-120601    beach-2             - 7.30am
frodo-100909    orcrb-2             - 7.30am
 
Tuesday 16th October
frodo-120809    dcdist-usdc         - 7.00am
frodo-120810    molecular-medicine  - 7.00am
frodo-030811    dcdist-osney        - 7.30am

Impact

The expected outage whilst each reboot completes is approximately 10 minutes.

 

Is this really necessary?

Unfortunately yes. We’ve weighed up the potential consequences of doing nothing vs undertaking the additional reboots and we just aren’t comfortable with the former. This is because doing nothing has the potential to introduce difficult to diagnose issues resulting from potential TCAM exhaustion later on.

Posted in Uncategorized | Comments Off on September 2018 – Odin 5940 FroDo Comware Upgrade – Additional full reboots required

September 2018 – Odin 5940 Frodo Upgrade – Take 2

Odin 5940 FroDo Comware Upgrade (reattempt)

We would like to announce a staged upgrade of the version of Comware running on our HPE 5940 FroDos for those that were not completed last time around. This blog entry aims to answer the majority of questions that this work will raise. Please, feel free to contact the Networks team with any further questions at networks@it.ox.ac.uk

What Happened Last time & Remediation Steps Moving Forward

Essentially we encountered an unexpected issue the last time around with unit L2 annexe connectivity not being re-established following the application of a hot patch which is part of the upgrade. This is strange as the MAC learning continues to work which initially gave us the impression last time around that all was well. This issue is logged as a support case with our vendor HPE and unfortunately to date, they’ve been unable to replicate the issue we had. We’ll therefore be seeking their availability on a remote session for at least one option 1 and option 2 upgrade to ensure that if the issue recurs we can get their eyeballs on to it.

In the meantime, we have a workaround which is to ‘turn it off and turn it on again’. Seriously, should the issue recur the workaround is to shut down the L2VPN Virtual Switching Instance (VSI) serving the annexe connection on the affected FroDo and then re-enable it which we’ll do in instances should it proves necessary to re-establish connectivity post-upgrade.

Why?

I shan’t be repeating what Rob Perkins said in his original post. If you’d like to know why this upgrade is needed, please read his original post here.

Impact

The expected impact is ~5-10 minutes for Option 1 customers during which time the FroDo will reload and external services will not be available. For Option 2 customers the impact is expected to be minimal thanks to the In Service Software Upgrade (ISSU) capability.

Because we wish to get this completed before the start of Michaelmas term, we will be carrying out the upgrades as per the  accelerated schedule below. Please accept our apologies for any inconvenience caused by these upgrades.

Timescale

Thursday 20th September
frodo-120601 beach-2 - 7.30am
frodo-120809 dcdist-usdc (option 2) - 8.00am

Tuesday 25th September
frodo-120810 molecular-medicine - 7.00am
frodo-050909 dcdist-beg (formerly begbroke-iat-1 - option 2) - 7.30am

Wednesday 26th September
frodo-120812 john-radcliffe-3 - 7.00am
frodo-100908 richard-doll (option 2) - 7.30am
frodo-120811 big-data-institute (option 2) - 8.00am

 

Posted in Uncategorized | Comments Off on September 2018 – Odin 5940 Frodo Upgrade – Take 2

September 2018 Odin FroDo Upgrade

FroDo Comware Upgrade

We would like to announce a staged upgrade of the version of Comware running on our HPE 5510 FroDos. This blog entry aims to answer the majority of questions that this work will raise. Please, however,  feel free to contact the Networks team with any further questions at networks@it.ox.ac.uk

Why?

As part of ongoing maintenance it is essential that we keep our FroDo software up to date. The new version of software being deployed addresses a number of vulnerabilities and bugs. For those interested this upgrade takes us from R1309 to R1309 P06 and involves over 300 devices.

Relevant Bug Fixes

201806290399
• Symptom: The value of the snmpEngineboot node is incorrect.
• Condition: This symptom occurs if the whole IRF fabric is rebooted to cause a master/subordinate switchover.

Addressed Vulnerabilities

This release addresses the following CVE

CVE-2016-9586
CVE-2017-15896
CVE-2017-3737
CVE-2017-3738
CVE-2017-3736
CVE-2017-12190
CVE-2017-12192
CVE-2017-15274
CVE-2017-15299
CVE-2017-1000253
CVE-2017-3735
CVE-2017-6458
CVE-2016-9042
CVE-2014-9297
CVE-2015-9298

Information about the detail of these vulnerabilities can be found at https://cve.mitre.org/cve/search_cve_list.html

Impact

The expected impact is ~5-10 minutes for Option 1 customers during which time the FroDo will reload and external services will not be available. For Option 2 customers the impact is expected to be minimal thanks to the In Service Software Upgrade (ISSU) capability introduced in the firmware update applied in August 2017.

We will be carrying out the upgrades between 06:00 and 07:30 to minimise impact.

Timescale

We plan to upgrade approximately 80 FroDo’s on the each of the following days:

Group A: Tuesday 18th September
Group B: Thursday 20th September
Group C: Tuesday 25th September
Group D: Thursday 27th September

Schedule

We have attempted,where possible, to group devices around main sites and annexes so that those sites will only see one period of disruption. Detailed schedules listing devices and dates can be found at https://docs.ntg.ox.ac.uk/pub/reference/FroDoUpgrade-Sep2018

Once again, if you have any further queries then please contact us at networks@it.ox.ac.uk

Posted in General Maintenance, Odin | Comments Off on September 2018 Odin FroDo Upgrade

September 2018 – Odin 5940 Frodo Upgrade

Odin 5940 FroDo Comware Upgrade

We would like to announce a staged upgrade of the version of Comware running on our HPE 5940 FroDos. This blog entry aims to answer the majority of questions that this work will raise. Please, feel free to contact the Networks team with any further questions at networks@it.ox.ac.uk

Why?

As part of ongoing maintenance it is essential that we keep our FroDo software up to date. The new version of software being deployed addresses a number of vulnerabilities and bugs. For those interested this upgrade takes us from F2604H04 to R2612H01 and involves more than a dozen devices.

Relevant Bug Fixes

Symptom: After the master of an IRF fabric is rebooted, SNMP obtains an incorrect value for the snmpEngineBoots node.

Condition: This symptom might occur if SNMP is used to obtain the value of the snmpEngineBoots node after the master of an IRF fabric is rebooted.

Effect: This stops management systems from connecting to the SNMP engine on the device. Noticeable and inconvenient because graphs of port throughput are no longer maintained.

Addressed Vulnerabilities

This release addresses the following CVEs

CVE-2014-9297

CVE-2015-3405

CVE-2015-9298

CVE-2016-7427

CVE-2016-7428

CVE-2016-7431

CVE-2016-9042

CVE-2017-3731

CVE-2017-3732

CVE-2017-3735

CVE-2017-3736

CVE-2017-3737

CVE-2017-3738

CVE-2017-6458

CVE-2017-12190

CVE-2017-12192

CVE-2017-15274

CVE-2017-15299

CVE-2017-15896

CVE-2017-1000253

Information about the detail of these vulnerabilities can be found at https://cve.mitre.org/cve/search_cve_list.html

Impact

The expected impact is ~5-10 minutes for Option 1 customers during which time the FroDo will reload and external services will not be available. For Option 2 customers the impact is expected to be minimal thanks to the In Service Software Upgrade (ISSU) capability.

We will be carrying out the upgrades between 06:00 and 07:30 to minimise impact.

Timescale

We plan to upgrade up to 2 FroDos, one option 1, and one option 2, on the each of the following days:

Tuesday 4th September
 frodo-030809 dcdist-br (option 2) - completed
 Notes: Resilience of link to BSP-STORAGE in BRDC not functioning correctly causing interruption and some Left Hand storage entered read-only mode.
        AD DC behind ADFS for Nexus 365 coincidentally failed the night before ~23:00 causing failure of *some* user logins to Outlook. 
        Not caused by Frodo upgrade but we were blamed for it by some before all the details were known.
Wednesday 5th September
 frodo-030811 dcdist-osney (option 2) - completed
 frodo-100907 wellcome-trust - completed
 frodo-100909 orcrb-2 - completed - upgraded 1 day early

Due to an issue encountered on the morning of 5th with two of the upgrades 
we will postpone the remaining ones until further notice pending the result 
of a support call with the vendor.
Thursday 6th September
 frodo-120809 dcdist-usdc (option 2) - cancelled
Tuesday 11th September
 frodo-100908 richard-doll (option 2) - cancelled
 frodo-120601 beach-2 - cancelled
Wednesday 12th September
 frodo-050909 begbroke-iat-1 (conversion to option 2 and dcdist-begbroke) - upgrade cancelled - conversion will still take place
 frodo-120810 molecular-medicine - cancelled
Thursday 13th September
 frodo-120811 big-data-institute (option 2) - cancelled
 frodo-120812 john-radcliffe-3 - cancelled
Posted in HP Networks, Odin | Comments Off on September 2018 – Odin 5940 Frodo Upgrade

eduroam and realmless usernames: an update

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.

Posted in Uncategorized | Tagged , , , | Comments Off on eduroam and realmless usernames: an update

May 2018 Odin FroDo Upgrade

FroDo Comware Upgrade

We would like to announce a staged upgrade of the version of Comware running on our HPE 5510 FroDos. This blog entry aims to answer the majority of questions that this work will raise. Please, however,  feel free to contact the Networks team with any further questions at networks@it.ox.ac.uk

Why?

As part of ongoing maintenance it is essential that we keep our FroDo software up to date. The new version of software being deployed addresses a number of vulnerabilities and bugs. For those interested this upgrade takes us from R1122P01 to R1309 and involves over 300 devices.

Relevant Bug Fixes

Symptom: Forwarding errors or traffic interruptions might occur on the switch.

Condition: This symptom occurs with a low probability if the switch runs for a long time.

Addressed Vulnerabilities

This release addresses the following CVE

CVE-2017-6458
CVE-2016-9042
CVE-2014-9297
CVE-2015-9298

Information about the detail of these vulnerabilities can be found at https://cve.mitre.org/cve/search_cve_list.html

Impact

The expected impact is ~5-10 minutes for Option 1 customers during which time the FroDo will reload and external services will not be available. For Option 2 customers the impact is expected to be minimal thanks to the In Service Software Upgrade (ISSU) capability introduced in the last firmware update applied in August 2017.

We will be carrying out the upgrades between 06:00 and 07:30 to minimise impact.

Timescale

We plan to upgrade approximately 80 FroDo’s on the each of the following days:

Group A: Tuesday 1st May
Group B: Thursday 3rd May
Group C: Tuesday 8th May
Group D: Thursday 10th May

Schedule

We have attempted,where possible, to group devices around main sites and annexes so that those sites will only see one period of disruption. Detailed schedules listing devices and dates can be found at https://docs.ntg.ox.ac.uk/pub/reference/odin-frodo-software-upgrade-may-2018-1

Once again, if you have any further queries then please contact us at networks@it.ox.ac.uk

Posted in General Maintenance, Odin | Comments Off on May 2018 Odin FroDo Upgrade

eduroam and realmless usernames

IT Services’s user-facing instructions for connecting to eduroam have always been unequivocal about the username to use: if you want to connect to eduroam, your username is your SSO with @ox.ac.uk appended on at the end, all lower case. So, an SSO of unit1234 would become unit1234@ox.ac.uk. However, as you may have discovered, when you connect to eduroam within the University and authenticate without the @ox.ac.uk appended to your SSO, you will still be granted access.

RADIUS is the service underpinning eduroam authentication. In RADIUS parlance, the @ox.ac.uk is the username’s realm and declares the institution performing the authentication, in this case “ox.ac.uk”. Other institutions that offer eduroam have their own realms and when someone within the University uses a realm other than ox.ac.uk, say larry@faber.edu, we will proxy the request to that foreign institution for them to authenticate.

Back in the dim and distant past, our RADIUS servers were configured such that if no realm was supplied when authenticating to eduroam here at the University, they would infer the realm to be ox.ac.uk and act accordingly. When configuring your device for connecting to eduroam, the advantage of making your realm explicit is fairly obvious: when you travel to other institutions that offer eduroam, you will be able to connect without any changes to your connection details, because the other institution will know to use the RADIUS servers at the University of Oxford to authenticate. The advantage of making your realm implicit is equally obvious: you save typing out 9 characters including that pesky ‘@’. For many years we’ve turned a blind eye to the practice of realmless authentication, but it’s coming to a head:

  1. The University of Oxford is not the only institution in this fine city offering eduroam. Other institutions are available. We’ve had reports that these institutions’ IT staff are being contacted by University members using realmless authentication with connection problems. “It works everywhere else, so it must be something wrong with your system”. Saying that the University’s instructions never mention realmless usernames is of little consolation to these IT staff fielding repeated support queries.
  2. Perhaps more importantly, since our RADIUS configuration was written Jisc has released an update to the eduroam technical specification. Specification 1.2 explicitly states that “only RFC 4282 compliant usernames (of the form userID@realm) to be employed for user authentication both for roaming users and for users when at the Home site”.

It’s the “at the Home site” that’s important for the second point. It means even though our internal authentication never leaves the confines of the University, we are in breach of the eduroam specification and we should fix that.

Some numbers

So with that out the way, how many devices are configured without a realm? It’s fairly easy to find out from our logs. Results for the past few days (no prizes for guessing on which day the undergraduates started arriving):

Day Realmless Realmed Percentage realmless
0 8834 25580 25.7%
1 9101 26994 25.2%
2 8921 28267 24.0%
3 6322 21409 22.8%
4 7867 22121 26.2%
5 13106 33646 28.0%
6 14443 36203 28.5%

The configuration change to reject realmless usernames is relatively simple and we actually have had it waiting to be deployed for a while now. However, with at least 14,443 devices configured without a realm, all requiring reconfiguration after we mandate an explicit realm, it’s not a simple case of making the change and hoping the users will reconfigure it when they realize something’s wrong.

What about eduroamCAT?

eduroamCAT is no panacea. In fact, our eduroamCAT profile is configured to include the realm so these figures are even more stark, as the realmless authentications would thus have had to have been manually configured clients. If we were to enforce the realm in usernames though I’m sure eduroamCAT would play a large part in device conformance.

Conclusion

There’s no question of if we’re going to stop allowing realmless authentication. For us to comply with the requirements specified by Jisc it’s a case of when it’s going to happen. With so many devices configured without a realm it would be a very bold move for us to make the necessary changes next Friday before leaving for the weekend. Such a change would require involvement from all sectors of IT support, both within IT Services and within the general ITSS community. The benefits may not be felt directly by ITSS here, but certainly other institutions would appreciate the change.

In terms of helping ITSS know who has devices configured without a realm, it’s something that we are discussing here at the moment and once we have decided on the best course of action there most likely will be an announcement on a medium more formal than a blog post.

Posted in eduroam | Comments Off on eduroam and realmless usernames