As I’ve watched the uptake of Grouper grow within the computing officer community over the last year (with many new and interesting use cases), I’ve seen many people face the same problems and struggle with the same dilemmas. The more I’ve helped people tackle these challenges, the clearer the solutions have become in my mind and the more I’ve realised I should try to document some of it. So, here it is, my list of principles, tips and good practices for Grouper administrators …

1. Use a ‘User Group’ to determine who has admin privileges on all of your groups and folders.
2. Whenever possible, use ‘Corporate Data’ groups to control memberships of your groups.
3. 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.
4. Only create ‘Applications’ groups if you need them to be provisioned to AD or available as Shibboleth attributes.
5. Adhere to the naming convention for ‘Applications’ groups.
6. Make ‘Applications’ groups specific to a service or purpose.
7. If you are delegating control of a group’s membership, give out the ‘update’ privilege, not the ‘admin’ privilege.

I realise it’d be useful to supplement this post with a higher-level overview of how Grouper works and what I mean by ‘Corporate Data’, ‘User Groups’ and ‘Applications’ groups. We’ll endeavour to get that written soon.

Our seventh principle of Grouper good practice is:

• If you are delegating control of a group’s membership, give out the ‘update’ privilege, not the ‘admin’ privilege.

One of the strengths of Grouper is that it enables you to delegate privileges to others to maintain membership of their own groups. If you’re doing this, you should assign the update privilege, which allows the updating of group memberships.

You should not assign admin privileges lightly. As well as allowing for the updating of group memberships, the admin privilege also allows the user to rename, move or delete the group. Or they could even remove your admin privileges, leaving you in a bit of a hole if you need to fix something.

Our sixth principle of Grouper good practice is:

• Make ‘Applications’ groups specific to a service or purpose.

This should ensure that each group provisioned to AD has a clear purpose and avoid any unforeseen consequences when a group is deleted, for example.

Additionally, requirements can change. Initially you might want to control access to a number of services with the same group but, over time, the people you want to grant access to might diverge from the original group. This scenario is best served by having specific ‘Applications’ groups all containing the same ‘User Groups’ group as a member. This gives the flexibility to allow the memberships to diverge, if required.

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 any of these characters, ” [ ] : ; | = + * ? < > / \,  so do not use them 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.