Does your new admin user, app or service really need superadmin access? Short answer is, NO!
12K Views157 Upvotes
This is a best practices instruction, not a question.
Read if you wish to learn about admin roles and admin rights.
First off.
Superadmin account never needs extra admin rights.
If a user has the superadmin (SA) 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.
Second...
There should be at least be two (2) superadmins in a Google Workspace organisation.
Always!
There are many situations where you may find yourself unable to log into your account, and if you are the only superadmin, that could cause critical an irrevocable problems. Often it's solvable, but not always.
Delegated admin rights
There are many lesser admin roles included by default, and one or several in combination may be able to do what you want. If not, you may have to create a custom admin role, and select the admin rights relevant for the actions you want your app or user to do.
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 role for the account used, or even have a separate user account for the service at all!
Below I will explain using a few commonly known tools used by many Workspace administrators around the world.
Take GAMADV-XTD3 for example (a very powerful, free and open source, API tool for bulk management of Workspace resources and settings).
If you, as the superadmin, 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 superadmin to be able to do all things that the service account is allowed to do.
However, the service account is mainly 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 Domain Wide Delegation 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 superadmin (or have other relevant admin rights), 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 Log Events as the admin user account doing it.
Google Workspace Password Sync (GWPS) - Google's official tool for syncing passwords from an LDAP to Workspace.
This needs to be a Microsoft Active Directory (AD) full admin on the Microsoft side, else it can't read the Directory Controller (DC) (there may be other requirements for other LDAPs), but it doesn't actually have to be a superadmin in Google Workspace, 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 superadmin. 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 (DSC). There is no possible admin role for DSCs , but a service account with the correct API access in DwD can do it - I have even documented how to in this script to manage Shared Contacts in Google Sheets.
So, how do you know what rights to add for an app I haven't listed above?
Let's check this example.
CB_Inventory (another API tool for managing Chromebooks in a Google Sheet that I created, also free and open source)
It says there in the wiki that the tool needs enough access to do its job.
Now, it's up to you to figure out what that is, unless the developer tells you. I, of course, do that.
You will need to create a custom admin role with the following admin rights.
Services: Manage Chrome OS Devices
Admin API Privileges: Read Users
Services: Manage Chrome OS Devices
Admin API Privileges: Read Users
If you can't see any such information on the products web page, ask the developer first. You shouldn't have to figure it out by yourself. Especially not if it's a paid service, where their support should have that information readily available for you.
There are many, many actions that can be done without being the superadmin, especially if done via the APIs, which many tools work through. Also, some of them can be read-only, if the necessary action is only reading info and not changing.
Apart from this I must recommend you read the official support article Security best practices for administrator accounts, including the articles linked at the bottom with the security checklists.
There you go. Hope you enjoyed reading this and it added to your admin toolbox.
Do reach out if you have questions about any of this. That's why we Product Experts are here.
Also, click Subscribe to get updates on this guide.
Details
Community content may not be verified or up-to-date. Learn more.
Last edited Jan 22, 2024