nlnl
DeutschDuitsDEEnglishEngelsENEspañolSpaansESSvenskaZweedsSVSuomiFinsFIDanskDeensDA한국어KoreaansKONederlandsNederlandsNLItalianoItaliaansITÍslenskaIJslandsISNorskNoorsNO日本語JapansJA

Geschreven in het Duits, vertaald door Claude. Is er iets verloren gegaan in de vertaling? Laat het ons weten.

Exchange AD Split Permissions zonder spijt

Zelfs organisaties die hun mailboxen volledig naar de cloud hebben verhuisd, laten vaak nog Exchange-servers on-premises draaien, en daarmee blijft een onderschat security-risico voor Active Directory bestaan. Het model “AD Split Permissions” ontneemt Exchange de brede AD-privileges die aanvallers kunnen misbruiken voor een volledige domeincompromittering. Tot nu toe strandde de invoering vooral op de procesaanpassingen die het beheerders oplegt. Dit artikel laat zien hoe je precies die hindernis elegant wegneemt: een script dat de verloren AD-permissies gericht en alleen op de relevante OU's opnieuw toekent, zodat de vertrouwde beheerworkflow blijft bestaan en je het volledige security-voordeel toch binnenhaalt.

Exchange AD Split Permissions zonder spijt

TLDR: wat als we de nadelen wegnemen?

Ik heb een manier gevonden om AD- en RBAC-permissies precies daar opnieuw toe te kennen waar de Exchange-gebruikers, -groepen en -contacten staan, zonder dat admins of identity management-systemen hun werkwijze hoeven aan te passen. Die frictie is in mijn ervaring voor de meeste bedrijven de belangrijkste blokkade geweest. En we houden de security-voordelen tegen lateral movement en domeincompromittering onverminderd overeind.

Active Directory

Het gaat in drie stappen:

  1. Implementeer het AD split permission model
  2. Ken de Exchange-servers de verloren AD-permissies weer toe, maar alleen op de relevante OU's
  3. Ken Exchange RBAC toe om de ontbrekende PowerShell-cmdlets weer beschikbaar te maken

Allemaal via de documentatie van Microsoft, AD-ACL's of Exchange RBAC-assignments.

Een spreker zit voor een laptop en legt een slide uit met de titel Step 1: Active Directory Permissions van glueckkanja. De slide laat zien hoe je Microsoft Exchange AD Split Permissions implementeert, met PowerShell-commando's voor het aanmaken van een delegatiegroep (New-ADGroup, Add-ADGroupMember) en het toekennen van permissies via het script Add-ExchangeADSplitPermissionOnOU.ps1.
Webcast: Exchange AD Split Permissions without regrets. Een stap-voor-stap implementatiegids

Waarom is dit (nu) belangrijk?

Sinds de introductie met Exchange 2010 SP1 is het grotendeels over het hoofd gezien of genegeerd. Het standaard shared permissions-model vormt echter een groot security-risico, omdat het een overname van Active Directory mogelijk maakt. Gecombineerd met de reputatie die Exchange de afgelopen jaren heeft opgebouwd op het gebied van remote exploits, is het tijd om te handelen.

Het probleem komt voort uit privileges die op de root van een domein worden toegekend en die vervolgens door het hele domein worden geërfd.

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

Permissies

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

Bekende voorbeelden:

  • Entra Connect Sync-account bij gebruik van Password Hash Sync
  • Standaardgroepen
  • Onbeschermde eigen groepen of admin- en serviceaccounts
    • Schrijfrechten op GPO's (die op domeincontrollers van toepassing zijn)
    • Beheer van toegang tot AD-backups, backupserver, PKI-templates, hypervisor, ...

Het is heel lastig om al deze bestaande en toekomstige paden achteraf dicht te zetten. Voor de eigen OU _ADM kun je ACL-overerving uitschakelen, maar de meeste standaardobjecten mogen niet uit de standaard Builtin-OU of de Users-container worden verplaatst en blijven dus kwetsbaar.

Veel beter is het om de verstrekkende permissies op de root te verwijderen, 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 pas met Exchange 2010 SP1 beschikbaar kwamen, had inmiddels iedereen de situatie geaccepteerd, en het lijkt erop dat security-teams het model daarna niet succesvol hebben kunnen doorvoeren.

Daarnaast zou het aanpassingen in admin- en IDM-processen hebben afgedwongen, zoals gebruikers of distributielijsten eerst in AD aanmaken en ze pas daarna via Exchange “mail enabled” maken.

Info: De volgende cmdlets zijn daarna niet meer beschikbaar of werken niet meer: 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) wordt:
    • 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, wat voor standaardadmins vaak extra AD-permissies vereist.

Laat die no-regrets-optie zien

Disclaimer: Lees de volgende links en artikelen volledig door en zorg dat je ze begrijpt, voer het eerst uit in een testomgeving en controleer of je AD-backups actueel zijn en je recovery-procedures op orde zijn.

Huidig gebruik auditen

Controleer eerst welke van de betrokken cmdlets op welke OU's worden gebruikt:

$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-Object 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-Object Caller
$CSVs | Group-Object CmdletName

Analyseer de CSV om te bepalen waar AD-permissies nodig zijn. Eventueel kun je optimaliseren door alle Exchange-relevante groepen naar aparte OU's te verplaatsen.

Split permissions-model activeren

Volg de instructie van Microsoft "Switch to Active Directory split permissions" in Configure Exchange Server for split permissions | Microsoft Learn(NIET RBAC split permissions)

In feite verwijdert dit de gevaarlijke permissies van de groep "Exchange Windows Permissions" en haalt het Exchange ook als groepslid weg.

Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /PrepareAD /ActiveDirectorySplitPermissions:true
Info: Om het terug te draaien gebruik je simpelweg /ActiveDirectorySplitPermissions:false

AD-permissies toekennen

Maak een eigen AD-groep aan en maak de Exchange-servers daar lid van.

# 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

Ik heb een script gemaakt waarmee je de AD-permissies per use case eenvoudig kunt delegeren.

Zonder deze permissies krijgt de Exchange-server de foutmelding “INSUFF_ACCESS_RIGHTS” van AD.

Download Add-ExchangeADSplitPermissionOnOU.ps1 van de glueckkanja GitHub

Het script kan de volgende PermissionTypes toekennen:

CreateUserAndContact
Aanmaken en verwijderen, ResetPassword en WriteAllProperties voor Users en Contacts
Exchange-cmdlets: `New-Mailbox`, `New-RemoteMailbox`, `New-MailUser`, `New-MailContact` en de bijbehorende `Remove-*`

GroupManage
Groepen aanmaken en verwijderen, lidmaatschappen wijzigen
Exchange-cmdlets: `New-DistributionGroup`, `Remove-DistributionGroup`, `Add-DistributionGroupMember`, `Update-DistributionGroupMember`, `Remove-DistributionGroupMember`
Daarnaast: gebruikers die via de EAC de DistributionGroups beheren waarvan ze eigenaar zijn

UserSendAs
AD-permissies op Users wijzigen
Exchange-cmdlet: `Add-ADPermission`

GroupSendAs
AD-permissies op Groups wijzigen
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" # For example
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

Maak de parameter -BypassSecurityGroupManagerCheck weer beschikbaar 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"


Maak de cmdlets New-Mailbox, New-RemoteMailbox, New-MailContact en Remove-... met de benodigde parameters weer beschikbaar:

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 deze handleiding meer organisaties helpt om de belangrijke stap te zetten en hun Active Directory te beschermen tegen compromittering via Exchange. Bij de implementatie van het Exchange AD Split Permissions-model bij meerdere klanten ben ik geen problemen tegengekomen en verliep de overgang soepel.

Ik hoop ook dat Microsoft een native, OU-gebaseerde aanpak introduceert om deze granulariteit te bereiken in plaats van het huidige alles-of-niets-model, want dat zou brede adoptie aanzienlijk eenvoudiger maken.

Nog een opmerking over AD Tiering: meld je niet aan op Exchange-servers met Domain Admin of andere Tier 0-accounts. Behandel Exchange-servers als Tier 1 en implementeer AD Tiering zo snel mogelijk. Als eerste stap raad ik aan om met PingCastle of Purple Knight je AD security posture te beoordelen en control path-blootstellingen in kaart te brengen.

Vergelijkbare berichten