Instruction whether your delegated admin user, app or service really need superadmin access

[kim_nilsson]

This is an instruction, not a question. Read if you wish to learn about admin roles and rights.

First off.

Superadmin account never needs extra admin rights.

If a user has the superadmin role, they never need to be assigned any other admin roles or custom admin rights, as the superadmin role has them all by default. However, that doesn't mean that the superadmin can do everything in a Google Workspace domain, as many actions and settings are user-only.

What admin rights must I assign my user, app or service?

Depending on what the app/service/account is supposed to do, you may not need to set the superadmin (SA) role for the account used, or even have a separate user account for the service at all!

Take GAM or GAMADV-XTD3 for example.

If you, as the SA, add the gam service account (not the same as a user account!) to Domain Wide Delegation (DwD), then the actual user account running gam does not need to be a SA to be able to do all things that the service account is allowed to do.

However, the service account is mainly (only?) used when impersonating a user to do certain things. The difference can easily be seen in the GAMADV-XTD3 wiki.

When you check the topics in the right-hand column, you will see topics listed under the two headers Client Access and Service Account Access.

Service Account Access obviously means a service account with DwD is needed. Those are actions that an admin can't always do, and instead requires the user do themselves. With service account access you can pretend to be the user and do it. It will also be logged in all logs that it was the user who did it! Important for audit purposes.

Client Access means you have to be SA, or else you will not be able to act on anyone but your own account. This is also why Client Access can be used with a gmail.com account, on yourself.

All actions will be logged in the Admin Audit Log as the admin user account doing it.

one2one (just an example of a tool for managing Chromebooks

Your Chromebooks tool (one2one) only need enough access to do its job.

Now, it's up to you to figure out what that is, unless the developer tells you. Ask them first. There are many, many actions that can be done without being the SA, especially if done via the APIs, which many tools work through. Also, some of them can be read-only, if the action is only reading info and not changing.

Google Workspace Password Sync (GWPS) - Google's official tool for syncing passwords from LDAP to Workspace.

This needs to be a MS AD full admin, else it can't read the DC (don't know requirements for other LDAPs), but it doesn't actually have to be a SA in Google, as it only manages passwords in Workspace. The guide says it needs a service account, and that can be added to a non-superadmin account (preferably a utility account, and not an account that some user accesses).

Directory Sync (GCDS) -Google's official tool for syncing user, groups, resources, profiles & shared contacts from LDAP to Workspace.

Now it gets tricky. 🙂 Here it depends on what your GCDS actually does. Certain actions are only possible as SA. If GCDS only provisions users and groups, it really only need those admin rights. Also, you can probably create a custom role with only those rights as API rights, much lower on the rights page. That GCDS user never logs into the account and the admin console, only communicates via the APIs. Same with GWPS above.

You can test your results by giving the GCDS/GWPS accounts less admin rights, and then add more GCDS object types to synk (Profiles, Schemas (most likely SA only), Resources (SA only), Domain Shared Contacts (there is no possible admin role for DSCs , but a service account with the correct API access in DwD can probably do it - even though I have helped document how to use a script to manage Shared Contacts in Sheets, I don't know, and therefore that exact detail isn't in the wiki).

There you go. Hope you enjoyed reading this and it added to your admin toolbox.