RBAC and Exchange Trusted Subsystem
For years support has been saying “Don’t uncheck Allow Inheritable Permissions” but customers have needs that require them to secure their environment and apply additional permissions and remove some of the permissions that are there. Usually, its not until later on that a problem arises, usually not until a reboot has been done. The call usually goes, “So Mr Customer what has changed?” Seeing as the permissions were changed weeks or even months ago, the customer honestly can say nothing. A little while later in the conversation or a look at the System log we come to find out a reboot happened. Ok great, let’s go find out what was changed. We usually find the customer needed to make a change to lock something down or add a special account to the permissions and inadvertently checks the wrong box or forgets to apply the permissions back in. Or as in some cases, left the lower level folders with the “Allow inheritable permissions to propagate from the parent” unchecked. Everything works fine until you introduce Exchange 2010.
Our latest version of Exchange introduces a new character, the Exchange Trusted Subsystem. The Exchange Trusted Subsystem (ETS) was created to support the new Role Based Access Control (BAC) model. ETS is a highly-privileged Universal Security Group that has the Read and Write access on all Exchange related objects your Exchange Organization. If you take a look at the Technet Article Exchange 2010 Deployment Permissions Reference you will see just what permissions are set as you run each Setup /prepare* command (go ahead, expand out the bullets) . The point is, this is an extremely important account and should be treated with care.
So now we know what the ETS is all about, lets go back to the “Allow Inheritable Permissions”. Security people are always trying to lock down their environment so that the right people have permissions to certain objects and others are locked out. Understandable, as most of corporate theft doesn’t come from the outside, it comes from within the corporation itself. There is always a fine line that when crossed creates one of the biggest headaches known to Support. I ran into a case yesterday that many moons ago, an IT Admin removed the “Include inheritable permissions from this object’s parent” on all containers under the Organization in AD. ETS got applied at the Organization level, but the lower level folders never got ETS. That is when the frustration begins. The customer was trying to work with one of our BETA products and needed to make sure that the Arbitration Mailboxes and the FederatedEamil mailbox were provisioned properly. In their installation they deleted their first databases and recreated them with distinct names. So we need to set the DiscoverySearchMailbox as an Arbitration mailbox. Not a big deal as we have well documented steps to do this.
So we go and run the following command:
Enable-Mailbox "DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}" –Arbitration and we get a cryptic response:
The user's Active Directory account must be logon-disabled for linked, shared, or resource mailbox.
+ CategoryInfo : InvalidArgument: (Discovery Search Mailbox:ADUser) [Enable-Mailbox], RecipientTaskExcept
ion
+ FullyQualifiedErrorId : BC7CCA19,Microsoft.Exchange.Management.RecipientTasks.EnableMailbox
Hmm the DiscoverySearchMailbox is a default account that should already be disabled. We check and sure enough it is disabled. We start looking at the arbitration mailboxes to see if they are working correctly and we run get-mailbox –arbitration and get nothing returned, we just get sent back the command prompt. Well lets look what happens when we run this Enable-Mailbox in verbose mode:
C:\Windows\system32>Enable-Mailbox "DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}" -Arbitration -De
bug -Verbose
VERBOSE: [14:47:19.205 GMT] Enable-Mailbox : Active Directory session settings for 'Enable-Mailbox' are: View Entire
Forest: 'False', Default Scope: 'XXXXXXX.com', Configuration Domain Controller: 'XXXX.com',
Preferred Global Catalog: 'XXXXX.com', Preferred Domain Controllers: '{
XXXXX.com, XXXXX.com }'
VERBOSE: [14:47:19.208 GMT] Enable-Mailbox : Runspace context: Executing user: Admin
Accounts/Enterprise Admin, Executing user organization: , Current organization: , RBAC-enabled: Enabled.
VERBOSE: [14:47:19.208 GMT] Enable-Mailbox : Beginning processing.
VERBOSE: [14:47:19.211 GMT] Enable-Mailbox : Instantiating handler with index 0 for cmdlet extension agent "Query Base
DN Agent".
VERBOSE: [14:47:19.212 GMT] Enable-Mailbox : Instantiating handler with index 1 for cmdlet extension agent "Rus Agent".
VERBOSE: [14:47:19.213 GMT] Enable-Mailbox : Instantiating handler with index 2 for cmdlet extension agent "Mailbox
Resources Management Agent".
VERBOSE: [14:47:19.214 GMT] Enable-Mailbox : Instantiating handler with index 3 for cmdlet extension agent
"Provisioning Policy Agent".
VERBOSE: [14:47:19.215 GMT] Enable-Mailbox : Instantiating handler with index 4 for cmdlet extension agent "Admin Audit
Log Agent".
VERBOSE: [14:47:19.699 GMT] Enable-Mailbox : Current ScopeSet is: {Domain Read Scope: {, }, Domain Write Scope : {,
}, Configuration Scope: {, }, Server Configuration Scope : {, }, , Exclusive Scope: {, }}
VERBOSE: [14:47:19.701 GMT] Enable-Mailbox : Searching objects "DiscoverySearchMailbox
{D919BA05-46A6-415f-80AD-7E09334BB852}" of type "ADUser" under the root "$null".
VERBOSE: [14:47:19.734 GMT] Enable-Mailbox : Previous operation run on domain controller XXXXX.com.
Confirm
The user's Active Directory account must be logon-disabled for linked, shared, or resource mailbox.
[Y] Yes [A] Yes to All [H] Halt Command [?] Help (default is "Y"): Y
The user's Active Directory account must be logon-disabled for linked, shared, or resource mailbox.
+ CategoryInfo : InvalidArgument: (Discovery Search Mailbox:ADUser) [Enable-Mailbox], RecipientTaskExcept
ion
+ FullyQualifiedErrorId : BC7CCA19,Microsoft.Exchange.Management.RecipientTasks.EnableMailbox
VERBOSE: [14:47:22.778 GMT] Enable-Mailbox : Ending processing.
Ok, lets see if we can create a new user. We start seeing “Insufficient Rights to perform this action”. Looking at the RBAC rights we are a member of the Organizational Management group. That should be sufficient to complete the operation. So we log in with the Root Forest account and we are still getting an Access Denied. We add the Recipient Management Role to the user and still the same thing. So we have all the rights, yet we cannot create a user. There are 2 possible causes, there is a problem with the RBAC rights, which we know can’t be because we can verify we have the proper rights, but better yet, we actually can see the commands that are needed to be run. You see if you don’t have the proper RBAC roles, you won’t even be able to run the command. So in our case, we can run the command, so we must not have rights to AD.
That leads us to what could be our second issue, rights to AD. Our account is an Enterprise Admin, Schema Admin, Domain Admin, etc. You get the point, we have rights to do whatever we want in AD. So we start at the top of the Organization and we see that the Exchange Trusted Subsystem is listed there with the proper AD rights. What about our sub-folders. We check the container where we are creating the user and low and behold, the ETS is not listed. Click the Advanced button and the “Allow inheritable permissions to propagate from the parent” was unchecked. Checked that button and replicate AD and run Get-Mailbox –Arbitration and we see our 3 arbitration mailboxes.
We like to call this “Defeated by Checkbox”.
Hope this helps