Exchange AD Split Permissions senza rimpianti

TLDR: e se eliminassimo gli svantaggi?

Ho trovato un modo per riassegnare i permessi AD e RBAC direttamente dove risiedono utenti, gruppi e contatti di Exchange, senza richiedere modifiche agli amministratori o ai sistemi di identity management. Nella mia esperienza, proprio questo attrito è stato l'ostacolo principale per la maggior parte delle aziende. E manteniamo comunque i benefici di sicurezza contro lateral movement e compromissione del dominio.

Si ottiene in tre passaggi:

1. Implementa il modello AD split permission
2. Concedi agli Exchange server i permessi AD perduti, ma solo sulle OU pertinenti
3. Concedi Exchange RBAC per riabilitare i cmdlet PowerShell mancanti

Tutto attraverso la guida di Microsoft, tramite AD ACL o assegnazioni Exchange RBAC.

Perché ci interessa (ora)?

Dalla sua introduzione con Exchange 2010 SP1, il tema è stato in gran parte trascurato o ignorato. Ma il modello di permessi condivisi predefinito rappresenta un rischio significativo di takeover di Active Directory. Considerando che negli ultimi anni Exchange è diventato tristemente noto per le remote exploits, è arrivato il momento di agire.

Il problema nasce dai privilegi concessi alla radice del dominio, che vengono poi ereditati in tutto il dominio.

• modifica dei permessi su utenti e gruppi (di fatto accesso completo)
• modifica dei membri di gruppo
• reset delle password degli utenti
• creazione ed eliminazione di utenti e gruppi

Solo alcuni utenti e gruppi Tier 0 altamente privilegiati 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 o della foresta, oppure causare comunque un impatto rilevante.

Esempi rilevanti:

• Account Entra Connect Sync quando si usa Password Hash Sync
• Gruppi predefiniti
  • Allowed RODC Password Replication Group insieme all'account Entra Connect (se esiste un vero RODC Windows)
  • 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 di attacco rimuovendo le protezioni
• Gruppi personalizzati non protetti o account admin/service
  • Permesso di scrittura sulle GPO (applicate al domain controller)
  • Gestione dell'accesso ai backup AD, al backup server, ai template PKI, all'hypervisor, ...

È molto difficile contenere retroattivamente tutti questi percorsi di attacco attuali e futuri. Per la OU personalizzata _ADM potresti disabilitare l'ereditarietà delle ACL, ma la maggior parte degli oggetti predefiniti non può essere spostata dalla OU Builtin o dal container Users e rimane quindi vulnerabile.

Molto meglio rimuovere i permessi potenti dalla radice, come si ottiene implementando il modello Active Directory split permissions. Configure Exchange Server for split permissions | Microsoft Learn

Anche Microsoft è d'accordo: «…encouraged to implement Active Directory split permissions» Active Directory Hardening Series - Part 7 – Implementing Least Privilege | Microsoft Community Hub

Ma perché nessuno lo fa?

Poiché le split permissions non erano disponibili prima di Exchange 2010 SP1, a quel punto tutti si erano ormai adattati al modello esistente e sembra che i team di security non siano riusciti a imporre la novità una volta che è arrivata.

Avrebbe inoltre imposto modifiche ai processi di amministrazione e IDM, come creare utenti o distribution list prima in AD e solo dopo usare Exchange per il «mail enable».

Info: i seguenti cmdlet non saranno 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) diventerebbe:
  • New-ADUser (dove adm.jdoe scrive in AD)
  • Enable-Mailbox
• Add-ADPermission per i diritti SendAs dovrebbe essere eseguito tramite «Utenti e computer di Active Directory» nella scheda security, richiedendo spesso permessi AD aggiuntivi per gli admin standard.

Mostrami questa opzione senza rimpianti

Disclaimer: leggi e comprendi a fondo i link e gli articoli seguenti, esegui prima tutto in un ambiente di test, assicurati che i backup AD siano aggiornati e che le procedure di recovery siano consolidate.

Audit dell'utilizzo attuale

Verifica innanzitutto quali dei cmdlet interessati sono in uso e su quali OU:

Analisi rapida di caller e cmdlet:

Analizza il CSV per capire dove serviranno i permessi AD. Se possibile, ottimizza spostando tutti i gruppi Exchange rilevanti in OU dedicate.

Abilitare il modello Split Permissions

Segui le istruzioni di Microsoft «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 dal gruppo «Exchange Windows Permissions» e toglie inoltre Exchange come membro di quel gruppo.

Concedere i permessi AD

Crea un gruppo AD personalizzato e rendi gli Exchange server membri di quel gruppo.

Ho scritto uno script per rendere semplice la delega dei permessi AD per singolo caso d'uso.

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

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`
Inoltre: gestione da parte dell'utente delle DistributionGroups di cui è proprietario tramite EAC

UserSendAs
Modifica dei permessi AD sugli Users
Cmdlet Exchange: `Add-ADPermission`

GroupSendAs
Modifica dei permessi AD sui Groups
Cmdlet Exchange: `Add-ADPermission`

Come usare lo script:

Concedere Exchange RBAC

Riabilitare il parametro -BypassSecurityGroupManagerCheck per i cmdlet Add-DistributionGroupMember e Remove-DistributionGroupMember:

Info: in caso contrario ottieni «-BypassSecurityGroupManagerCheck parameter is not available» o «You don't have sufficient permissions. This operation can only be performed by a manager of the group»

Riabilitare New-Mailbox, New-RemoteMailbox, New-MailContact, Remove-... con i parametri necessari:

Conclusioni

Spero che questa guida aiuti più organizzazioni a compiere il passo importante di proteggere il proprio Active Directory dalla compromissione via Exchange. Nella mia esperienza di implementazione del modello Exchange AD Split Permissions presso diversi clienti, non ho incontrato problemi e l'adozione è stata fluida.

Spero inoltre che Microsoft introduca un approccio nativo, basato sulle OU, per ottenere questo livello di granularità al posto dell'attuale modello «tutto o niente», il che renderebbe l'adozione su larga scala molto più semplice.

Una nota sull'AD Tiering: non effettuare il logon agli Exchange server con Domain Admin o con qualsiasi altro account Tier 0. Tratta gli Exchange server come Tier 1 e implementa l'AD Tiering il prima possibile. Come primo passo, consiglio di usare PingCastle o Purple Knight per valutare la postura di sicurezza del tuo AD e identificare le esposizioni sui control path.