Delegated Administration in Exchange Online

2018-01-10 | Dominik Hoefling

My colleagues and I are working on a (pilot) multi-forest Exchange hybrid environment with a single Office 365 tenant. In this early stage of the project we will have two companies, each with their own on-premises environment. One of the requirement is a delegated administrative concept for Exchange Online, which means administrators and helpdesk workers should only manage and configure settings for their specific domains. This blog post will show you how to handle this with Role Based Access Control (RBAC).

RBAC was introduced in Exchange 2010 to allow precise permission management within the Exchange organization for administrators and users. With RBAC, you can configure and control in a very granular way the administrative tasks that administrators or users can perform. RBAC controls both the administrative tasks that can be performed and the extent to which users can now administer their own mailbox and distribution groups. Understand that, with RBAC, it doesn’t matter what Active Directory permissions you have when using Exchange management tools—everything is authorized and controlled via RBAC. You can define precisely which cmdlets and parameters a user can run or modify.

RBAC also filters which cmdlets and functionality are available in Exchange Admin Center (EAC) or Exchange Online PowerShell, and it displays only the options available to you. For example, if you do not have the Mailbox Import Export permission, you won’t see the New-MailboxExportRequest cmdlet and thus cannot use it.

RBAC assigns permission in two primary ways, depending on whether the user is an administrator or an end-user:

More information about Role Based Access Control can be found in one of my previous blog posts: https://dominikhoefling.com/2014/09/08/exchange-permissions-model/

Note: I will not go further with the multi-forest Exchange hybrid deployment. Let’s assume both companies are already connected to the single Office 365 tenant.

Each organization is using a single smtp domain. Company 1 is responsible for dominikhoefling.com, company 2 for exchange-lab.de. To make it clear, both administrators in each company has assigned the global administrator role in the single Office 365 tenant.

The first goal is to restrict administrators and help desk workers from company 2 (exchange-lab.de) change recipient objects from company 1 (dominikhoefling.com):

1. Create a new role group for company 1:

New-RoleGroup -Name "Delegated Administration dominikhoefling.com"

2. Create a new exclusive management scope with UPN as recipient restriction filter:

New-ManagementScope -Name "Protect dominikhoefling.com" -RecipientRestrictionFilter { UserPrincipalName -Like "*dominikhoefling.com*} -Exclusive

Note: be careful with exclusive scopes! There will be a confirm message after you ran the cmdlet:

When you create exclusive management scopes, only users or universal security groups that are assigned exclusive scopes that contain objects to be

modified will be able to access those objects. Users or USGs that aren't assigned an exclusive scope that contains the objects will immediately lose

access to those objects. Are you sure you want to create the dominikhoefling.onmicrosoft.com\Protect dominikhoefling.com exclusive scope?

[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"):

What is a exclusive scope and why are we using this? When you create an exclusive scope, only those who are assigned that exclusive scope, or an equivalent exclusive scope, can modify the objects that match the scope. Role assignees who aren't assigned that exclusive scope, or an equivalent, can't modify the objects that match the scope, even if their own roles have scopes that would otherwise include the objects. Exclusive scopes override any other regular scope that isn't exclusive. This behavior is similar to how a deny access control entry (ACE) on an Active Directory access control list (ACL) functions. Source: https://technet.microsoft.com/en-us/library/dd638110(v=exchg.150).aspx

3. Create a new management role assignment with an exclusive recipient write scope:

New-ManagementRoleAssignment -SecurityGroup "Delegated Administration dominikhoefling.com" -Role "Mail Recipients" -ExclusiveRecipientWriteScope "Protect dominikhoefling.com"

4. You can check the management role assignment with the following cmdlet:

Get-ManagementRoleAssignment -Identity "Mail Recipients-Delegated Administration dominikhoefling.com"

5. Add the administrators or help desk workers to the role group which was created in step 1:

Add-RoleGroupMember -Member info@dominikhoefling.com -Identity "Delegated Administration dominikhoefling.com"

6. You can test it with the administrative account from company 2 (exchange-lab.de), which is in my example still a global administrator in the Office 365 tenant. Let’s try to set a smtp forwarding for a mailbox which belongs to company 1 (dominikhoefling.com:

Set-Mailbox -Identity info@dominikhoefling.com –ForwardingSmtpAddress dominik.hoefling@atwork-it.com

The operation on mailbox "info" failed because it's out of the current user's write scope. 'info' isn't within your current write scopes. Can't perform save operation. + CategoryInfo : InvalidOperation: (info:ADObjectId) [Set-Mailbox], InvalidOperationException + FullyQualifiedErrorId : [Server=HE1PR0801MB1628,RequestId=a7d2d179-9d5f-4c86-b9cf-67b14db00864,TimeStamp=1/10/2018 10:23:20 PM] [FailureCategory=CmdletInvalidOperationException] B590B0F6,Microsoft.Exchange.Management.RecipientTasks.SetMailbox + PSComputerName : outlook.office365.com

The same behavior occurs in the Exchange admin center:

Exchange Admin Center

7. Now we switch back to an administrative account from company 1 (dominikhoefling.com) and try to set the smtp forwarding:

Set-Mailbox -Identity info@dominikhoefling.com -ForwardingSmtpAddress dominik.hoefling@atwork-it.com

Get-Mailbox -Identity info@dominikhoefling.com | select ForwardingSmtpAddress

ForwardingSmtpAddress

---------------------

smtp:dominik.hoefling@atwork-it.com

Of course, because it is an exclusive scope and only manageable by their members, we also removed the capability to use the ‘Add-RoleGroupMember’ cmdlet for the administrators and help desk workers for the respective companies. You can check which cmdlet belongs to which management role entry and add/remove every available cmdlet.

I would recommend to create a new role instead of changing the default one and use the exclusive configuration for a deny to the default rules.

Get-ManagementRoleEntry "*\Add-RoleGroupMember"

Name Role Parameters

---- ---- ----------

Add-RoleGroupMember Role Management {BypassSecurityGroupManagerCheck, Confirm, ErrorAction, ErrorVariable...}

Only a subset of so called Enterprise Administrators can edit those roles and members. You can create such roles and assignments for every available Exchange Online cmdlet. Take care that you do not lockout yourself and a proper documentation is imperative.

As soon as the pilot concept will be finished, I will publish the configuration settings how to delegate administration in Exchange Online for single Office 365 tenant scenarios with multiple (self-administrated) organizations!

Tags: , ,

Categories: Exchange, Hybrid, Office365

Source: http://atwork.blog/post/2018/01/10/Delegated-Administration-in-Exchange-Online