Recreating the local admin role in G Suite

Delegating management privileges to a section of the G Suite organisational tree is a common requirement for deployments that scale across districts or educational trusts.

When a single branch of the organisational tree contains a entire school with thousands of user accounts the ability to create a local admin who can manage that branch without having access to other parts of the tree becomes a useful facility. Unfortunately the local admin role isn’t one of the built-in options provided by G Suite  - you have to make your own.

The ability to assign users to roles is managed through the Admin roles icon on the console. The same dialog allows ‘super’ users to select individual permissions from a set of fixed options to create custom roles.

The trick to creating the new local admin role is to avoid any permission that only operates at the root level. Some objects, such as groups can only be managed at the organisational  level. Therefore selecting the groups permission immediately restricts you managing at the top level which is not what we want. When you assign users to roles with root permissions the option to select an OU will be fixed to All Orgs.

So what permissions can be applied at the branch level?  The interface gives no obvious indication but it turns out there are quite a few.. as well as a couple of things that can trip you up.

The current list of permissions that can be applied at the sub-organisational level are shown here.

Selecting all the permissions listed in the dialog creates a role that can manage the user and chromebook objects under a specific node in the organisational tree.

The local admin can also update the organisational tree, deploy applications to chromebooks and even manage network policies. The role does not have the ability to update any policy relating to the core application set (Drive, GMail, Classroom etc..) or any policy affecting the organisation as a whole such as domains and security.

---

A couple of points worth noting:

The permission to manage User Chrome policies works in two different modes depending on whether the organisation has purchased Chromebook licences or not.

If the organisation does not have Chromebook licences you need to select the option below.

Once Chromebook licences have been added a new option appears under Services and you should transfer the rights to this node (see below).

If the organisation has purchased licences and uses the first option without ticking in the new permissions the User Chrome Management dialog will hang when the local admin user tries to access it.

The second point is less obvious.

If you check in the ChromeOS permission within Services it will fix permissions at the root level which is something  we are trying to avoid.

However if you only check in the  individual sub-options under ChromeOS and leave ChromeOS unchecked you’ll find that the OU drop down is still available (above). This is a subtle difference but it allows you to delegate the rights to manage Chromebooks to a single node in the organisational tree.

Interestingly you can also reuse the policy for all your local admins. When you hit the Assign Admins button the dialog gives you Assign More as an option (below).  You can add multiple user accounts within this dialog  – each batch of users can  point to  a different node in the organisational tree.

It’s also possible to enter the same user account multiple times so long the user is assigned to  a different node in the organisational tree. Using this method the user will find they are able to access more than one sub-organisation in the tree which is useful if a single account is responsible for managing multiple schools. 

Currently the only way to update the allocated sub-OU is to delete and recreate the assignment. 

If the new local administrator navigates to admin.google.com they’ll  be presented with a dashboard containing just the Device management and Users icons. The whole organisational tree is visible but the custom role works like a filter. Users can only view and manage user accounts and chromebooks that fall under the allocated sub-OU for the role.

The method described would be appropriate for a district or multi school trust but could equally apply to a single school where the super administrator wishes to delegate admin rights for an intake year or class group. 

The rights as shown are fairly liberal but can be reduced without affecting the ability to be assigned to an specific sub-OU.

One last note. Even if you check in all the delegated rights you do not re-create a super account.
A super account maintains a even higher level of access rights which includes the ability to bulk load users and (oddly) the ability to update a user to share contact information. I'm sure there are many more.

My thanks go to Aled Owain Jones, Technical Support Officer for Conwy County Borough Council, Wales for working through these examples with me.