Granular administrative roles appear in Office 365

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, 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 ‘’ 

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 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 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

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.


Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro. His latest books are Office 365 for Exchange Professionals (eBook, May 2015) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×