Bhargav ShuklaDirector – Product Research and InnovationKEMP Technologies

Make Role Based Access Control (RBAC) work for you

MNG303

AgendaUnderstanding RBACRBAC in Exchange 2013RBAC in Lync 2013Real world deployment planning for RBAC

Understanding RBAC

History of RBACApproach to restricting systems access to authorized usersConcept or RBAC at Microsoft goes back to 2003 or maybe even earlierAnyone remember AzMan or Authorization Manager?Separate location of security objects (Active Directory) and policy store (AzMan)Provides granular permissions based on organizational requirements and not based on DACLs

History of RBACRBAC as we know itIntroduced in Exchange and Lync 2010Simplifies access control administrationRemoves dependency on AD administrators for routine tasksRoles are closely mapped to application e.g. Exchange or LyncProvided ability to grant granular permissions

Ability to control cmdlet and parameter level accessBetter permission assignments than canned permission groups

RBAC in Exchange 2013

RBAC in Exchange 2013All Exchange 2013 tools are based on Remote PowerShellExchange Management ShellExchange Administration Center

All tools leveragePowerShell v3.0Windows Remote Management (WinRM)Remote PowerShell through IISRBAC incorporated into the IIS Remote PowerShell implementationThis is why even local EMS goes through IIS!

RBAC in Exchange 2013No dependency on PowerShell listenerwinrm enumarate winrm/config/Listener doesn’t return any listener on Exchange 2013

Connect to Exchange remotely using PowerShell$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange server>/PowerShell/Import-PSSession $Session

Better than ACLsRBAC provides much more granular modelExchange 2003 had 3 management groups

Exchange Full AdministratorExchange AdministratorExchange View-Only Administrator

Exchange 2007 had 5 management groupsExchange Organization AdministratorExchange Recipient AdministratorExchange View-Only AdministratorExchange Public Folder AdministratorExchange Server Administrator

RBAC Components

AssignmentPolicy

Reipient Read Scope

Recipient Write Scope

Configuration Read Scope

Configuration Write Scope

ManagementRole

Role Entries

Cmdlet: Parameters Cmdlet: Parameters Cmdlet: Parameters

Management Role Group

Administrators Users

Where?

What? Who?

RoleAssignment

RBAC Components“What” – Roles/Cmdlets/ParametersManagement Roles

Group of cmdlets and parametersDefines a job role~83 pre-defined roles in Exchange 2013

Management Role EntriesRepresents individual cmdlet and it’s parametersList Role Entries for a role

Get-ManagementRoleEntry “RoleName\*”You can select cmdlets or parameters using appropriate switch

RBAC Components“What” – Roles/Cmdlets/ParametersCreating new management roles

Parent-Child hierarchyBuilt-In roles serve as a parentExisting custom roles can also be used to create new roles New “child” roles can be modified

Can remove entriesCan’t add entries parent role doesn’t have

In general, every new role must be created from existing roleThere are always exceptions…

RBAC Components“What” – Roles/Cmdlets/ParametersCreating new management roles

The exception - “Unscoped Top Level” roleAs the name implies:

No scope can be assignedNo parent can be assignedCreates an empty role container

Must be member of “Unscoped Role Management” role to create one

Benefits of “Unscoped Top Level” roleProvide restricted access to business logic

Assign scripts to a roleScripts reside on Exchange serverUsers can run scripts as an exported cmdlet but can’t see or modify sourceUsers don’t need access to cmdlets that script runs

RBAC and Principle of Least Privilege - http://bit.ly/unscopedtoplevel

Demo

Unscoped Top Level Role

RBAC Components“Where” – Self/OU/ScopeDefined by RBAC management scopeInherited from parent if none specifiedUse ServerList to define server scopesUse RecipientRoot to define OU scopeUse OPATH filters define recipient or server restrictionsUse Exclusive to block inheritanceCan’t assign a scope outside of implicit scope boundaries

RBAC Components“Who” – Admins/UsersRole Assignees

Can be direct assignment to a userCommonly assignments are created for a groupRole Assignments for administratorsRole Assignment Policies for end users

Role Group MembersRole groups located within “Microsoft Exchange Security Groups” OU in ADNew-RoleGroup cmdlet creates a new USG in the OU*-RoleGroupMember cmdlets allow manipulation of Role Group membershipsUse BypassSecurityGroupManagerCheck parameter to override owner as admin or to manage Security Distribution Groups

RBAC ComponentsIt is possible to move “Microsoft Exchange Security Groups” OU to a different domain in the forest“otherWellKnownobjects” attribute of the org object is updated if OU is moved

Can also move groups to different OUOnly moving all groups is supported, moving only few groups is not

RBAC ComponentsRole assignmentGlue to connect Who/Where/WhatNew-ManagementRoleAssignment

Role and Group are requiredScope is optionalIf no scope defined, assignment inherits scope from role

Demo

Creating custom RBAC roles in Exchange 2013

Watch out for…Don’t remove View-AdServerSettings cmdlets

Update RBAC scopes if moving an OU

RBAC behind the scenesAll tasks run under the security context of the Exchange server providing the PowerShell sessionThe Exchange servers are members of the Exchange Trusted Subsystems USGExchange Trusted Subsystems USG has the permissions to carry out all Exchange tasksRBAC determines the level of access given to the user

RBAC behind the scenesWhat do you see in Active Directory audits when an object is created or changed?Active Directory modifications are made by Exchange Trusted Subsystem, use Exchange Audit logs for actions performed by admins

RBAC split permissionsPermissions to create security principals controlled by RBAC

Only Exchange servers, services and members of appropriate groups can create security principals

Switching to RBAC Split Permissions is a manual process

To implement - http://bit.ly/17yvC5i

To Remove - http://bit.ly/16TgQGZ

Active Directory split permissionssetup.com to implement during or after install

Microsoft Exchange Protected Groups OU is created

Exchange Windows Permissions group is created or moved to that OU

ETS isn’t added to EWP group

ACEs aren't added to AD domain object for EWP group

Non-Delegating assignments are not created for Mail Recipient Creation and Security Group Creation and Membership

More details - http://bit.ly/16Thp3w

Split permissionsUsing RBAC

Separate who can create security principals from those who administer Exchange configuration

Simplified process while maintaining separation

Can use Exchange management tools

Allow Exchange Servers and services to create security principals

Using Active DirectorySeparation of roles as well as tools

Several changes are made to permissions granted to ETS and Exchange Servers

Can’t use Exchange management tools to create security principals

Can’t manage DG membership from Exchange management tools

RBAC in Lync 2013

RBAC in Lync 2013Access granted based on user’s Lync Server roleAllows administrators to delegate precisely the rights neededRestrictions are effective only on remote connectionsRBAC does not apply to local connection on serverMust use Lync Server Control Panel, Lync Server Management Shell or remote PowerShell session

RBAC in Lync 2013Connect remotely using PowerShell$cred = Get-Credential “Domain\Lync_Administrator” $session = New-PSSession -ConnectionURI “https://LyncServer/OcsPowershell” -Credential $cred Import-PsSession $session

How it differs from Exchange 2013Scope is limited toConfiguration Scope “Site:SiteID”User Scope “OU:OU Path”

Role group membersMember of Universal Security GroupsNo cmdlet for managing role members

New role creationNot as granular as Exchange, can’t control parameter level accessRole definitions are stored in CMS, Exchange stores it in AD

Demo

Creating custom RBAC roles in Lync 2013

Deployment planning

Deployment planningUnderstanding of organizational structureUnderstanding of Job rolesMapping Job roles to Built-in Management rolesDocumenting Permissions requirementCreating repeatable process and supporting documentation

Demo

RBAC planning process

Key TakeawaysRBAC provides granular control over permissionsSeparates policy storage from security object storagePermissions map closely to application and user requirementsPlan requirements and create custom roles to provide least access based on job roles