400 likes | 615 Views
Make Role Based Access Control (RBAC) work for you. Bhargav Shukla Director – Product Research and Innovation KEMP Technologies. MNG303. Agenda. Understanding RBAC RBAC in Exchange 2013 RBAC in Lync 2013 Real world deployment planning for RBAC. Understanding RBAC. History of RBAC.
E N D
Make Role Based Access Control (RBAC) work for you Bhargav Shukla Director – Product Research and Innovation KEMP Technologies MNG303
Agenda Understanding RBAC RBAC in Exchange 2013 RBAC in Lync 2013 Real world deployment planning for RBAC
History of RBAC Approach to restricting systems access to authorized users Concept or RBAC at Microsoft goes back to 2003 or maybe even earlier Anyone 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 RBAC RBAC as we know it Introduced in Exchange and Lync 2010 Simplifies access control administration Removes dependency on AD administrators for routine tasks Roles are closely mapped to application e.g. Exchange or Lync Provided ability to grant granular permissions Ability to control cmdlet and parameter level access Better permission assignments than canned permission groups
RBAC in Exchange 2013 All Exchange 2013 tools are based on Remote PowerShell Exchange Management Shell Exchange Administration Center All tools leverage PowerShell v3.0 Windows Remote Management (WinRM) Remote PowerShell through IIS RBAC incorporated into the IIS Remote PowerShell implementation This is why even local EMS goes through IIS!
RBAC in Exchange 2013 No dependency on PowerShell listener winrmenumaratewinrm/config/Listener doesn’t return any listener on Exchange 2013 Connect to Exchange remotely using PowerShell $Session = New-PSSession -ConfigurationNameMicrosoft.Exchange -ConnectionUri http://<FQDN of Exchange server>/PowerShell/ Import-PSSession $Session
Better than ACLs RBAC provides much more granular model Exchange 2003 had 3 management groups Exchange Full Administrator Exchange Administrator Exchange View-Only Administrator Exchange 2007 had 5 management groups Exchange Organization Administrator Exchange Recipient Administrator Exchange View-Only Administrator Exchange Public Folder Administrator Exchange Server Administrator
RBAC Components Users Administrators What? Who? Management Role Group Assignment Policy Management Role Role Assignment Role Entries Cmdlet: Parameters Cmdlet: Parameters Cmdlet: Parameters Where? Reipient Read Scope Configuration Read Scope Recipient Write Scope Configuration Write Scope
RBAC Components “What” – Roles/Cmdlets/Parameters Management Roles Group of cmdlets and parameters Defines a job role ~83 pre-defined roles in Exchange 2013 Management Role Entries Represents individual cmdlet and it’s parameters List Role Entries for a role Get-ManagementRoleEntry “RoleName\*” You can select cmdlets or parameters using appropriate switch
RBAC Components “What” – Roles/Cmdlets/Parameters Creating new management roles Parent-Child hierarchy Built-In roles serve as a parent Existing custom roles can also be used to create new roles New “child” roles can be modified Can remove entries Can’t add entries parent role doesn’t have In general, every new role must be created from existing role There are always exceptions…
RBAC Components “What” – Roles/Cmdlets/Parameters Creating new management roles The exception - “Unscoped Top Level” role As the name implies: No scope can be assigned No parent can be assigned Creates an empty role container Must be member of “Unscoped Role Management” role to create one Benefits of “Unscoped Top Level” role Provide restricted access to business logic Assign scripts to a role Scripts reside on Exchange server Users can run scripts as an exported cmdlet but can’t see or modify source Users 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/Scope Defined by RBAC management scope Inherited from parent if none specified Use ServerList to define server scopes Use RecipientRoot to define OU scope Use OPATH filters define recipient or server restrictions Use Exclusive to block inheritance Can’t assign a scope outside of implicit scope boundaries
RBAC Components “Who” – Admins/Users Role Assignees Can be direct assignment to a user Commonly assignments are created for a group Role Assignments for administrators Role Assignment Policies for end users Role Group Members Role groups located within “Microsoft Exchange Security Groups” OU in AD New-RoleGroupcmdlet creates a new USG in the OU *-RoleGroupMembercmdlets allow manipulation of Role Group memberships Use BypassSecurityGroupManagerCheck parameter to override owner as admin or to manage Security Distribution Groups
RBAC Components It 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 OU Only moving all groups is supported, moving only few groups is not
RBAC Components Role assignment Glue to connect Who/Where/What New-ManagementRoleAssignment Role and Group are required Scope is optional If no scope defined, assignment inherits scope from role
Demo Creating custom RBAC roles in Exchange 2013
Watch out for… Don’t remove View-AdServerSettingscmdlets Update RBAC scopes if moving an OU
RBAC behind the scenes All tasks run under the security context of the Exchange server providing the PowerShell session The Exchange servers are members of the Exchange Trusted Subsystems USG Exchange Trusted Subsystems USG has the permissions to carry out all Exchange tasks RBAC determines the level of access given to the user
RBAC behind the scenes What 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 permissions Permissions 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 permissions setup.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 permissions Using 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 Directory Separation 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 Access granted based on user’s Lync Server role Allows administrators to delegate precisely the rights needed Restrictions are effective only on remote connections RBAC does not apply to local connection on server Must use Lync Server Control Panel, Lync Server Management Shell or remote PowerShell session
RBAC in Lync 2013 Connect 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 2013 Scope is limited to Configuration Scope “Site:SiteID” User Scope “OU:OU Path” Role group members Member of Universal Security Groups No cmdlet for managing role members New role creation Not as granular as Exchange, can’t control parameter level access Role definitions are stored in CMS, Exchange stores it in AD
Demo Creating custom RBAC roles in Lync 2013
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
Demo RBAC planning process
Key Takeaways RBAC provides granular control over permissions Separates policy storage from security object storage Permissions map closely to application and user requirements Plan requirements and create custom roles to provide least access based on job roles