Exchange AD Split Permissions without regrets
On-Premises Exchange Server installations are still prevalent even for organizations that have moved all mailboxes to the cloud. Also, they are still very powerful within Active Directory so most times there is a strong attack path on compromising the whole AD and with that usually much of the corporate IT. Switching to the so called “AD Split permissions” removes the critical permissions and I have engineered a solution that removes it’s downsides that usually prevented the adoption.
TLDR: what if we remove the downsides?
I found a way to re-grant the AD and RBAC permissions where the Exchange user, groups, contacts, etc. reside. This way there is no adoption needed for admins or identity management systems, which in my experience was the blocker for most companies to implement it. And we still get the security benefit against lateral movement and domain compromise.

It’s achieved in three steps:
- Implement AD split permission model
- Grant Exchange servers the lost AD permissions, but only on the relevant OUs
- Grant Exchange RBAC to re-enable missing PowerShell cmdlets
All via Microsoft’s guidance, AD ACLs or Exchange RBAC assignments.
Why do we care (now)?
It has been largely overlooked or ignored since it was introduced with Exchange 2010 SP1. But the default shared permissions model represents a big security risk to Active Directory takeover. Combined with Exchange being notorious for remote exploits these last few years, it’s time to act!
The problem originates from privileges granted to the root of a domain that get inherited throughout the domain.
- modify permissions on users and groups (effectively full access)
- modify group members
- reset password on users
- create/delete users and groups

Only certain high privileged Tier0 users and groups are protected by the AdminSDHolder process (attribute admincount=1) and in many environments there will be unprotected users or groups that could allow compromise of the domain and/or forest or at least cause serious impact.
Prominent examples:
- Entra Connect Sync account when using PWHashSync
- Default groups
- Allowed RODC Password Replication Group together with EntraConnect account (If a real Windows RODC exists)
- Also see Untrustworthy Trust Builders: Account Operators Replicating Trust Attack (AORTA) - SpecterOps showing more paths (Account Operators group is a similar threat)
- Emptying Protected Users to create attack vectors by removing protections
- Unprotected custom groups or admin/service accounts
- Write permission on GPOs (applying to domain controller)
- Managing access to AD backups, backup server, PKI templates, hypervisor, ...
It is very hard to retroactively contain all these current and future potential pathways. For the _ADM custom OU you could disable ACL inheritance, but most default objects may not be moved from the default Builtin OU or Users container and remain vulnerable.
It is much better to remove the powerful permissions from the root, which is done by implementing the Active Directory split permissions model. Configure Exchange Server for split permissions | Microsoft Learn
And Microsoft agrees “…encouraged to implement Active Directory split permissions” Active Directory Hardening Series - Part 7 – Implementing Least Privilege | Microsoft Community Hub
But why is no one doing it?
As split permissions weren’t available until Exchange 2010 SP1 everyone had accepted it by then and it seems that security teams did not manage to push successfully once it existed.
And it would have forced changes to admin and IDM processes, like creating users or distribution lists in AD first and only afterwards using Exchange to “mail enable” them.
No longer available or working cmdlets:Add-DistributionGroupMember, New-DistributionGroup, New-Mailbox, New-MailContact, New-MailUser, New-RemoteMailbox, Remove-DistributionGroup, Remove-DistributionGroupMember, Remove-Mailbox, Remove-MailContact, Remove-MailUser, Remove-RemoteMailbox, Update-DistributionGroupMember, Add-ADPermission, Remove-ADPermission
Adoption examples:
- New-Mailbox (where Exchange writes to AD) would be:
- New-ADUser (where adm.jdoe writes to AD)
- Enable-Mailbox
- Add-ADPermission for SendAs rights would have to be done via AD users and computers in the security tab and often requiring additional AD permissions for standard admins.
Show me this no-regrets option!
Disclaimer: Please fully read and understand the following links and articles, perform in a test environment first, make sure AD backups are current and recovery practices are established!
Audit current usage
You should first check which of the affected cmdlets are in use on which OUs.$CsvPath ="C:\temp\SplitPermissionAdminAuditLog.csv"
$Cmdlets = "Add-ADPermission","Remove-ADPermission","New-DistributionGroup","Remove-DistributionGroup","Add-DistributionGroupMember","Update-DistributionGroupMember","Remove-DistributionGroupMember","New-Mailbox","Remove-Mailbox","New-RemoteMailbox","Remove-RemoteMailbox","New-MailUser","Remove-MailUser","New-MailContact","Remove-MailContact"
Search-AdminAuditLog -ResultSize 99000 -Cmdlets $Cmdlets| select RunDate,Caller,ObjectModified,CmdletName,@{Name='CmdletParameters';Expression={[string]::join(",", ($_.CmdletParameters))}},succeeded,error | Export-Csv -Path $CsvPath -Delimiter ";" -Encoding Unicode -NoTypeInformation
Quick Analysis of caller and cmdlets:$CSVs=Import-Csv -Path $CsvPath -Delimiter ";"$CSVs|group Caller$CSVs|group CmdletNameAnalyze the CSV for where AD permissions will be needed. Potentially optimize by moving all Exchange relevant groups into dedicated OUs.
Enable split permissions model
Follow instructions of “Switch to Active Directory split permissions” in Configure Exchange Server for split permissions | Microsoft Learn (NOT RBAC split permissions)
In essence it will remove the dangerous permissions of “Exchange Windows Permissions” group and also remove Exchange as group member.Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /PrepareAD /ActiveDirectorySplitPermissions:true
To revert back just use: /ActiveDirectorySplitPermissions:false
Grant AD Permissions
Create a custom AD group and make Exchange server members.
adjust OU Path first!New-ADGroup -Name "AD_Custom Exchange Split permissions replacement" -GroupCategory Security -GroupScope DomainLocal -Path "OU=Rights,OU=Groups,OU=T1,OU=_ADM,$((Get-ADDomain).DistinguishedName)" -Description "replaces the permissions lost by split permissions on relevant OUs"Add-ADGroupMember "AD_Custom Exchange Split permissions replacement" -Members "Exchange Trusted Subsystem"
reboot Exchange servers for permissions via group to work
I’ve created a script to make delegating the AD permissions easy per use case.
INFO: Without these permissions the Exchange server would receive the error
“INSUFF_ACCESS_RIGHTS”from AD.
Download Add-ExchangeADSplitPermissionOnOU.ps1 from glueckkanja GitHub
It can grant the following PermissionTypes:
- CreateUserAndContact
- Create/delete, ResetPassword and WriteAllProperties for Users and Contacts
- Exchange cmdlets: New-Mailbox, New-RemoteMailbox, New-MailUser, New-MailContact and the matching Remove-*
- GroupManage
- Create/Delete Groups, Modify Member
- Exchange cmdlets: New-DistributionGroup, Remove-DistributionGroup, Add-DistributionGroupMember, Update-DistributionGroupMember, Remove-DistributionGroupMember
- Additional usecases: user managing DistributionGroups they own via https://
/EAC
- UserSendAs
- Modfiy AD Permissions on Users
- Exchange cmdlet: Add-ADPermission
- GroupSendAs
- Modfiy AD Permissions on Groups
- Exchange cmdlet: Add-ADPermission
How to use the script:
Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU <OU> -PermissionType <GroupManage|UserSendAs|GroupSendAs|CreateUserAndContact> -Trustee "AD_Custom Exchange Split permissions replacement
e.g.Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU "OU=ExchangeGroups,OU=HQ,OU=Alderaan,$((Get-ADDomain).DistinguishedName)" -PermissionType GroupManage -Trustee "AD_Custom Exchange Split permissions replacement"
Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU "OU=ExchangeGroups,OU=HQ,OU=Alderaan,$((Get-ADDomain).DistinguishedName)" -PermissionType GroupSendAs -Trustee "AD_Custom Exchange Split permissions replacement"
Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU "OU=Users,OU=HQ,OU=Alderaan,$((Get-ADDomain).DistinguishedName)" -PermissionType UserSendAs -Trustee "AD_Custom Exchange Split permissions replacement"
Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU "OU=Users,OU=HQ,OU=Alderaan,$((Get-ADDomain).DistinguishedName)" -PermissionType CreateUserAndContact -Trustee "AD_Custom Exchange Split permissions replacement"
Grant Exchange RBAC
Re-enable -BypassSecurityGroupManagerCheck parameter for Add-DistributionGroupMember and Remove-DistributionGroupMember cmdlets:New-RoleGroup -Name "SplitPermission Security Group Creation and Membership" -Roles "Security Group Creation and Membership" -Members "Organization Management","Recipient Management" -Description "Brings back -BypassSecurityGroupManagerCheck to Add-DistributionGroupMember, but also needs AD ACL for Exchange Server on target DLs"
INFO:
Else you get "-BypassSecurityGroupManagerCheck parameter is not available" or "You don't have sufficient permissions. This operation can only be performed by a manager of the group"
Re-enable New-Mailbox, New-RemoteMailbox, New-MailContact, Remove-... cmdlets with needed parameters:New-RoleGroup -Name "SplitPermission Mail Recipient Creation" -Roles "Mail Recipient Creation" -Members "Organization Management","Recipient Management" -Description "Brings back New-Mailbox, New-RemoteMailbox, New-MailUser, New-MailContact and matching Remove-... cmdlets, but additionally Exchange needs AD ACL for Exchange Server on target OUs"
Conclusions
I hope that with this guidance many more will take this important step to secure their Active Directory from compromise via Exchange. I have not yet run into issues when I implemented Exchange AD split permissions model and the adoption from this article at our customers.
I hope Microsoft will implement a native way to achieve this granular OU based approach, instead of the current all or nothing, for it to become widely adopted.
As AD Tiering is dear to my heart: Additionally, please do not logon to Exchange servers with Domain Admin (or any Tier0) accounts but treat them as Tier1 from now on and implement AD Tiering asap. As a first step, I recommend tools like PingCastle or Purple Knight to assess your AD Security and Control Paths.




















