Our fifth principle of Grouper good practice is:

• Adhere to the naming convention for ‘Applications’ groups.

The naming of groups is important to ensure the consistency and uniqueness of group identifiers between Grouper and Active Directory groups. It is a requirement of the AD that group names are unique.

So, to ensure uniqueness, the group ID is split down into three defining sections:

• Owning department/school – the school/department should be the abbreviation (without the leading D-) that is assigned to your school/department within SAP for example COMP (Computing science), LIBR (Library).
• Auto – the word “Auto” needs to be included within any group that is to be provisioned into the AD. This identifies the group in the AD as being automatically generated and therefore management of the group should be carried out within Grouper.
• Group purpose – this should provide a clear purpose for the group, so that users are able to quickly distinguish what the group represents.

This gives a group name of the format <Department/school>_ Auto_< Purpose>.

Please note that the group ID cannot include spaces so, if the purpose is more than one word, please replace spaces with an underscore character. AD will also not accept slash characters so do not use \ or / in your group names.

Our fourth principle of Grouper good practice is:

• Only create ‘Applications’ groups if you need them to be provisioned to AD or available as Shibboleth attributes.

There are two reasons for this:

1. The GrouperGroups section of the AD is already quite busy and cluttered, adding unnecessary groups will only make it worse.
2. The Grouper to AD provisioning process is quite inefficient and can slow down if there are a large number of changes. Minimising the number of groups being provisioned to AD will avoid any unnecessary slowing down of the provisioning process.

Our third principle of Grouper good practice is:

• Where adequate source data doesn’t exist to define a ‘Corporate Data’ group, create a ‘User Group’ if you’re likely to use the same set of members in more than one place.

This is a principle based around reuse, in order to save time and avoid inconsistencies and errors.

The classic example is for a research group. This fictional research group might be made up of some staff from School X, some from School Y and a few PGR students. There is nothing in our corporate data systems to identify that these people belong to this research group so we cannot create a ‘Corporate Data’ group for them.

Now, let’s say this research group wants to set up a mailing list, a wiki and a shared filestore. (These are all things that can be controlled through Grouper.) Instead of manually maintaining the membership list of three different ‘Applications’ groups, create one reusable ‘User Groups’ group which can be the member of the three ‘Applications’ groups.

Our second principle of Grouper good practice is:

• Whenever possible, use ‘Corporate Data’ groups to control memberships of your groups.

This is a straightforward, unambiguous and just plain sensible principle.

Membership of the ‘Corporate Data’ groups are populated with data from our corporate data source systems and are updated automatically. Using these groups to build up the membership of your groups means that the members of your groups will be updated automatically, too.

Our first principle of Grouper good practice is:

• Use a ‘User Group’ to determine who has admin privileges on all of your groups and folders.

Whilst setting up another group for this purpose might seem like an additional overhead of time and effort before you really get started with Grouper, I assure you it’s worth it. There are a few reasons and considerations behind this.

Now, if there are several of you working together with Grouper and all want to have admin privileges on each other’s groups then this is just common sense; it’s much easier to grant privileges on your groups to a single group than to several of your colleagues.

But you might be thinking, “Hey, it’s just me here. I don’t need to share admin privileges with anyone else.” Well, that’s OK, I hear you, but, please still create a user group for this purpose (with you as the only member). I appreciate it’s a small hassle, but hear me out.

Today, it’s just you working on it. But what if that changes? In six month’s time, you might be lucky enough to get a new colleague to work with you. Do you want to have to go through all the groups you’ve created and grant them admin privileges? Or would you rather add them as a member of one single group that you bothered to spend a couple of minutes setting up to have admin privileges on all of your groups?

Or, another scenario, what if you move on? Now your successor doesn’t have privileges on any of the groups they need to look after. If only we had a single admin group we could add them to! Of course, if you’re moving on, you might not be too worried about that but I’d like to think we’re all conscientious enough to care.

My final thought on this is a little more contentious. I’d say you should set up and use a ‘User Group’ for controlling admin privileges even if there’s already a ‘Corporate Data’ group containing the right people. I must admit this isn’t something I’ve always done myself but as my thinking has evolved and developed, it’s what I’m always going to do in the future.

You can then simply use the ‘Corporate Data’ group to populate the members of your admin group. The reason for this is that, whlist the ‘Corporate Data’ group might be right today, we’ve seen how things can change with reorganisations and evolving responsibilities.

Using a ‘User Group’ for admin privileges, from the start, will future-proof your part of Grouper.