It contains automatically populated groups defined by the academic course and organisational structure of the University and custom groups defined and populated locally by units. These groups can be used for a variety of purposes, including fine-grained access control to physical and digital resources.

Groupstore extends the suite of Identity and Access Management (IAM) features offered by IT Services. Groupstore complements the Core User Directory (CUD) Service by allowing people to be grouped, either by attributes or in a more ad-hoc fashion.


Expand All

To request access to the Groupstore service, please use the Groupstore User Interface Access service request.

To request the removal of a user or to change the details of a current user, please contact

Groupstore group names bear some resemblance to the paths used when saving files.  In Groupstore, group path names are built up one folder at a time, with colons separating each folder name in the path.  For example, the name "etc:uat-users" would refer to the group "uat-users" in top-level folder "etc".  Every group and folder has both a short name and a longer name, which may be identical.  For example, the group of staff in IT Services has the short name "org:oxuni:centadm:itserv:staff" and the long name "org:University of Oxford:University Administration and Services:IT Services:IT Services, Staff".

The Groupstore group hierarchy is split into the following top-level branches:

  • A course group tree (called "course").  This contains course groups organised by SITS programme code and then by route code.  The short forms of the folder names use the SITS codes directly.  For example, the folder "course:programme:MPhys Physics:route:MPhys Physics" has the short form "course:programme:UP_PS1:route:UP_PS1".
  • An organisational group tree (called "org").  This contains college and department groups loosely based on the organisational structure in Oak LDAP.
  • A tree full of internal Groupstore groups (called "etc").  These can be ignored for the purposes of User Acceptance Testing.
  • University-wide application-specific group structures (called "app").  These are currently unused, and can also be ignored for the purposes of User Acceptance Testing.

By default, the existence of a group can be seen by everyone with access to Groupstore.  This can be prevented by removing the VIEW permission from the "EveryEntity" object.  However, the members of a group can only be seen by users or groups of users with the READ permission granted.  If a group is added to another group, the user doing the adding must have READ permissions on both groups.  This prevents users from discovering the members of a group without holding the relevant permissions.

In both the "course" and "org" folders, higher-level groups are used to aggregate the groups at deeper levels of the tree.  For example, the group org:college:roles:itss contains all college ITSS, and course:year-of-study:1 contains all first-year students.  In general, these higher level groups are populated based on the central "systems of record": SITS, HRIS, the University Card system and the Registration database and deeper groups offer more control to the local college or department administrators.

In the organisational tree, each unit has two sets of admin groups associated with it: a group "admin-r" for granting read-only access to groups, and a full admin group "admin-rw" for creating groups or adding members.  By default, the "admin-r" group contains all unit ITSS and the "admin-rw" group consists of the unit's primary ITSS.  However, full admins can add or remove members as they see fit.  In addition, full admins may create any group they like within their unit's "local" or "roles:local" folders.

Groupstore full UI

Typical use cases: ad-hoc lookup of group membership; management of custom unit groups

The Groupstore full user interface is a web application which allows registered users to perform the following:

  • Inspect Group membership (subject to access rights)
  • Create ad hoc groups for your units (subject to access rights)

All Groupstore users are encouraged to use the Groupstore UI to familiarize themselves with Groupstore.

The web user interface is available at  The Groupstore home page will present you with a customizable summary of groups that you manage or are a member of. From there you can use the search field at the top right to find a group or use the folder browser on the left-hand side to browse the complete Groupstore hierarchy.

You should be able to see the existence of most groups, but will be unable to view the members of a college or department group unless you are a member of the appropriate admin group.  As mentioned previously, "full" (read/write) admins for a unit can create new groups or folders within the "local" folder for their unit.  The organisational groups are populated based on CUD affiliations derived from the systems of record.  Since these may not fully represent reality, full admins may add members to the relevant "include" and "exclude" groups to modify this list.

When adding members to a group, it is recommended that you click the "search for an entity" link beneath the "Member name or ID:" box.  This will display a search box that will find users far faster than simply typing the name into the "Member name or ID:" box.  To add a Kerberos service principal or a /itss principal to a group, you need to type the full name including the realm (i.e. "service/" or "user/itss@OX.AC.UK").

Get support

If you cannot find the solution you need here then we have other ways to get IT support

Get IT support