Monthly Archives: September 2017

A delay, you say?

Posted on by
Reply

It’s been pointed out to me that the impact of the Grouper to AD provisioning delays is actually not widely understood. I’ll try to sum it up here as explicitly as I can but please feel free to ask if I haven’t explained anything as well as you would’ve liked!

The delay is in provisioning new groups, changes to groups and changes to group memberships from Grouper to AD. There is no impact to existing groups and group memberships.

So, what could be affected by this?

Anything that uses AD groups in the ‘GrouperGroups’ OU for access control could be affected. Some of the things these groups are used directly to control access to include (but are not limited to) shared filestore, mailing lists, wifi, calendars, printers, PCs, software and the new Rocket HPC system (currently in pilot, I believe).

Additionally, AD’s GrouperGroups groups show up as a Shibboleth attribute which can be used to restrict access to any resources protected by the Login Gateway to a specific group of people. Known uses for this include Microsoft Imagine (formerly Dreamspark), some internal websites and some holiday booking systems. There could, of course, be others.

And what is definitely not affected?

There is no delay internal to Grouper so group memberships within Grouper are up to date. Anything relying on Grouper groups directly or via data feeds, such as some features of the mobile app or Chubb access to some buildings, will be fine.

What does all this actually mean?

Firstly, I hope that anyone who has chosen to use (or inherited) Grouper as an access control component of their service knows and understands how Grouper fits into their particular picture; if it includes AD then access to the service could be affected for new users.

It’s something to consider if an end user reports an access issue. For example, if a new member of staff can’t connect to their team’s shared filestore or they’re not receiving emails to a mailing list they should be on then the chances are they are a victim of the delay. If, however, they find that their smartcard won’t let them into Merz Court then that will be caused by something else.

I hope this has helped to clear up the impact of the delay but if not please let us know!

New academic year (and the trouble it brings)

Posted on by
Reply

It’s now the middle of September so I feel I owe you an update on the issues we’re facing around provisioning Grouper group memberships to AD. Since 1st September we’ve not had any “real-time” provisionsing to AD. We have, again, offered some workarounds to alleviate the impact of the most urgent cases. I’d like to thank the Operations team for their help with this.

This wasn’t unexpected, of course; it happened last year and we knew it would happen again. Michael sent a couple of warning emails out in advance and I tried to prepare everyone I spoke to.

I’ll try to explain the reasons why we see this delay in Grouper to AD provisioning: it’s purely to do with the volume of membership changes that occur at the change over of academic year (August to September).

Chart showing monthly updates to Grouper groups, by stem, from March 2016 to September 2017

Chart showing monthly updates to Grouper groups, by stem, from March 2016 to September 2017

You can see from the chart that there have been even more changes to group memberships this year than last year, meaning that the provisioning delay has been longer. We’re currently only half way through September but there have already been over a million membership changes! Most of these are in the student Corporate Data, particularly module enrolment groups.

There are two main reasons why there are substantially more changes this year than last: firstly, Grouper usage has increased considerably over the last year; and secondly, the SAgE reorganisation necessitated the addition of many new student Corporate Data groups.

The issue around the volume of changes is further exacerbated by a bug in Grouper’s provisioning technology which means that every change in Grouper must be processed even though it’s only changes in the Applications stem which are actually pushed through to AD.

We were hoping to be able to escape the delays this year by upgrading Grouper to take advantage of their next generation provisioning technology, which is much faster and also doesn’t suffer from that bug. Unfortunately, after extensive testing and collaboration with the developers, we decided that it was not quite production-ready for deployment in an enterprise environment. I’m very hopeful that we will be able to upgrade before this time next year!

So, onto the backlog … Well, once we’d seen the number of changes to process, estimates started off at well over 20 days. Over the last week, however, we’ve seen processing times increase considerably. We believe this is due to the work of ISG in modernising the AD domain controller infrastructure. This means that my current estimate is that the backlog should be cleared sometime on Monday … just in time for registration!