History of Exchange with having wide permissions in AD

Posted on October 14, 2022 by m365guy Leave a comment

On-Premises Exchange servers have always been a different beast when we compare it to other Microsoft products like SQL, SharePoint, and others. Exchange in general has been notorious for having wide permissions within AD. In the past, this has been described as ‘design’. Providing Exchange administrators, the flexibility to manage attributes on Exchange Server objects that are consistent with their role as an Exchange administrator is how Microsoft has described it in the past.

Microsoft has evaluated the rights that are granted to servers that are running Exchange Server and to Exchange administrators in the identified scenarios, which has determined that it is possible to make changes that lower the permissions that are granted within an Active Directory Domain.

This blog post will go back to the older Exchange versions that had these wide permissions and cover some of the default permissions that could lead to elevation of privileges within AD.

All Exchange Server CU versions that are older than the following:

**Source:** https://support.microsoft.com/en-us/topic/reducing-permissions-required-to-run-exchange-server-when-you-use-the-shared-permissions-model-e1972d47-d714-fd76-1fd5-7cdcb85408ed

Means that it takes only a few steps to go from Exchange to being a Domain Admin for example. If you haven’t upgraded the CU level of your Exchange servers to the recent version. It is recommended to do it as soon as possible. Another way would be to implement the Exchange Split Permissions Model to solve this problem.

Exchange Windows Permissions

The first group that we are going to discuss is Exchange Windows Permissions. This group has the following description: “This group contains Exchange servers that run Exchange cmdlets on behalf of users via the management service. Its members have permission to read and modify all Windows accounts and groups. This group should not be deleted.”

Older Exchange versions may see that Exchange Windows Permissions has ‘WriteDACL‘ (Modify Permissions) on the Domain Naming Context. This can lead to Exchange servers elevating their privileges to a Domain Admin. Since being able to modify the permissions on the DNC can lead to assigning yourself DCSync permissions.

To verify whether you have this configuration in your environment. You can run the following command:

NOTE: Replace DC=contoso,DC=com with your AD domain name.

$ADSI=[ADSI]"LDAP://DC=contoso,DC=com"
$ADSI.psbase.get_ObjectSecurity().getAccessRules($true, $true,[system.security.principal.NtAccount]) | Where-Object {$_.IdentityReference -like "*Exchange Windows Permissions*"} | Where-Object {$_.ActiveDirectoryRights -like "*WriteDacl*"} | Where-Object {$_.AccessControlType -like "*Allow*"}

At this example, we can see that Exchange Windows Permissions does indeed have WriteDacl on the Domain Naming Context.

To see the all the permissions of Exchange Windows Permissions we can run the following command:

NOTE: Replace DC=contoso,DC=com with your AD domain name.

$ADSI=[ADSI]"LDAP://DC=contoso,DC=com"
$ADSI.psbase.get_ObjectSecurity().getAccessRules($true, $true,[system.security.principal.NtAccount]) | Where-Object {$_.IdentityReference -like "*Exchange Windows Permissions*"} | Sort-Object ActiveDirectoryRights | Out-GridView

This is the result that we will get:

If you’re not that familiar with Active Directory. You may not recognize what those GUIDs are representing. However, I’ve decided to lay it out, so you don’t have to figure out what all those GUIDs mean.

Besides of WriteDacl, Exchange Windows Permissions has the following permissions on the Domain Naming Context:

Create Organizational Units –> (bf967aa5-0de6-11d0-a285-00aa003049e2)
Create inetOrgPerson Object –> (4828cc14-1437-45bc-9b07-ad6f015e5f28)
Create Computer Objects –> (bf967a86-0de6-11d0-a285-00aa003049e2)
Create Group Objects –> (bf967a9c-0de6-11d0-a285-00aa003049e2)
Create Contact Objects –> (5cb41ed0-0e4c-11d0-a286-00aa003049e2)
Create User Objects –> (bf967aba-0de6-11d0-a285-00aa003049e2)
Write Properties to the userAccountControl attribute –> (bf967a68-0de6-11d0-a285-00aa003049e2)
Write Properties to the countryCode attribute –> (5fd42471-1262-11d0-a060-00aa006c33ed)
Write Properties to the wWWHomePage –> (bf967a7a-0de6-11d0-a285-00aa003049e2)
Add/Remove users from groups –> (bf9679c0-0de6-11d0-a285-00aa003049e2)
- This includes adding members to DnsAdmins as well if you are using the older Exchange CU versions.
Modify the sAMAccountName attribute –> (3e0abfd0-126a-11d0-a060-00aa006c33ed)
Reset the password of User, inetOrgPerson and Computer objects –> (00299570-246d-11d0-a768-00aa006e0529)
Read/Write on the managedBy attribute on groups –> (0296c120-40da-11d1-a9c0-0000f80367c1)
Members in Exchange Windows Permissions can change passwords –> (ab721a53-1e2f-11d0-9819-00aa0040529b)
Delete inetOrgPerson Objects –> (4828cc14-1437-45bc-9b07-ad6f015e5f28)
Delete Computer Objects –> (bf967a86-0de6-11d0-a285-00aa003049e2)
Delete Group Objects –> (bf967a9c-0de6-11d0-a285-00aa003049e2)
Delete Organizational Units –> (bf967aa5-0de6-11d0-a285-00aa003049e2)
Delete Contact Objects –> (5cb41ed0-0e4c-11d0-a286-00aa003049e2)
Delete User Objects –> (bf967aba-0de6-11d0-a285-00aa003049e2)

Exchange Trusted Subsystem

The second group that we are going to talk about is Exchange Trusted Subsystem. This group has the following description: “This group contains Exchange servers that run Exchange cmdlets on behalf of users via the management service. Its members have permission to read and modify all Exchange configuration, as well as user accounts and groups. This group should not be deleted.”

Exchange Trusted Subsystem is by default a member of the Exchange Windows Permissions, so everything that Exchange Windows Permissions can do. Exchange Trusted Subsystem can do the same.

However, let’s focus purely on what rights Exchange Trusted Subsystem have. One of the things that stood out right away is that this group has WriteDACL on Group objects. This permission has been delegated by default on the Domain Naming Context.

What does this mean? It means that accounts in Exchange Trusted Subsystem can add themselves for example to a group like DNSAdmins, which we all know can become Domain Admin. See: https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/from-dnsadmins-to-system-to-domain-compromise

To verify this, we can run this command in PowerShell:

NOTE: Replace DC=contoso,DC=com with your AD domain name.

$ADSI=[ADSI]"LDAP://DC=contoso,DC=com"
$ADSI.psbase.get_ObjectSecurity().getAccessRules($true, $true,[system.security.principal.NtAccount]) | Where-Object {$_.IdentityReference -like "*Exchange Trusted Subsystem*"} | Where-Object {$_.ActiveDirectoryRights -like "*WriteDacl*"} | Where-Object {$_.InheritedObjectType -like "*bf967a9c-0de6-11d0-a285-00aa003049e2*"} | Where-Object {$_.AccessControlType -like "*Allow*"}

At the result, we can see indeed that Exchange Trusted Subsystem has WriteDACL on Group objects.

Exchange Trusted Subsystem also has WriteDACL on Group objects but being delegated on the AdminSDHolder container.

$ADSI=[ADSI]"LDAP://CN=AdminSDHolder,CN=System,DC=contoso,DC=com"
$ADSI.psbase.get_ObjectSecurity().getAccessRules($true, $true,[system.security.principal.NtAccount]) | Where-Object {$_.IdentityReference -like "*Exchange Trusted Subsystem*"} | Where-Object {$_.ActiveDirectoryRights -like "*WriteDacl*"} | Where-Object {$_.InheritedObjectType -like "*bf967a9c-0de6-11d0-a285-00aa003049e2*"} | Where-Object {$_.AccessControlType -like "*Allow*"}

At the result, we can see that this group has been delegated on the AdminSDHolder container.

Let’s find all the permissions of Exchange Trusted Subsystem. Open PowerShell and run the following command:

$ADSI=[ADSI]"LDAP://DC=contoso,DC=com"
$ADSI.psbase.get_ObjectSecurity().getAccessRules($true, $true,[system.security.principal.NtAccount]) | Where-Object {$_.IdentityReference -like "*Exchange Trusted Subsystem*"} | Sort-Object ActiveDirectoryRights | Out-GridView

This is the result that we will get:

Besides of modifying the DACL of groups, Exchange Trusted Subsystem has the following rights on the Domain Naming Context:

Write properties on Exchange-Personal-Information
Write properties on the adminDisplayName attribute
Write properties on the displayName attribute
Write properties containing user attributes that describe user public information
Write properties on displayNamePrintable attribute
Write properties on mail attribute
Write properties on textEncodedORAddress attribute
Write properties on msExchADCGlobalNames attribute
Write properties on givenName attribute
Write properties on garbageCollPeriod attibute
Write properties on legacyExchangeDN attribute
Create/Delete and Write permissions on publicFolder attribute
Full control over the msExchDynamicDistributionList attribute
Modifying the DACL of AD groups
Full control over the msExchActiveSyncDevices attribute

Additional to all of this, Exchange Trusted Subsystem is also a member of the Local Administrators group on every Exchange server.

Organization Management

Organization Management is like the Domain Admins of Exchange. This group has Full control over all the Exchange groups, which includes Exchange Windows Permissions and Exchange Trusted Subsystem. Organization Management is also a member of the Local Administrators group on every Exchange server.

Frequently Asked Questions

Q1: “What do I need to do to limit the attack path from Exchange to Domain Admin?”

Answer: It is recommended to update all your Exchange servers to the latest CU version. Besides of that, consider taking a look at the Exchange Split Permissions Model. This model will separate the tasks between Exchange and AD objects, which reduces the attack surface a lot.

Q2: “I’ve moved completely to Exchange Online. Do I still need to use these groups and if not. What should I do next?”

Moving to Exchange Online means that it would be way easier to adopt the Exchange Split Permissions Model. Since you don’t rely on any On-Premises Exchange groups anymore.

Q3: “I won’t be able to implement the Exchange Split Permissions anytime soon. What are the temporary solutions to reduce the elevation of privileges of Exchange becoming DA?”

There are two PowerShell scripts that I would recommend mitigating this problem. However, use this at your own risks. I personally haven’t found any concerns yet, but this always depends on each organization.

The first PowerShell script would be Fix-DomainObjectACL.ps1. In short, this script will revoke WriteDACL from the Exchange Windows Permissions group on the Domain Naming Context.

The second PowerShell script will be Fix-DNSAdmins-DACL.ps1

We can specify the -Fix parameter and it will clean WriteDACL from the DNSAdmins group. WriteDACL will be removed from Exchange Trusted Subsystem on the DNSAdmins group.

We can confirm this by the using the following command in PowerShell:

$ADSI=[ADSI]"LDAP://CN=DnsAdmins,CN=Users,DC=contoso,DC=com"
$ADSI.psbase.get_ObjectSecurity().getAccessRules($true, $true,[system.security.principal.NtAccount]) | Where-Object {$_.IdentityReference -like "*Exchange Trusted Subsystem*"} | Where-Object {$_.ActiveDirectoryRights -like "*WriteDacl*"}

At this example, we can see that there is no result. This means that Exchange Trusted Subsystem has no more WriteDACL on the DNSAdmins group.