​​​Exchange AD Split Permissions senza rimpianti​

TLDR: e se eliminassimo gli svantaggi?

Ho trovato un modo per riassegnare i permessi AD e RBAC nei punti in cui risiedono utenti, gruppi, contatti Exchange e così via. In questo modo non serve alcun adattamento per admin o sistemi di identity management, che nella mia esperienza era il vero blocco per la maggior parte delle aziende. E manteniamo comunque il beneficio di security contro lateral movement e compromissione del dominio.

Si ottiene in tre passi:

1. Implementare il modello AD split permission
   
2. Concedere ai server Exchange i permessi AD persi, ma solo sulle OU rilevanti
   
3. Concedere Exchange RBAC per riabilitare i cmdlet PowerShell mancanti
   

Tutto tramite le indicazioni di Microsoft, ACL di AD o assegnazioni RBAC di Exchange.

Perché ci interessa (ora)?

È stato in gran parte trascurato o ignorato da quando è stato introdotto con Exchange 2010 SP1. Ma il modello di shared permissions di default rappresenta un grosso rischio di security per il takeover di Active Directory. Considerato che negli ultimi anni Exchange è diventato noto per gli exploit remoti, è tempo di agire.
Il problema nasce dai privilegi concessi alla root del dominio, che vengono ereditati in tutto il dominio.

• modificare i permessi su utenti e gruppi (di fatto accesso completo)
• modificare i membri dei gruppi
• reimpostare la password degli utenti
• creare/eliminare utenti e gruppi

Solo alcuni utenti e gruppi Tier0 ad alto privilegio sono protetti dal processo AdminSDHolder (attributo admincount=1) e in molti ambienti esistono utenti o gruppi non protetti che potrebbero consentire la compromissione del dominio e/o della foresta, o quantomeno provocare un impatto serio.

Esempi rilevanti:

• Account Entra Connect Sync quando si usa PWHashSync
• Gruppi di default
  • Allowed RODC Password Replication Group insieme all'account EntraConnect (se esiste un vero Windows RODC)
  • Vedi anche Untrustworthy Trust Builders: Account Operators Replicating Trust Attack (AORTA) - SpecterOps, che mostra ulteriori percorsi (il gruppo Account Operators rappresenta una minaccia analoga)
  • Svuotare Protected Users per creare vettori d'attacco rimuovendo le protezioni
• Gruppi custom o account admin/service non protetti
  • Permessi di scrittura sulle GPO (applicate ai domain controller)
  • Gestione dell'accesso a backup di AD, backup server, template PKI, hypervisor, ...

È molto difficile contenere retroattivamente tutti questi percorsi presenti e futuri. Per la OU custom _ADM potresti disabilitare l'ereditarietà delle ACL, ma la maggior parte degli oggetti di default non può essere spostata dalla OU Builtin di default o dal container Users, e resta vulnerabile.
È molto meglio rimuovere i permessi potenti dalla root, cosa che si ottiene implementando il modello Active Directory split permissions. Configure Exchange Server for split permissions | Microsoft Learn
E Microsoft concorda: «…encouraged to implement Active Directory split permissions» Active Directory Hardening Series - Part 7 – Implementing Least Privilege | Microsoft Community Hub

Ma perché nessuno lo fa?

Dato che le split permissions non erano disponibili fino a Exchange 2010 SP1, all'epoca tutti avevano ormai accettato lo status quo, e sembra che i team di security non siano riusciti a farle passare con successo una volta che sono state introdotte.
Inoltre avrebbero imposto modifiche ai processi admin e IDM, come creare utenti o liste di distribuzione prima in AD e solo dopo usare Exchange per il «mail enable».

Cmdlet non più disponibili o funzionanti:
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

Esempi di adattamento:

• New-Mailbox (dove Exchange scrive in AD) diventa:
  • New-ADUser (dove adm.jdoe scrive in AD)
  • Enable-Mailbox
• Add-ADPermission per i diritti SendAs deve essere eseguito tramite Utenti e computer di AD nella scheda security, richiedendo spesso permessi AD aggiuntivi per gli admin standard.

Mostrami questa opzione senza rimpianti

Disclaimer: leggi e comprendi bene i link e gli articoli che seguono, testa prima in un ambiente di prova, assicurati che i backup di AD siano aggiornati e che le procedure di recovery siano consolidate.

Audit dell'utilizzo attuale

Prima di tutto verifica quali dei cmdlet interessati sono in uso e su quali OU.
$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

Analisi rapida di caller e cmdlet:
$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.

Abilitare il modello split permissions

Segui le istruzioni di «Switch to Active Directory split permissions» in Configure Exchange Server for split permissions | Microsoft Learn (NON RBAC split permissions)
In sostanza rimuove i permessi pericolosi del gruppo «Exchange Windows Permissions» ed elimina Exchange come membro del gruppo.
Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /PrepareAD /ActiveDirectorySplitPermissions:true
Per tornare indietro basta usare: /ActiveDirectorySplitPermissions:false

Concedere i permessi AD

Crea un gruppo AD custom e rendi i server Exchange membri.
adatta prima il percorso OU
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"

riavvia i server Exchange affinché i permessi via gruppo diventino effettivi
Ho creato uno script per rendere semplice la delega dei permessi AD in base al caso d'uso.

INFO: Senza questi permessi il server Exchange riceverebbe da AD l'errore «INSUFF_ACCESS_RIGHTS».

Scarica Add-ExchangeADSplitPermissionOnOU.ps1 dal GitHub di glueckkanja
Può concedere i seguenti PermissionTypes:

• CreateUserAndContact
  • Create/delete, ResetPassword e WriteAllProperties per Users e Contacts
  • Cmdlet Exchange: New-Mailbox, New-RemoteMailbox, New-MailUser, New-MailContact e i corrispondenti Remove-*
• GroupManage
  • Create/Delete Groups, Modify Member
  • Cmdlet Exchange: New-DistributionGroup, Remove-DistributionGroup, Add-DistributionGroupMember, Update-DistributionGroupMember, Remove-DistributionGroupMember
  • Casi d'uso aggiuntivi: utenti che gestiscono le DistributionGroups di cui sono owner tramite https:///EAC
• UserSendAs
  • Modifica dei permessi AD su Users
  • Cmdlet Exchange: Add-ADPermission
• GroupSendAs
  • Modifica dei permessi AD su Groups
  • Cmdlet Exchange: Add-ADPermission

Come usare lo script:

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

per esempio
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"

Concedere Exchange RBAC

Riabilita il parametro -BypassSecurityGroupManagerCheck per i cmdlet Add-DistributionGroupMember e 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:
Altrimenti ottieni «-BypassSecurityGroupManagerCheck parameter is not available» oppure «You don't have sufficient permissions. This operation can only be performed by a manager of the group»

Riabilita i cmdlet New-Mailbox, New-RemoteMailbox, New-MailContact, Remove-... con i parametri necessari:
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"

Conclusioni

Spero che con questa guida molti altri facciano questo passo importante per mettere in sicurezza la propria Active Directory dalla compromissione via Exchange. Non ho ancora incontrato problemi nell'implementare il modello Exchange AD split permissions e nell'adottare quanto descritto in questo articolo presso i nostri clienti.

Spero che Microsoft implementi un modo nativo per ottenere questo approccio granulare basato sulle OU, invece dell'attuale logica «tutto o niente», così da favorirne l'adozione su larga scala.

Dato che l'AD Tiering mi sta particolarmente a cuore: inoltre, evita di fare login sui server Exchange con account Domain Admin (o qualsiasi Tier0) e trattali d'ora in poi come Tier1, implementando l'AD Tiering il prima possibile. Come primo passo consiglio strumenti come PingCastle o Purple Knight per valutare la security di AD e i Control Path.