​​​Exchange AD Split Permissions zonder spijt​

TLDR: wat als we de nadelen wegnemen?

Ik heb een manier gevonden om de AD- en RBAC-rechten opnieuw toe te kennen op de plek waar de Exchange-gebruikers, -groepen, -contacten enzovoort staan. Daarmee hoeven admins en identity management-systemen hun processen niet aan te passen, en juist dat was in mijn ervaring de reden dat de meeste bedrijven het nooit hebben ingevoerd. Tegelijk houden we de veiligheidswinst tegen lateral movement en compromittering van het domein.

Dat gebeurt in drie stappen:

1. Implementeer het AD split permission-model
   
2. Geef de Exchange-servers de verloren AD-rechten terug, maar alleen op de relevante OU’s
   
3. Ken Exchange RBAC toe om de ontbrekende PowerShell-cmdlets weer te activeren
   

Alles via de handleiding van Microsoft, AD ACL’s of Exchange RBAC-toewijzingen.

Waarom is dit (nu) belangrijk?

Het onderwerp is sinds de introductie met Exchange 2010 SP1 grotendeels over het hoofd gezien of genegeerd. Het standaardmodel met gedeelde rechten vormt echter een groot veiligheidsrisico, omdat het een overname van Active Directory mogelijk maakt. In combinatie met de reputatie die Exchange de afgelopen jaren rond remote exploits heeft opgebouwd, is het tijd om te handelen.
Het probleem komt voort uit privileges die op de root van een domein worden toegekend en vervolgens door het hele domein worden overgeërfd.

• rechten op gebruikers en groepen wijzigen (in de praktijk volledige toegang)
• groepslidmaatschappen wijzigen
• wachtwoorden van gebruikers resetten
• gebruikers en groepen aanmaken/verwijderen

Alleen bepaalde hoog geprivilegieerde Tier0-gebruikers en -groepen worden beschermd door het AdminSDHolder-proces (attribuut admincount=1), en in veel omgevingen bestaan er onbeschermde gebruikers of groepen waarmee het domein en/of het forest gecompromitteerd kan worden of die op zijn minst grote schade kunnen aanrichten.

Bekende voorbeelden:

• Entra Connect Sync-account bij gebruik van PWHashSync
• Standaardgroepen
  • Allowed RODC Password Replication Group samen met het EntraConnect-account (als er een echte Windows RODC bestaat)
  • Zie ook Untrustworthy Trust Builders: Account Operators Replicating Trust Attack (AORTA) - SpecterOps, waarin meer paden worden beschreven (de groep Account Operators vormt een vergelijkbare dreiging)
  • Protected Users leegmaken om aanvalsvectoren te creëren door beschermingen weg te halen
• Onbeschermde eigen groepen of admin-/serviceaccounts
  • Schrijfrechten op GPO’s (die op domeincontrollers worden toegepast)
  • Beheer van toegang tot AD-backups, backupserver, PKI-templates, hypervisor, ...

Het is heel moeilijk om al deze bestaande en toekomstige mogelijke paden achteraf in te dammen. Voor de eigen OU _ADM kun je ACL-overerving uitschakelen, maar de meeste standaardobjecten mogen niet uit de standaard-OU Builtin of de container Users worden verplaatst en blijven dus kwetsbaar.
Het is veel beter om de vergaande rechten op de root weg te halen, en dat doe je door het Active Directory split permissions-model te implementeren. Configure Exchange Server for split permissions | Microsoft Learn
En Microsoft is het daarmee eens: “…encouraged to implement Active Directory split permissions” Active Directory Hardening Series - Part 7 – Implementing Least Privilege | Microsoft Community Hub

Maar waarom doet niemand het?

Omdat split permissions tot Exchange 2010 SP1 simpelweg niet bestonden, had iedereen zich tegen die tijd bij de situatie neergelegd, en het lijkt erop dat securityteams het er niet doorheen kregen toen de mogelijkheid er eindelijk was.
Bovendien zou het aanpassingen aan admin- en IDM-processen hebben geforceerd, zoals gebruikers of distributielijsten eerst in AD aanmaken en ze pas daarna via Exchange “mail enablen”.

Cmdlets die niet langer beschikbaar zijn of niet meer werken:
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

Voorbeelden van procesaanpassingen:

• New-Mailbox (waarbij Exchange naar AD schrijft) zou worden:
  • New-ADUser (waarbij adm.jdoe naar AD schrijft)
  • Enable-Mailbox
• Add-ADPermission voor SendAs-rechten zou via Active Directory Users and Computers op het tabblad Security moeten gebeuren, waarvoor gewone admins vaak extra AD-rechten nodig hebben.

Laat me die no-regrets-optie zien

Disclaimer: Lees en begrijp de onderstaande links en artikelen volledig, test eerst in een testomgeving en zorg ervoor dat AD-backups actueel zijn en dat er recovery-procedures zijn vastgelegd.

Breng het huidige gebruik in kaart

Controleer eerst welke van de betrokken cmdlets op welke OU’s in gebruik zijn.
$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

Snelle analyse van caller en 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.

Split permissions-model activeren

Volg de instructies onder “Switch to Active Directory split permissions” in Configure Exchange Server for split permissions | Microsoft Learn (NIET RBAC split permissions)
Kort gezegd verwijdert het de gevaarlijke rechten van de groep “Exchange Windows Permissions” en haalt het Exchange als groepslid weg.
Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /PrepareAD /ActiveDirectorySplitPermissions:true
Om terug te draaien gebruik je simpelweg: /ActiveDirectorySplitPermissions:false

AD-rechten toekennen

Maak een eigen AD-groep aan en voeg de Exchange-servers daaraan toe.
pas eerst het OU-pad aan.
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"

start de Exchange-servers opnieuw op, zodat de rechten via de groep werken
Ik heb een script gemaakt waarmee je de AD-rechten per use case eenvoudig kunt delegeren.

INFO: Zonder deze rechten krijgt de Exchange-server de fout “INSUFF_ACCESS_RIGHTS” van AD.

Download Add-ExchangeADSplitPermissionOnOU.ps1 van de glueckkanja GitHub
Het kan de volgende PermissionTypes toekennen:

• CreateUserAndContact
  • Create/delete, ResetPassword en WriteAllProperties voor Users en Contacts
  • Exchange-cmdlets: New-Mailbox, New-RemoteMailbox, New-MailUser, New-MailContact en de bijbehorende Remove-*
• GroupManage
  • Create/Delete Groups, Modify Member
  • Exchange-cmdlets: New-DistributionGroup, Remove-DistributionGroup, Add-DistributionGroupMember, Update-DistributionGroupMember, Remove-DistributionGroupMember
  • Aanvullende use cases: gebruikers die de DistributionGroups beheren waarvan ze eigenaar zijn, via https:///EAC
• UserSendAs
  • Modfiy AD Permissions on Users
  • Exchange-cmdlet: Add-ADPermission
• GroupSendAs
  • Modfiy AD Permissions on Groups
  • Exchange-cmdlet: Add-ADPermission

Zo gebruik je het script:

Add-ExchangeADSplitPermissionOnOU.ps1 -TargetOU <OU> -PermissionType <GroupManage|UserSendAs|GroupSendAs|CreateUserAndContact> -Trustee "AD_Custom Exchange Split permissions replacement

bijv.
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"

Exchange RBAC toekennen

Activeer de parameter -BypassSecurityGroupManagerCheck opnieuw voor de cmdlets Add-DistributionGroupMember en Remove-DistributionGroupMember:
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:
Anders krijg je "-BypassSecurityGroupManagerCheck parameter is not available" of "You don't have sufficient permissions. This operation can only be performed by a manager of the group"

Activeer de cmdlets New-Mailbox, New-RemoteMailbox, New-MailContact, Remove-... met de benodigde parameters opnieuw:
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"

Conclusie

Ik hoop dat met deze handleiding veel meer mensen deze belangrijke stap zetten en hun Active Directory beveiligen tegen compromittering via Exchange. Ik ben tot nu toe geen problemen tegengekomen bij het implementeren van het Exchange AD split permissions-model en van de aanpassingen uit dit artikel bij onze klanten.

Ik hoop dat Microsoft een ingebouwde manier gaat leveren voor deze granulaire, OU-gebaseerde aanpak in plaats van het huidige alles of niets, zodat die breed wordt overgenomen.

Omdat AD Tiering me erg aan het hart gaat: log daarnaast niet in op Exchange-servers met Domain Admin-accounts (of andere Tier0-accounts), maar behandel ze vanaf nu als Tier1 en implementeer AD Tiering zo snel mogelijk. Als eerste stap raad ik tools als PingCastle of Purple Knight aan om je AD-security en control paths te beoordelen.