By now you may have read or heard that the /PrepareDomain operation in the Exchange 2010 Release Candidate (RC) applies certain Access Control Entries (ACEs) on the AdminSDHolder object within Active Directory. In particular, /PrepareDomain grants the Exchange Windows Permissions universal security group (USG) the ability to modify the members attribute, the ability to change and reset passwords, and the ability to modify the permissions of any object protected by the AdminSDHolder role.
Note: For those unfamiliar with the AdminSDHolder role, it is a special role within Active Directory that evaluates, on an hourly basis, the Access Control List (ACL) of certain security groups and the members of those groups (known as protected groups, e.g., Enterprise Admins) and resets the ACL with specific ACEs if the ACL doesn’t match the AdminSDHolder role ACL. For more information, please see http://support.microsoft.com/kb/232199 and http://support.microsoft.com/kb/318180.
By default, no user accounts are members of the Exchange Windows Permissions security group. In fact the only member of this group is the Exchange Trusted Subsystem security group, which contains only Exchange 2010 server computer objects. The majority of permissions applied within Active Directory via the Exchange 2010 RC Setup process are for these two security groups.
However, as a result of the ACEs applied on AdminSDHolder, a malicious administrator could elevate their privileges and thus gain control of the Active Directory forest. In particular, the malicious administrator must grant themselves membership in the Exchange Windows Permissions security group. A malicious administrator could either be a person that simply has local administrative rights to log on to an Exchange 2010 RC server, or be a person that is a member of the Exchange Organization Management role. Once the malicious administrator is a member of the Exchange Windows Permissions security group, the malicious administrator can elevate themselves to domain administrator or enterprise administrator.
In previous versions of Exchange we relied upon setting ACEs within Active Directory for administrators to be able to manage objects within the domain partition. Beginning with Exchange 2010, we are providing a new authorization layer inside of Exchange, known as Role Based Access Control (RBAC), instead of relying upon applying ACEs for every account that requires the appropriate permissions. Exchange administrators are granted the ability to perform certain operations within a specific scope through RBAC. The Exchange server, in turn, executes the authorized actions on behalf of the administrator or users via the permissions granted within Active Directory through the Exchange Windows Permissions and Exchange Trusted Subsystem security groups. For more information on RBAC, please see http://technet.microsoft.com/en-us/library/dd298183(EXCHG.149).aspx.
As its name implies, RBAC provides access to administrative functions via roles. Out of the box, Exchange 2010 ships with several default roles. In order to provide an Exchange administrator a holistic experience, roles like Organization Management and Recipient Management provide the ability to create accounts and to manage the mail-related and GAL-related properties of those accounts.
The ACEs being applied are at the domain partition level. However, groups and accounts that are protected via AdminSDHolder do not inherit permissions. Instead they receive their own defined set of permissions that are specified on the AdminSDHolder container within the domain partition. The same permissions that are applied to the domain partition are also currently applied to the AdminSDHolder container to allow customers to mail-enable protected accounts and manage them, should they wish to do so. However, as some have correctly pointed out, that enables an elevation of privilege scenario that is unacceptable in any environment. Microsoft agrees with this assessment and concurs that Exchange 2010 cannot ship with the permissions assigned to the AdminSDHolder role that allow for Active Directory forest privilege elevation. The Exchange Product Group has evaluated several ways to remove this privilege elevation scenario while still ensuring that we provide customers the flexibility they need to manage mail-enabled recipients within Active Directory.
To that end, the released to manufacturing (RTM) version of Exchange 2010 includes the following changes with respect to the ACEs applied by Exchange within the domain partition:
- /PrepareDomain no longer applies ACEs granted to Exchange Windows Permissions USG on the AdminSDHolder container. If /PrepareDomain detects the ACEs granted to Exchange Windows Permissions USG on the AdminSDHolder container, /PrepareDomain will remove them.
- /PrepareDomain no longer applies the extended right ACE User-Change-Password to the Exchange Servers USG on the AdminSDHolder container. If /PrepareDomain detects this ACE granted to Exchange Servers USG on the AdminSDHolder container, /PrepareDomain will remove it.
- /PrepareDomain no longer applies the extended right ACE User-Change-Password to the Exchange Servers USG on the domain partition. If /PrepareDomain detects this ACE granted to Exchange Servers USG on the domain partition, /PrepareDomain will remove it.
- /PrepareDomain no longer applies an unscoped DeleteTree and WriteDACL ACEs on the domain partition. Instead, these ACEs are scoped specifically to user and inetOrgPerson class objects.
Due to the permission changes described above:
- Members of Exchange Windows Permissions USG will not be able to alter the membership of the Enterprise Admins or Domain Admins security groups.
- Members of Exchange Windows Permissions USG cannot change or force the password reset of an account protected by AdminSDHolder.
- The permission structure of any account or group protected by AdminSDHolder cannot be altered by members of Exchange Windows Permissions.
- Exchange administrators will not be able to create/delete AdminSDHolder protected accounts.
This change ensures parity with previous versions of Exchange Server which allows customers to mail-enable accounts protected by AdminSDHolder. Please note, however, that this is not a best practice and we do not recommend that you do so. Exchange, like Windows, recommends customers follow best practices and maintain separate accounts: one account for administration of Active Directory, and one account for regular day-to-day use (including email).
If you have any questions, please let us know.