RBAC: Walkthrough of creating a role that can wipe ActiveSync Devices

[The_Exchange_Team]

A question that has come up several times in recent months is: How do I create RBAC roles that present only very limited ActiveSync management functionality?

Before we dive into the answer let us do a quick review of what RBAC (Role Based Access Control) is.

Prior to Exchange 2010 permissions were defined through tools like DSACLS and ADSIEdit. This let you specify what objects a user or group could touch and what they could do to the object as a whole. If a user needed write access to one specific property of an object, but not the other properties, there was no easy way to handle this. RBAC does not define permissions on the object; instead it defines permissions on the PowerShell cmdlets that can modify the object. PowerShell cmdlets get added to a role and a user or group is assigned to the role. If the cmdlet and parameters you need are part of a role you participate in, then you will be able to run the cmdlet.

In the Exchange Management Shell you can run (get-excommand).count to see how many Exchange cmdlets you currently have access to. In the Exchange Control Panel (ECP) and the Exchange Management Console the cmdlets you have access to determine what options are displayed. Therefore if a window in either GUI requires you have specific PowerShell cmdlets in your role, but you do not have them one of two results is possible:

• The window will not be displayed (in fact options that lead to it are unlikely to be offered)
• The window will display, but all content will be disabled (this is typical if you have the relevant Get- cmdlets, but lack one or more of Set, New, Add, etc.)

For more detail around RBAC, please start with the following:

• RBAC and the Triangle of Power http://blogs.technet.com/b/exchange/archive/2009/11/16/3408825.aspx
• Understanding Role Based Access Control http://technet.microsoft.com/en-us/library/dd298183.aspx

Exchange 2010 SP2 contains 71 RBAC roles. However, none of them offer limited subsets of ActiveSync commands that can be assigned to help desk staff. To create such roles you have to tackle them yourself. If your helpdesk works with PowerShell this is relatively straightforward because you can create a role that has only the PowerShell cmdlet and parameters they require. If the users operate exclusively through the ECP this process is more complex, because the user must be able to navigate to the point where the operation is conducted.

In this example the customer needed helpdesk staff to be able to wipe ActiveSync devices through the Exchange Control Panel. The problem was that only members of Organization Management were able to navigate to the proper window in the ECP and carry out a device wipe. Adding the HelpDesk users to the Organization Management role group was out of the question – it simply has too many rights.

The Administrator tried creating an RBAC role that contained only the Clear-ActiveSyncDevice cmdlet. The problem was that the new role did not allow them to access the functionality through the ECP. The ECP did not allow the users to navigate to the place where the “Wipe Device” button is displayed because the button is nested a few levels down. The user needs to be able to list the users in the Organization, see their Phone and Voice properties and be able to open the dialogs along the way. A role that contains only the Clear-ActiveSyncDevice cmdlet does not include the other cmdlets that are required by these other steps in the ECP. What we have to do from here is figure out what we have to add to this role so we can navigate to the window and click the “Wipe Device” button.

The first step in this process is to look at what roles the Organization Management role group is comprised of. To do this we run:

[PS] C:\>$FormatEnumerationLimit=999
[PS] C:\>get-rolegroup "organization management" | fl roles

Roles : {Active Directory Permissions, Address Lists, ApplicationImpersonation, Audit Logs, Cmdlet Extension Agents, Database Availability Groups, Database Copies, Databases, Disaster Recovery, Distribution Groups, Edge Subscriptions, E-Mail Address Policies, Exchange Connectors, Exchange Server Certificates, Exchange Servers, Exchange Virtual Directories, Federated Sharing, Information Rights Management, Journaling, Legal Hold, Mail Enabled Public Folders, Mail Recipient Creation, Mail Recipients, Mail Tips, Mailbox Import Export, Mailbox Search, Message Tracking, Migration, Monitoring, Move Mailboxes, Organization Client Access, Organization Configuration, Organization Transport Settings, POP3 And IMAP4 Protocols, Public Folder Replication, Public Folders, Receive Connectors, Recipient Policies, Remote and Accepted Domains, Retention Management, Role Management, Security Group Creation and Membership, Send Connectors, Support Diagnostics, Transport Agents, Transport Hygiene, Transport Queues, Transport Rules, UM Mailboxes, UM Prompts, UnScoped Role Management, Unified Messaging, User Options, View-Only Audit Logs, View-Only Configuration, View-Only Recipients, MyBaseOptions, MyContactInformation, MyDiagnostics, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, RetentionPolicies, MyTextMessaging, MyVoiceMail, MyMailboxDelegation}

From here we need to discard roles that are not going to be directly related to wiping a device. Some of the roles like “Remote and Accepted Domains” are obviously not going to contain related cmdlets. For the potentially interesting Roles our next step is to find out what they contain. To do that we run a cmdlet like this one:

[PS] C:\storage>Get-ManagementRoleEntry "Mail Recipients\*"

Name Role Parameters
---- ---- ----------
Write-AdminAuditLog Mail Recipients {Comment, Confirm, Debug, DomainController, ErrorAction, Er...
Update-Recipient Mail Recipients {Confirm, Credential, Debug, DomainController, ErrorAction,...
Test-MAPIConnectivity Mail Recipients {Archive, Confirm, Debug, ErrorAction, ErrorVariable, Ident...
Set-User Mail Recipients {AssistantName, CertificateSubject, City, Company, Confirm,...

I have cut the output short here and included only a few lines as a demonstration (the actual cmdlet produces 96 results).

From here the next step is to create new child roles of the roles that we believe are useful for our work. Here is an example:

new-managementrole -parent "Mail Recipients" -name StrictlyRecipActiveSyncDeviceWipe

The role we just created is a child of Mail Recipients, thus it has all the permissions of its parent. Why not use the Mail Recipients role itself? As we progress I intend to remove pieces from this role so that we can achieve the lowest level of permissions possible. Never modify the built-in roles like Mail Recipients because it will break functionality. Another point to raise: a child of a role can only be assigned the functionality of its parent; it cannot be given any rights or access to functionality that is not already included in the parent.

Once we have created our role we need to create a Role Group. This will make it easier to assign the role to users in the future. For our testing we are using an account called WipeTest. Once testing is complete, replace WipeTest with the account(s) or group(s) desired.

New-RoleGroup -Name "OnlyActiveSyncDeviceWipe" -Roles "StrictlyRecipActiveSyncDeviceWipe " -members WipeTest

WipeTest can log into OWA and access the ECP. We find that we can navigate most of the way to the option we want in the ECP, but not all the way. This indicates an additional role is required.

If you look in the Exchange directory (by default c:\Program Files\Microsoft\Exchan ge) you will find the following path “ClientAccess\ecp\PhoneVoice”. Looking through the files in here will give you some clues as to what you might want to add next. The Web.Config file has numerous mentions of OrganizationConfig, but that isn’t specific enough. We can look through the folder to see if any of the files mention specific cmdlets we might be able to use and that are not in the role we have already defined. One that stands out is Set-CasMailbox (it is in QuarantinedDevices.ASCX). We then checked on where that cmdlet resides:

[PS] C:\>Get-ManagementRoleEntry "*\set-casmailbox" | fl name,role,parameters

Name : Set-CASMailbox
Role : Mail Recipients
Parameters : {ActiveSyncDebugLogging, ActiveSyncEnabled, ActiveSyncMailboxPolicy, Confirm, Debug, DisplayName, DomainController, ECPEnabled, EmailAddresses, ErrorAction, ErrorVariable, EwsAllowEntourage, EwsAllowList, EwsAllowMacOutlook, EwsAllowOutlook, EwsApplicationAccessPolicy, EwsBlockList, EwsEnabled, HasActiveSyncDevicePartnership, Identity, IgnoreDefaultScope, ImapEnabled, ImapEnableExactRFC822Size, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, MAPIBlockOutlookNonCachedMode, MAPIBlockOutlookRpcHttp, MAPIBlockOutlookVersions, MAPIEnabled, Name, OutBuffer, OutVariable, OWAEnabled, OwaMailboxPolicy, PopEnabled, PopEnableExactRFC822Size, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, PrimarySmtpAddress, SamAccountName, ShowGalAsDefaultView, Verbose, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : Organization Client Access
Parameters : {ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs, Confirm, Debug, DomainController, ErrorAction, ErrorVariable, Identity, OutBuffer, OutVariable, Verbose, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : User Options
Parameters : {ActiveSyncDebugLogging, Confirm, ErrorAction, ErrorVariable, Identity, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, OutBuffer, OutVariable, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, ShowGalAsDefaultView, WarningAction, WarningVariable, WhatIf}

Name : Set-CASMailbox
Role : MyBaseOptions
Parameters : {ActiveSyncDebugLogging, Confirm, ErrorAction, ErrorVariable, Identity, ImapMessagesRetrievalMimeFormat, ImapSuppressReadReceipt, ImapUseProtocolDefaults, OutBuffer, OutVariable, PopMessagesRetrievalMimeFormat, PopSuppressReadReceipt, PopUseProtocolDefaults, ShowGalAsDefaultView, WarningAction, WarningVariable, WhatIf}

It is interesting to note the parameter differences. We can exclude MyBaseOptions and UserOptions because their parameters would not help us wipe a device. We have already tried a child role of Mail Recipients and that role did not work. That leaves “Organization Client Access” as a role we could try using. You will notice it has access to the ActiveSyncAllowedDeviceIDs and ActiveSyncBlockedDeviceIDs parameters and they are not present in the Mail Recipients role.

Since we have seen Set-CasMailbox listed in the files we can try creating a new child role of “Organization Client Access” and strip out everything except Set-CasMailbox.

new-managementrole -parent "organization client access" -name OrgClientAccessWipeDeviceOnly
get-managementroleentry "OrgClientAccessWipeDeviceOnly\*" |where{$_.name -notlike "*set-casm*"}| Remove-ManagementRoleEntry

Now we add this new role to the Role Group we created earlier:

New-ManagementRoleAssignment -Name "OCA Child ActiveSyncDevice Wipe" -SecurityGroup "OnlyActiveSyncDeviceWipe" -Role OrgClientAccessWipeDeviceOnly

Now when WipeTest tries to wipe the device they can access the button in the ECP. One problem remains: StrictlyRecipActiveSyncDeviceWipe (a child of “Mail Recipients”) still has too many rights. From here we remove most of the cmdlets from StrictlyRecipActiveSyncDeviceWipe using the following cmdlet:

get-managementroleentry "StrictlyRecipActiveSyncDeviceWipe\*" |where{$_.name -notlike "*activesync*"}| Remove-ManagementRoleEntry

The next stage involves adding cmdlets back in to the role one at a time until we can navigate to the proper location in the ECP and conduct a device wipe. The routine is simple: add a cmdlet, try the operation. If it fails log out of OWA, add another cmdlet and try again. When we get it to work we can either stop or go back and remove individual cmdlets to try and achieve a minimum level of permissions. Below are some examples of the cmdlets we can use.

To add a cmdlet back in we need to do this:

add-ManagementRoleEntry "Mail Recipients\get-mailbox" -role StrictlyRecipActiveSyncDeviceWipe

/Aside

If you wanted to put back multiple cmdlets you can use the syntax from the example below:

Get-ManagementRoleEntry "Mail Recipients\*" | where{$_.name -like "get-m*"} | add-ManagementRoleEntry -role StrictlyRecipActiveSyncDeviceWipe

In this blog I only want to insert the cmdlets one at a time, but I included this for illustration.

/End Aside

If we want to remove an individual cmdlet from the role we can use this:

Remove-ManagementRoleEntry "StrictlyRecipActiveSyncDeviceWipe\Get-Mailbox"

(When the “Are You Sure?” prompt appears, select Yes or Yes to All)

In this blog I have included many of the details regarding how I journeyed to the final set of cmdlets. I have left out most of the tedious trial and error, but hopefully included enough detail you can go through this process yourself.

Below I have pasted in a summary of all the cmdlets for those that want to see everything together in a single, concise presentation:

new-managementrole -parent "Mail Recipients" -name StrictlyRecipActiveSyncDeviceWipe
new-managementrole -parent "organization client access" -name OrgClientAccessWipeDeviceOnly
get-managementroleentry "OrgClientAccessWipeDeviceOnly\*" |where{$_.name -notlike "*set-casm*"}| Remove-ManagementRoleEntry

(When the “Are you sure?" prompt is presented, select A)

get-managementroleentry "StrictlyRecipActiveSyncDeviceWipe\*" |where{$_.name -notlike "*activesync*"}| Remove-ManagementRoleEntry

(When the “Are you sure?” prompt is presented, select A)

add-ManagementRoleEntry "Mail Recipients\get-mailbox" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-user" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-recipient" -role StrictlyRecipActiveSyncDeviceWipe
add-ManagementRoleEntry "Mail Recipients\get-casmailbox" -role StrictlyRecipActiveSyncDeviceWipe
New-RoleGroup -Name "OnlyActiveSyncDeviceWipe" -Roles StrictlyRecipActiveSyncDeviceWipe,OrgClientAccessWipeDeviceOnly -members WipeTest

Once these cmdlets are run the WipeTest user (or the user or group you specify) will be able to open OWA, navigate to the ECP and open each of the dialogs needed to reach the point where they can wipe a device.

Thanks to Matt Byrd and Brad Hughes as contributors as I was writing this post.

Chris Pollitt

[#2]

I wish you'd have done this 12 months ago. I had to work it all out for myself. :(

Working out the roles to add back in was tedious as noted above.

I haven't looked at EX2013 but perhaps there is a pre-defined role for this now? Pretty please.

[#3]

Great job!

[#4]

Great to know this is available. Hopefully it is in 2013 also. I was not looking forward to having to do this for our 2013 deployment.

[#5]

I did this for a helpdesk role group but they can't manage another user in ECP. Only myself and my organization is availabe. Any hint what role entries I have to add?