Small Office 365 tenants could care less about the notion of granular management across applications. But their larger counterparts care about this kind of thing very much because it's part of the IT discipline that they have grown up with on-premises. Four years after its launch in 2011, Office 365 has introduced granular level management for Office 365, but only for those old-style applications like Exchange and SharePoint. New stuff like Delve is still managed as tenant-wide entities.
Since its launch,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
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 ‘Kim.Akers@Office365ExchangeBook.com’
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 dpredmond@Office365ExchangeBook.com Deirdre Redmond
User kim.akers@Office365ExchangeBook Kim Akers
User BOwens@Office365ExchangeBook 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