Busting the Exchange Trusted Subsystem Myth
Posted by Devin in Computers, Exchange, WorkIt’s amazing what kind of disruption leaving your job, looking for a new job, and starting to get settled in to a new job can have on your routines. Like blogging. Who knew?
At any rate, I’m back with some cool Exchange blogging. I’ve been getting a chance to dive into a “All-Devin, All-Exchange, All The Time” groove and it’s been a lot of fun, some of the details of which I hope to be able to share with you in upcoming months. In the process, I’ve been building a brand new Exchange 2010 lab environment and ran smack into a myth that seems to be making the rounds among people who are deploying Exchange 2010. This myth gives bum advice for those of you who are deploying an Exchange 2010 DAG and not using an Exchange 2010 Hub Transport as your File Share Witness (FSW). I call it the Exchange Trusted Subsystem Myth, and the first hint of it I see seems to be on this blog post. However, that same advice seems to have gotten around the net, as evidenced by this almost word-for-word copy or this posting that links to the first one. Like many myths, this one is pernicious not because it’s completely wrong, but because it works even though it’s wrong.
If you follow the Exchange product group’s deployment assumptions, you’ll never run into the circumstance this myth addresses; the FSW is placed on an Exchange 2010 HT role in the organization. Although you can specify the FSW location (server and directory) or let Exchange pick a server and directory or you, the FSW share isn’t created during the configuration of the DAG (as documented by fellow Exchange MVP Elan Shudnow and the “Witness Server Requirements” section of the Planning for High Availability and Site Resilience TechNet topic). Since it’s being created on an Exchange server as the second member of the DAG is joined, Exchange has all the permissions it needs on the system to create the share. If you elect to put the share on a non-Exchange server, then Exchange doesn’t have permissions to do it. Hence the myth:
- Add the FSW server’s machine account to the Exchange Trusted Subsystem group.
- Add the Exchange Trusted Subsystem group to the FSW server’s local Administrators group.
The sad part is, only the second action is necessary. True, doing the above will make the FSW work, but it will also open a much wider hole in your security than you need or want. Let me show you from my shiny new lab! In this configuration, I have three Exchange systems: EX10MB01, EX10MB02, and EX10MB03. All three systems have the Mailbox, Client Access, and Hub Transport roles. Because of this, I want to put the FSW on a separate machine. I could have used a generic member server, but I specifically wanted to debunk the myth, so I picked my DC EX10DC01 with malice aforethought.
- In Figure 1, I show adding the Exchange Trusted Subsystem group to the Builtin/Administrators group on EX10DC01. If this weren’t a domain controller, I could add it to the local Administrators group instead, but DCs require tinkering. [1]
Figure 1: Membership of the Builtin/Administrators group on EX10DC01
- In Figure 2, I show the membership of the Builtin/Administrators group on EX10DC01. No funny business up my sleeve!
Figure 2: Membership of the Exchange Trusted Subsystem group
- I now create the DAG object, specifying EX10DC01 as my FSW server and the C:\EX10DAG01 directory so we can see if it ever gets created (and when).
- In Figure 3, I show the root of the C:\ drive on EX10DC01 after adding the second Exchange 2010 server to the DAG. Now, the directory and share are created, without requiring the server’s machine account to be added to the Exchange Trusted Subsystem group.
Figure 3: The FSW created on EX10DC01
I suspect that this bad advice came about through a combination of circumstances, including an improper understanding of Exchange caching of Active Directory information and when the FSW is actually created. However it came about, though, it needs to be stopped, because any administrator that configures their Exchange organization is opening a big fat hole in the Exchange security model.
So, why is adding the machine account to the Exchange Trusted Subsystem group a security hole? The answer lies in Exchange 2010’s shift to Role Based Access Control (RBAC). In previous versions of Exchange, you delegated permissions directly to Active Directory and Exchange objects, allowing users to perform actions directly from their security context. If they had the appropriate permissions, their actions succeeded.
In Exchange 2010 RBAC, this model goes away; you now delegate permissions by telling RBAC what options given groups, policies, or users can perform, then assigning group memberships or policies as needed. When the EMS cmdlets run, they do so as the local machine account; since the local machine is an Exchange 2010 server, this account has been added to the Exchange Trusted Subsystem group. This group has been delegated the appropriate access entries in Active Directory and Exchange databases objects, as described in the Understanding Split Permissions TechNet topic. For a comprehensive overview of RBAC and how all the pieces fit together, read the Understanding Role Based Access Control TechNet topic.
By improperly adding a non-Exchange server to this group, you’re now giving that server account the ability to read and change any Exchange-related object or property in Active Directory or Exchange databases. Obviously, this is a hole, especially given the relative ease with which one local administrator can get a command line prompt running as one of the local system accounts.
So please, do us all a favor: if you ever hear or see someone passing around this myth, please, link them here.
Busted!
[1] Yes, it is also granting much broader permissions than necessary to make a DC the FSW node. Now the Exchange Trusted Subsystem group is a member of the Domain Admins group. This is probably not what you want to do, so really, don’t do this outside of a demo lab.
Entries (RSS)
[...] This post was mentioned on Twitter by devinganger, Henrik Walther. Henrik Walther said: RT @devinganger: On Devin on Earth: Busting the Exchange Trusted Subsystem Myth http://bit.ly/5ko5rU [...]
Absolutely correct – I need to update that post. That “myth” occurred becase during that Beta/RC timeframe there was no documentation released about what the necessay permissions were so it was purely me poking around to see what happened. Definitely went looking on Technet and most of the DAG articles were empty placeholders back then, so doin the correct thing was essentially impossible. . Good post though – this should clear it up.
[...] Devin on Earth » Busting the Exchange Trusted Subsystem Myth Posted on December 20, 2009 by johnacook http://www.thecabal.org/2009/12/busting-the-exchange-trusted-subsystem-myth/ [...]
Hey Devin, thanks for the link. I’m a bit surprised to see those errors on those two blogs about adding the computer account to the Exchange Trusted Subsystem group when indeed, that is not needed. I posted on those 2 blogs hoping they’ll change their guidance.
Tom — I figured that’s a large part of what it was. Between lack of documentation and the incremental process of making one change, seeing if it worked, making another change, seeing if it worked, and then caching finally updating so that the change you make that should have been enough not working yet…
Elan — dude, you keep rocking the house.
[...] permissions for a DAG’s FSW. Consequently, it had a major error. You’ll want to visit Devin’s page for a full explanation and the correct way to set up the DAG. Always helps when you can read the [...]
[...] –> http://www.thecabal.org/2009/12/busting-the-exchange-trusted-subsystem-myth/ [...]
Great article. Your text in the bullet above figure 2 is a little confusing.