Granular administrative roles appear in Office 365

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.

ITPro Today

June 4, 2015

5 Min Read
Granular administrative roles appear in Office 365

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, NameObjectId                            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 –AutoSizeRoleMemberType EmailAddress            DisplayName          -------------- ------------            -----------                User [email protected] 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

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like