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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.