Three years ago I wrote a document titled “Removing Exchange’s ability to impact Tier 0 and Tier 1” that was distributed internally at Microsoft as well as to dozens of Microsoft customers as part of Cybersecurity services delivered through Microsoft Consulting Services (MCS).
I had always intended to get this document published publicly, but for one reason or another, it never happened. With KB4490059 being released in response to @_dirkjan‘s #PriveExchange vulnerability, I’ve decided it’s beyond time to just share it here on my blog. KB4490059 is a step in the right direction. You can add these mitigations on top of it for even further protections, or perhaps find a more compelling reason to switch to the Active Directory Split Permissions model.
Removing Exchange’s ability to impact Tier 0 and Tier 1
Exchange is tightly integrated with Active Directory. When Exchange is installed, the Active Directory Schema is extended, and several highly privileged groups are created. These privileged groups are granted rights to a large number of objects within Active Directory. A compromised Exchange Server can easily lead to complete control of Tier 1, and in many instances Tier 0.
For more information on the Tier model, see “Securing Privileged Access”.
In Exchange 2010 and later, there are two options for
mitigating this risk. Both should be evaluated carefully before implementation.
It is only necessary to implement one of these two options.
Mitigation Option 1 –
Implement the Active Directory Split Permissions Model
Starting with Exchange 2010, there are three Permissions Models available.
Of the three, the Active Directory Split Permissions Model,
is the only one that can mitigate this risk without additional modifications to
Active Directory. Because this model does not allow Exchange to modify security
principles (i.e. create/delete/reset password) or group membership (i.e. add
members to security groups that may grant access to other systems), compromise
of an Exchange Server is contained to the Exchange environment when running
under this permissions model.
This permissions model isn’t for everyone. You should
carefully consider the impact switching to Active Directory Split Permissions
may have on your organization. It may require a significant change in user
provisioning, business practices, or workflows that revolve around Exchange. It
is also important to note that while this permissions model is fully supported
by the Exchange Product Group, it does not receive the same level of testing as
the default Shared Permissions model.
If you’ve determined that the Active Directory Split
Permissions Model is right for your organization, you can switch to it by
running the following setup command:
more information on configuring split permissions, see “Configure Exchange 2010 for Split Permissions”.
Implementing the Active Directory Split Permissions model
both removes Exchange from Tier 0, placing it in Tier 1, and reduces potential
impact to Tier 1.
Mitigation Option 2 –
Reduce privileges granted to Exchange in Active Directory
If your organization needs to use the default Shared
Permissions Model, the RBAC Split Permissions Model, or still has legacy
versions of Exchange present, modifications to permissions in Active Directory
are required to mitigate this risk.
To remove Exchange’s potential to impact to Tier 0,
permissions granted to Exchange’s privileged groups must be removed from the Access
Control List (ACL) on the following groups and their members in all domains
within the Active Directory Forest Exchange has been installed in, to include
any nested groups and members of those nested groups.
Policy Creators Owners
With the exception of the last 3 entries above, these groups
should already be protected by AdminSDHolder, which prevents them from
inheriting permissions that would allow Exchange’s privileged groups (Exchange
Trusted Subsystem, Exchange Windows Permissions, Organization Management, etc.)
to take control of them. Members of these groups should have the same
protection. However, since Account Operators, Backup Operators, Print
Operators, and Server Operators, can be excluded from AdminSDHolder protection,
it is worthwhile to take the extra step of removing Exchange’s permission to
all of the above groups (if present).
Because the permissions are inherited, the easiest way to
accomplish this, is to place all Tier 0 users and groups into the same OU,
block inheritance on that OU, and restrict permissions on the ACL for that OU.
Full Control (GenericAll), Write (GenericWrite), Modify Permissions
(WriteDacl), Write Member (WriteMember), and Change Password (note that Change
Password permissions should NOT be removed from “Everyone” or “SELF”), are the
permissions that should be removed from any object that should not have the
ability to manipulate Tier 0 OUs/users/groups. In most cases the entire
security principal can be removed from the Tier 0 OUs/users/groups.
To remove Exchange’s potential to impact Tier 1, a similar
approach to the above must be taken.
Exchange’s permissions on the ACLs of users and groups with privileged
access to Tier 1 assets.
Because the permissions are inherited, the easiest way to
accomplish this, is to place all Tier 1 privileged users and groups into the
same OU, block inheritance on that OU, and restrict permissions on the ACL for
that OU. Full Control (GenericAll), Write (GenericWrite), Modify Permissions
(WriteDACLl), and Write Member (WriteMember), are the permissions that should
be removed from any object that should not have the ability to manipulate Tier
1 privileged users/groups. In most cases the entire security principal can be
removed from the ACL on the Tier 1 OUs/users/groups.
For example, Exchange should not have permissions to an
account or group that grants privileged access to a SQL server.
Privileged accounts and groups should NOT be mail enabled.
Therefore removing Exchange’s permissions from them should have no negative
impact on operations. If an account
with, or a group used to grant privileged access to, any system, regardless of
what tier it resides in, has been mail enabled, privileges should either by
removed, or they should be mail disabled. Either way, it may be necessary to
create unprivileged accounts/groups for mail use, or non-mail enabled
accounts/groups for privileged access use, in order to avoid disruptions.
This approach is not tested by the Exchange Product Group. Failure to exercise caution when implementing this approach could result in damage to the Exchange environment.
Service Packs and Cumulative Updates in Exchange often
include Schema updates to Active Directory. Because Schema extensions and Active Directory
preparation require Schema Admins and Enterprise
Admins privileges, this portion of updating Exchange is a Tier 0 operation.
Schema extensions and Active Directory preparation must be performed from a
Tier 0 Privileged Access Workstation (PAW).
Schema extension and Active Directory preparation performed
during an update to Exchange may overwrite some Exchange related settings in
Active Directory. It is recommended that permissions on Tier 0 and Tier 1 set
according to the guidance above are validated after every Exchange update install.