Managing Exchange Server 2013 Using the Exchange Admin Center, PowerShell, and RBAC Martin Coetzer | Portfolio Architect, Microsoft Learning eXperiences ​Andi Conrad | Consultant, IT Service Management, Microsoft Services

Course Topics Managing Exchange Server 2013 01 | Exchange Management Tools 02 | What is RBAC? 03 | RBAC Components 04 | Putting RBAC together 05 | Troubleshooting RBAC 06 | Auditing in Exchange Server 2013

04 | Putting RBAC together Martin Coetzer | Portfolio Architect, Microsoft Learning eXperiences ​Andi Conrad | Consultant, IT Service Management, Microsoft Services

Module Overview Built-in Management Role Groups Where is it stored? Organization wide enforcement What AD permissions is required? Assigned roles are additive Deployment Planning

Glue The Triangle of Power Where Who What These are the 4 high level pieces of RBAC. The details follow on the upcoming slides.

Out-of-the-Box No Explicit Scopes built in Where No Explicit Scopes built in 85 Roles built into Exchange Mail Recipients Database MyDistributionGroups 12 Role Groups Help Desk Organization Management Discovery Management 195 Role Assignments What Who Where – Scopes are OPath filters What – Built in roles not editable. Glue

Where is the Authorization “Triangle” Stored? AD stores the objects that allow authorization CN=Configuration | |- CN=Services |- CN=<Org Name> |- CN=RBAC |- CN=Policies |- CN=Role Assignments |- CN=Roles |- CN=Scopes Note there is nothing to stop the administrator from using ADSIEdit to make changes and those changes will break RBAC to varying degrees (it will depend on where the change is made, and whether it cascades down)

Exploring RBAC Can get all RBAC cmdlets with: Examples: get-excommand | Where-Object { $_.Name -like "*scope*" } get-excommand | Where-Object { $_.Name -like "*role*" } Examples: Get-RoleGroup Get-ManagementRole Get-ManagementRoleAssignment Get-ManagementScope

Demo Exploring RBAC

Organization-Wide enforcement All cmdlets run are in remote PowerShell Remote PowerShell always checks AD for your roles Same rights enforced Org wide All cmdlets are run the same way. Remote PowerShell establishes a runspace on an Exchange Server, that server confirms what you are allowed to do with Active Directory and then your client is told what options it is permitted to present. This is important because with older versions of Exchange anyone can install the management tools. Once those tools are installed if they have access there is no telling what they will do. Now if a user installs the 2010 Management Tools on a workstation they do not have everything at their fingertips and are limited in what they can do by the RBAC roles that are assigned.

AD Permissions In legacy all permissions were granted to you in AD Explicitly or via Group RBAC does EVERYTHING! Using one group: Exchange Trusted Subsystems Group

What does that mean? All cmdlets are executed under the context of the Exchange server! All cmdlets are executed in the runspace that IIS and WSMan set up. The cmdlets run as Exchange Trusted Subsystem.

How they work together Walk through the diagram. The PowerShell client communicates with the PowerShell host which uses WSMan to establish the runspace in an IIS Application Pool on an Exchange server. The permissions of the session are checked with Active Directory and the list of commands and properties the current user is allowed to manipulate is returned through IIS and WSMan to the PowerShell Client. Each command then goes through a very similar authentication process to make sure AD permissions have not changed since last checked.

What does it look like to the end user? Exchange Cmdlet count Organization Administrator

What does it look like to the end user? Exchange Cmdlet count Help Desk

Assigned Roles are Additive Not like permissions! Assignee gets all rights assigned Administrative User Role 1 A Not B Not C Resultant Set Not A Not B Not C A Not B Not C A B C A Not B C Role 2 C Not A Not B Role 3 B Not A Not C

Creating a new Role and assigning it How to create and assign a new Role The screen shots create a new role, remove role entries for *-inboxrules, create an exclusive scope and assign the scope to a Role Group that is also created.

WORKING WITH ROLES CREATING SCOPE END to End Scenario Demo WORKING WITH ROLES CREATING SCOPE END to End Scenario

Deployment planning Understanding of organizational structure MEC 2014 8/3/2019 9:46 PM Deployment planning Understanding of organizational structure Understanding of Job roles Mapping Job roles to Built-in Management roles Documenting Permissions requirement Creating repeatable process and supporting documentation © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Summary Built-in Management Role Groups Where is it stored? Organization wide enforcement AD permissions Assigned roles are additive Deployment Planning