Richard's Exchange Ramblings

Things I've seen as an Exchange Support Escalation Engineer

Exchange 2010 and the Exchange Trusted Subsystem

Exchange 2010 and the Exchange Trusted Subsystem

  • Comments 9
  • Likes

In this case, the problem was initially manifesting itself as the following error when trying to create a new mailbox in the first database created with installation of the server:
Active Directory operation failed on adserver.domain.com. This error is not retriable. Additional information: Insufficient access rights to perform the operation.
Active directory response: 00002098: SecErr: DSID-03150E8A, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
The user has insufficient access rights.

Further it was found that the customer got a similar error when trying to create a new database:
Active Directory operation failed on adserver.domain.com. This error is not retriable. Additional information: Access is denied.
Active directory response: 00000005: SecErr: DSID-03152492, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
    + CategoryInfo          : NotSpecified: (0:Int32) [New-MailboxDatabase], ADOperationException
    + FullyQualifiedErrorId : 36F6B416,Microsoft.Exchange.Management.SystemConfigurationTasks.NewMailboxDatabase

This ended up coming down to a case of the Exchange Trusted Subsystem not having the correct permissions on the Databases container in AD to create the new database. The questions here might be, “What is the Exchange Trusted Subsystem? And why does its permissions matter? Shouldn’t the permissions of the administrator on the container be what’s important?”

Well, to answer these questions, all commands in Exchange 2010 are now actually executed by the Exchange Trusted Subsystem, after going through user access checks in Role Based Access Control (RBAC).

More about RBAC and permissions can be looked at here:
http://technet.microsoft.com/en-us/library/dd298183.aspx
http://technet.microsoft.com/en-us/library/dd638106.aspx

The second article notes:
If RBAC allows an action to proceed, the action is performed in the context of the Exchange Trusted Subsystem and not the user's context. The Exchange Trusted Subsystem is a highly privileged universal security group (USG) that has read/write access to every Exchange-related object in the Exchange organization. It's also a member of the Administrators local security group and the Exchange Windows Permissions USG, which enables Exchange to create and manage Active Directory objects.

So, how did we figure out that the Exchange Trusted Subsystem permissions were the problem?

A DSACLS of the Databases container showed the Exchange Trusted Subsystem group missing from the Permissions on the container, so I could only wonder where else it is missing. It should have an inherited Full Control there, inherited from the CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com container.

The following document references the Exchange 2010 Deployment permissions:
http://technet.microsoft.com/en-us/library/ee681663.aspx

This gets set during setup /prepareAD.

In this case, setup /prepareAD had been run again to try and solve the issue, but did not work. So why not?

When we checked, we found that we did have the Exchange Trusted Subsystem group with full control on the Microsoft Exchange container. That’s why the prepareAD didn’t fix it.

So that means that somewhere between the Microsoft Exchange container and the Databases container, the permissions inheritance was disabled. You can see the Inheritance setting in the Advanced area on the Security for each container. You can use ADSIEdit to open the Configuration container, and then drill down to these containers:

Services
Microsoft Exchange
First Organization – (check here)
Administrative Groups – (check here)
Exchange Administrative Group (FYDIBOHF23SPDLT) – (check here)

Here is an example of what this looks like:

image

If the permissions inheritance is disabled on one of the ones I have indicated to check, it needs to be re-enabled, and the permissions should then be fixed.

In our case, it was missing at the Administrative Groups level. Once that was fixed, new mailboxes and new databases could be created without error.

Comments
  • Thanks, your the best!

  • What if all these permissions are in place and correct and it still doesn't work?  I am getting access denied and I checked the permissions.  Everything is correct according to what you have above.  Also I can see that the new container is getting created, but access is denied.

  • I got it.  Even though the permissions were correct, I still had to re-run the setup /PrepareAD again in order to fix this issue.  

  • Great aticle! Helped me out on a weird problem wih permissions for some addresslists.

  • Hi can anyone tell me the meaning of Exchange Trusted Subsystem universal security group purpose? I am not able to find any related document by goggling it. please help me.

    await your reply, please post your reply to me @ smooth.munna@gmail.com.

    regards,

    Bhalotia

  • Hi Richard,

    Thanks for this post, it helped me solve a similar issue I was having, though my case was slightly different.

    The Exchange Trusted Subsystem did not get added to the Exchange Windows Permissions group. And the Exchange Windows Permissions group was not granted any rights in the domain, so I could not create any AD objects through the Exchange shell. I solved this by granting the Exchange Windows Permissions group the various rights necessary to create objects in AD at the root of the AD container.

    Any idea why this would happen? I ran prepareAD prior to install, and tried running afterwards too but it did nothing.

    Cheers,

    Matt

  • Quick followup to my previous comment, I ran "setup.com /preparedomain testdomain.local" and it resolved the issues. I previously ran "setup.com /preparead" and although it ran successfully it did not complete all of the tasks.

  • Hi,

    This can much easily be done if u just go into the "Active Directory users and Computers".

    then drop down to:

    "Microsoft Exchange Security", Right click on "Exchange Trusted Subsystem" and choose "Properties"

    In the properties go to "Manage" and double click the server that has the Exchange 2010 installed and then go to "Delegation" and make sure to choose "Trust this computer for delegation to any servive (Kerberos Only) and your problem will be solved

    Cheers,

    Ralph C. Soliano

  • Hi, We are able to create mailbox databases but we are getting this error when we are trying to create public folder DB

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment