Filtro di sicurezza GPO MS16-072: ripristinare Read e preservare l’ambito

Che cos’è il filtro di sicurezza GPO MS16-072?

La diagnosi del filtro di sicurezza GPO MS16-072 parte da due domande distinte: il computer può recuperare i criteri utente e l’utente che ha effettuato l’accesso è autorizzato ad applicarli? Un criterio destinato a un piccolo gruppo di utenti può smettere di funzionare quando il computer perde l’autorizzazione Read. Ripristinare un’autorizzazione Apply estesa può far funzionare il criterio modificandone però anche i destinatari previsti.

L’articolo di supporto MS16-072 di Microsoft documenta la modifica introdotta il 14 giugno 2016: Windows recupera le GPO utente usando il contesto di sicurezza del computer anziché quello dell’utente. La soluzione è concedere Read ad Authenticated Users, oppure a Domain Computers quando si usa il filtro di sicurezza. Il bollettino MS16-072 collega l’aggiornamento all’articolo 3163622 della Microsoft Knowledge Base; i pacchetti di aggiornamento installabili dipendono dalla versione di Windows. Si tratta di una modifica consolidata dell’elaborazione, non di un problema appena scoperto.

L’obiettivo pratico è ripristinare il recupero preservando i destinatari previsti. La stessa revisione deve distinguere i criteri che devono essere in produzione dalle coppie AD/SYSVOL incomplete, dai criteri disabilitati con collegamenti attivi, dagli oggetti inutilizzati e dalle deleghe discutibili. Questi stati richiedono decisioni diverse; fare in modo che ogni criterio venga applicato non è un obiettivo di correzione utile.

Funzionamento: Read, Apply e ambito dei collegamenti

Le indicazioni attuali per la diagnosi di Microsoft spiegano perché rimuovere Authenticated Users da Security Filtering può compromettere i criteri utente: questa azione rimuove sia Read sia Apply Group Policy. Un gruppo di utenti specifico può mantenere le proprie autorizzazioni mentre l’account computer non riesce più a recuperare la GPO.

Read aggiunto tramite la scheda Delegation di GPMC è diverso dalla voce denominata Read (from Security Filtering). Quest’ultima include Apply; il solo Read ripristina il recupero senza concedere quel diritto di applicazione. Mantenete il gruppo di utenti previsto in Security Filtering e fornite Read alla popolazione di computer appropriata tramite Delegation.

Il filtro di sicurezza opera nelle posizioni raggiunte dai collegamenti della GPO. Il riferimento sul filtro di sicurezza di Microsoft spiega che la sola appartenenza a un gruppo non porta un utente fuori ambito in un sito, dominio o OU collegati. Aggiungere Apply esteso può ampliare i destinatari nell’ambito dei collegamenti applicabili; non applica automaticamente la GPO all’intero dominio. Questa pagina storica spiega i meccanismi del filtro e va letta insieme alle indicazioni attuali su Read per i computer.

La documentazione sull’elaborazione dei criteri di gruppo di Microsoft descrive condizioni aggiuntive: sezioni disabilitate, filtri WMI ed elaborazione loopback. Merge aggiunge l’elenco dei criteri utente basato sul computer dopo l’elenco dell’utente; Replace usa al suo posto l’elenco basato sul computer. Registrate la modalità effettiva prima di interpretare un risultato. Per il loopback Merge, l’articolo di supporto MS16-072 indica espressamente di aggiungere gli utenti e i computer previsti in Scope > Security Filtering. Convalidate separatamente questa configurazione mirata; la correzione generale di Read per i computer descritta sopra non è una procedura completa per il loopback.

Catena del guasto e criteri da esaminare

Una sequenza comune di guasto è semplice: un amministratore restringe una GPO utente a un gruppo aziendale, rimuove Authenticated Users e poi rileva che le impostazioni utente mancano sui computer interessati. Il gruppo destinatario sembra ancora corretto. La dipendenza mancante è Read per i computer. Aggiungere di nuovo Authenticated Users a Security Filtering può nascondere questa dipendenza ripristinando sia Read sia Apply.

Microsoft documenta la mancata applicazione dei criteri utente come sintomo; il suo esempio di diagnosi include un errore nel rapporto dei risultati. Non presumete che questo guasto sia sempre silenzioso e non considerate ogni impostazione mancante una prova di un problema di autorizzazioni MS16-072.

Altri stati delle GPO richiedono una decisione separata prima di collegarle o riattivarle:

• Incoerenza AD/SYSVOL: verificate l’oggetto della directory e i file corrispondenti, la replica e i backup recuperabili. Un riscontro di oggetto orfano non giustifica da solo il ripristino del criterio per l’uso o la sua eliminazione.
• Entrambe le sezioni disabilitate, ma un collegamento abilitato: stabilite se si tratta di manutenzione intenzionale o di un collegamento obsoleto. Il riscontro non significa che le impostazioni disabilitate siano attualmente applicate.
• Nessun collegamento inventariato: identificate una bozza, un criterio di riserva o una distribuzione dimenticata. L’assenza di collegamenti è un segnale di inventario, non una prova di compromissione.
• Delega discutibile su criteri e collegamenti: esaminate i soggetti e gli oggetti pertinenti. Un riscontro di autorizzazione non prova che qualcuno abbia inserito un collegamento ostile.

Per la questione distinta di chi possa riscrivere le impostazioni, le configurazioni errate delle GPO come vettore di attacco spiegano l’esposizione dovuta ai diritti di modifica dei criteri e alla configurazione debole. Per una OU privilegiata, le ACL deboli delle GPO su Tier 0 spiegano perché bloccare l’ereditarietà non protegge le autorizzazioni di modifica proprie della GPO collegata. L’accesso in lettura, l’accesso di modifica dei criteri e l’accesso di scrittura dei collegamenti richiedono ciascuno prove proprie.

Rilevamento: misurare autorizzazioni e risultati effettivi

Partite da una GPO interessata, identificata senza ambiguità. L’esempio 3 del riferimento Get-GPPermission di Microsoft fornisce questo comando:

Get-GPPermission -Name "TestGPO" -All

Sostituite il nome dell’esempio con il criterio reale. Il cmdlet riporta i soggetti che hanno autorizzazioni su quella GPO; non è una simulazione completa dell’elaborazione dei criteri. Se i nomi sono ambigui, usate il GUID della GPO. Le seguenti query individuali adattano parametri documentati:

Get-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "GPO-Users-Cible" -TargetType Group

Usate i nomi risolti del vostro dominio. Confrontate Read per i computer, l’autorizzazione Apply del gruppo previsto e qualsiasi Apply esteso inatteso. Un risultato assente o un errore non è una verifica delle autorizzazioni riuscita. Esaminate le autorizzazioni personalizzate e le voci Deny esplicite anziché dedurre l’accesso effettivo da un livello riepilogativo.

Per il risultato dell’elaborazione, l’esempio di diagnosi di Microsoft usa:

gpresult /h gpresult.html

Eseguite un test utente positivo e uno negativo ed esaminate i rapporti generati. Conservate il computer, l’utente, l’identità della GPO, i collegamenti pertinenti e qualsiasi errore insieme a ogni risultato. La matrice diagnostica seguente aiuta a mantenere visibili le spiegazioni alternative:

Questi sono comandi documentati e una procedura di convalida proposta. Qui non si dichiarano risultati di test AD o acquisizioni dei registri eventi.

Correzione: ripristinare Read senza ampliare Apply (Remediation)

1. Registrare i destinatari previsti e lo stato attuale

Prima di modificare le autorizzazioni, conservate lo stato del criterio e stabilite il proprietario, gli utenti destinatari, i computer di accesso, l’ambito dei collegamenti e la modalità di elaborazione. Determinate quale popolazione di computer richieda Read. Authenticated Users, Domain Computers o un gruppo di computer adatto sono opzioni da valutare rispetto a tale popolazione; verificate Deny esplicito separatamente.

2. Concedere Read ai computer tramite Delegation

In GPMC, aprite la scheda Delegation della GPO interessata, selezionate Add, scegliete il gruppo o l’oggetto computer, selezionate Read e confermate. Mantenete Apply sul gruppo di utenti previsto. La pagina di diagnosi di Microsoft documenta questa procedura e la distinzione risultante fra il solo Read e Read da Security Filtering.

Per un’anteprima PowerShell, questo esempio usa parametri della documentazione Set-GPPermission di Microsoft:

Set-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group -PermissionLevel GpoRead -WhatIf

-WhatIf mostra un’anteprima dell’operazione; non applica la modifica. Usate la GPO e il soggetto reali, esaminate l’anteprima ed eseguite la modifica approvata sul singolo criterio tramite la procedura scelta.

3. Correggere una concessione accidentale di Apply esteso

Se Authenticated Users deve soltanto leggere questa GPO mirata, visualizzate in anteprima la sostituzione del suo livello di autorizzazione attuale:

Set-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group -PermissionLevel GpoRead -Replace -WhatIf

La documentazione afferma che un livello di autorizzazione esistente più alto resta invariato a meno che non si usi -Replace. Pertanto, richiedere semplicemente GpoRead può lasciare in vigore una concessione Apply esistente. La sostituzione è appropriata solo dopo aver confermato che il soggetto debba perdere la propria autorizzazione superiore su questa GPO. Preservate l’autorizzazione Apply del gruppo destinatario e lo stato registrato per il ripristino.

4. Convalidare l’applicazione e risolvere i riscontri di inventario

Ripetete le misurazioni delle autorizzazioni ed entrambi i test utente. Verificate l’applicazione prevista, l’esclusione degli utenti non destinatari e le condizioni di elaborazione pertinenti. Per gli oggetti orfani, convalidate entrambi i componenti di archiviazione prima del ripristino o del ritiro. Per i criteri disabilitati ma collegati, confermate l’intenzione ed eliminate i collegamenti obsoleti quando opportuno; non riattivate automaticamente le impostazioni. Rivedete le concessioni discutibili con il proprietario, compresi i diritti di scrittura dei collegamenti indipendentemente dalle autorizzazioni del contenitore dei criteri.

Come EtcSec rileva questi problemi

Le descrizioni seguenti riflettono sette implementazioni Detect() esaminate in etc-collector al commit c38a5bb9d0d847a56980c8ba02c7b0169abbc69f. Descrivono segnali di configurazione, non sette attacchi dimostrati o un test eseguito su questo ambiente.

Controlli del filtro

GPO_AUTHENTICATED_USERS_APPLY seleziona le GPO con un collegamento abilitato e una voce ACL Authenticated Users che contiene il bit Apply. L’adattatore LDAP associa tale bit al diritto esteso pertinente; Microsoft documenta Apply Group Policy come il diritto usato per determinare l’applicazione. Il Detect() stesso non scarta le voci Deny, non calcola l’accesso effettivo, non valuta WMI e non controlla le sezioni disabilitate. Una configurazione di base intenzionalmente ampia può legittimamente produrre un segnale di revisione.

GPO_NO_SECURITY_FILTERING cerca GPO collegate e abilitate con Apply per Everyone o Authenticated Users e nessun altro soggetto specifico con Apply, escludendo Domain Computers da questo test del soggetto specifico. Un gruppo specifico non annulla una concessione Apply estesa, quindi il rilevatore può non individuare un ampliamento quando entrambi coesistono. Inoltre, non calcola l’accesso effettivo o lo stato delle sezioni. Questi due controlli si sovrappongono e vanno esaminati come un’unica questione di filtro, anziché essere contati come prove indipendenti di esposizione.

Nessuno dei due predicati stabilisce che manchi Read per i computer. Usate le misurazioni delle autorizzazioni e i test di elaborazione precedenti per la diagnosi MS16-072.

Controlli di inventario

GPO_ORPHANED usa i riscontri SYSVOL forniti di tipo orphaned_ldap o orphaned_sysvol. Se non viene restituito alcun riscontro di oggetto orfano corrispondente, il suo meccanismo di ripiego LDAP segnala un percorso di file vuoto o un oggetto con DisplayName e CN entrambi vuoti. Questo meccanismo può attivarsi anche quando sono stati forniti altri riscontri SYSVOL. Un oggetto LDAP completo la cui cartella SYSVOL sia scomparsa può sfuggire a questo ripiego. Registrate se sono state fornite prove SYSVOL; non è un rilevatore di un gPLink che rimanda a una GPO mancante.

GPO_DISABLED_BUT_LINKED richiede Flags = 3, che significa che entrambe le sezioni sono disabilitate, e un collegamento abilitato. Identifica uno stato di inventario da spiegare, non impostazioni disabilitate attualmente applicate.

GPO_UNLINKED trova le GPO senza alcun collegamento inventariato, includendo i collegamenti disabilitati nell’insieme delle GPO collegate, ed esclude i due GUID delle GPO predefinite. Non significa la stessa cosa di un collegamento disabilitato, di sezioni disabilitate o di un oggetto orfano AD/SYSVOL. Esaminate il ciclo di vita e l’intenzione prima di collegare o ritirare l’oggetto.

Controlli di delega

GPO_MODIFY_RIGHTS verifica l’appartenenza diretta o risolta tramite il gruppo primario a Group Policy Creator Owners, identificato dal RID 520. Non segue le appartenenze annidate. Il riferimento sugli identificatori di sicurezza di Microsoft descrive la capacità del gruppo di creare GPO e la proprietà dei nuovi oggetti da parte del creatore. La sola appartenenza non dimostra né diritti di modifica su tutte le GPO esistenti né l’autorizzazione a collegarle. Esaminate i membri e i criteri e le deleghe di cui sono proprietari.

GPO_LINK_POISONING seleziona ACE di concessione il cui DN dell’oggetto contiene CN=Policies,CN=System e la cui maschera include GenericAll, GenericWrite o WriteDACL. Il Detect() stesso non esclude gli amministratori, non esamina l’ACL di ogni GPO, non stabilisce l’accesso in scrittura al gPLink di una OU e non identifica un collegamento ostile esistente. Il suo Count rappresenta oggetti distinti; TotalInstances può includere più ACE. Convalidate il soggetto e la delega, quindi esaminate separatamente le autorizzazioni dei collegamenti del sito, dominio o della OU pertinenti. La documentazione sull’ambito di Microsoft colloca gPLink su questi oggetti e la sua procedura di delega gestisce lì le autorizzazioni Link GPOs.