Since its launch, Office 365 has operated on the basis that tenant administrators control everything on behalf of a customer. If your account has administrator status, you can do anything, including being able to access information across different applications. This is an acceptable situation for small companies, but it’s a real problem for larger companies, especially those who want to move workload to the cloud from a point where administration of on-premises operations is broken down along clearly understood lines of demarcation.
Enter granular administrative roles to provide Office 365 tenants with a method of assigning control over different parts of Office 365 to specific users. Tenant administrators remain all-powerful, but now they have a chance to share their power with others.
Microsoft actually made a false start along this journey in 2014 but reversed course very quickly. It’s likely that they weren’t fully ready at that time to go ahead with the implementation. In any case, the basics are:
The source of authority for granular management roles lies in groups held in Azure Active Directory (AAD). You can’t see these groups through the AAD console and have to work with them using the Office 365 Admin console or PowerShell. You can see the available roles by running the Get-MsOlRole cmdlet. This command lists the available roles – the ObjectId property is important because you will use it to interact with roles in other places.
Get-MsOlRole | Format-Table ObjectId, Name ObjectId Name -------- ---- 17315797-102d-40b4-93e0-432062caca18 Compliance Administrator 29232cdf-9323-42fd-ade2-1d097af3e4de Exchange Service Administrator 4ba39ca4-527c-499a-b93d-d9b492c50246 Partner Tier1 Support 62e90394-69f5-4237-9190-012177145e10 Company Administrator 729827e3-9c14-49f7-bb1b-9608f156bbb8 Helpdesk Administrator 75941009-915a-4869-abe7-691bff18279e Lync Service Administrator 88d8e3e3-8f55-4a1e-953a-9b9898b8876b Directory Readers 9360feb5-f418-4baa-8175-e2a00bac4301 Directory Writers 9c094953-4995-41c8-84c8-3ebb9b32c93f Device Join 9f06204d-73c1-4d4c-880a-6edb90606fd8 Device Administrators b0f54661-2d74-4c50-afa3-1ec803f12efe Billing Administrator c34f683f-4d5a-4403-affd-6615e00e3a7f Workplace Device Join d29b2b05-8046-44ba-8758-1e26182fcf32 Directory Synchronization Accounts d405c6df-0af8-4e3b-95e4-4d06e542189e Device Users e00e864a-17c5-4a4b-9c06-f5b95a8d5bd8 Partner Tier2 Support f023fd81-a637-4b56-95fd-791ac0226033 Service Support Administrator f28a1f50-f6e7-4571-818b-6a12f2af6b6c SharePoint Service Administrator fe930be7-5e62-47db-91af-98c3a49a38b1 User Account Administrator
I won’t go into the detail of what all of the various roles do. Instead, I want to focus on the roles created to allow users to manage applications like SharePoint Online and Exchange Online.
To assign a user account one of these roles, go to the Office 365 Admin Center, select the account in the Users section, and edit it. Go to Roles and select “Limited admin access” as shown in the screen shot below. You can then assign one or more of the roles to the user. Note that you have to provide an alternate email address if you assign an administrative role to a user account. This is to ensure that the password for the account can be recovered in case it is lost.
Note too that this scheme is for cloud-based management. In a hybrid environment, the on-premises Active Directory is the master and synchronization occurs from the on-premises directory to AAD. You can certainly create cloud-only user accounts and assign them administrative roles, but they will not be able to manage hybrid objects.
You can also use PowerShell to add user accounts to administrative roles. For instance, here’s how to add a new Exchange Online administrator:
Add-MsOlRoleMember –RoleName ‘Exchange Service Administrator’ –RoleMemberEmailAddress ‘[email protected]’
For the record, MSO Service Principals can also be assigned to granular roles. This fact is interesting but is probably uninteresting to the vast majority of those who work with Office 365.
Behind the scenes, the AAD role groups are updated with details of the access that has been granted and the information is then pushed to the directories that support the different applications, such as EXODS for Exchange Online and SPODS for SharePoint Online. You can see the set of users who have been assigned access to a particular role by running the Get-MsOlRoleMember cmdlet, which is when those ObjectIds come into play. For instance, here’s how to find out who has been assigned administrative control over Exchange Online:
Get-MsOlRoleMember –RoleObjectId 29232cdf-9323-42fd-ade2-1d097af3e4de | Format-Table RoleMemberType, EmailAddress, DisplayName –AutoSize RoleMemberType EmailAddress DisplayName -------------- ------------ ----------- User [email protected] Deirdre Redmond User [email protected] Kim Akers User [email protected] Ben Owens (Business Director)
After synchronization is complete (allow a couple of minutes), a user who has been assigned administrative access should be able to log-on and see the administrative interfaces. The Admin option will appear in their Office 365 App Launcher and, if they can manage Exchange, they’ll be able to use the https://outlook.office365.com/ecp/ link to go direct to the Exchange Administration Center (EAC). A limited set of options will be available in the Office 365 Admin Center (for instance, they won’t be able to create new user accounts). This is to be expected as their role is to manage an application rather than the tenant.
An Exchange administrator has full access to EAC options. And if we look at the permissions section to see what admin roles exist in the tenant, a new ExchangeServiceAdmins_53add RBAC management role group is present (see screenshot). This group cannot be edited by administrators as it is under the control of Office 365. It serves as the synchronization point back to AAD, so any account assigned control over Exchange Online is found here. This group is part of the Organization Management role group and so gains full administrative control over Exchange Online.
Similar arrangements exist in SharePoint Online and Skype for Business. Other applications such as Office Delve and the Office 365 Video Portal are managed on a tenant-wide basis. These applications don’t exist in the on-premises world and the need for granular management is not as strong as it is for applications that have a long on-premises history.
In some respects, it’s surprising that it has taken quite so long for Office 365 to have granular application-level management. But in another way it simply reflects the fact that a very large percentage of Office 365 tenants are small and don’t need this kind of granularity. After four years, it might also be a sign that the migration of larger customers to the cloud is gathering pace.
Follow Tony @12Knocksinna