• Guide, Sicurezza, Sistemi Operativi
• 15 Dicembre 2020

Nell’articolo Funzionamento delle Group Policy in Windows Server Nicola Ferrini ha affrontato in modo approfondito le tematiche di gestione ed uso delle GPO. In questo articolo affronteremo alcuni altri aspetti relativi all’uso ed alla gestione delle GPO, soffermandoci sulle modalità di applicazione di queste ultime in relazione ai filtri di sicurezza ed ai filtri WMI.

Se nella definizione delle Group Policy Preference abbiamo a disposizione la funzione di Item Level Targeting per determinare con precisione dove applicare le impostazioni della GPO, in una Group Policy “tradizionale” questo strumento non è presente e dovremo impiegare altre modalità di selezione o filtraggio per quanto riguarda l’applicazione o meno di una determinata GPO.

A questo proposito abbiamo a disposizione due strumenti

• Il tab Security Filtering
• I filtri WMI

Con il primo è possibile applicare una Group Policy ad un preciso gruppo di sicurezza, o ad un singolo utente agendo direttamente sugli oggetti che potranno “leggere” la GPO, mentre con il WMI Filtering è possibile interagire direttamente con il moto WMI in modo da applicare una Group Policy in presenza di una ben determinata condizione, ad esempio dell’appartenenza ad una subnet di rete.

Uso del Security Filtering

Di default una GPO creata ex novo o built-in si presenta in questo modo

Figura 1 Impostazioni di sicurezza GPO

La Security è impostata in modo che la GPO sia applicata a tutti gli Authenticated Users e, per impostazione predefinita, a questa Special Identity appartengono tutti gli account in relazione di trust con il dominio (sia gli Utenti che i Computer). Per informazioni ulteriori potete consultare la pagina https://www.devadmin.it/2017/01/18/everyone-vs-authenticated-users-vs-domain-users/

E quindi ne consegue che qualunque oggetto per cui sia applicabile la GPO, Utente, Computer (o entrambi) è in grado di “leggerla” ed applicarla.

È da tenere presente che dal Security Update di giugno 2016, ogni Group Policy, anche quelle riferite esclusivamente ad impostazioni utente DEVONO poter essere lette dal PC sul quale vengono applicate. Infatti, rimuovendo il gruppo Authenticated Users (impostato di default) veniamo avvisati con questo messaggio relativo alla KB3163622

Figura 2 Avviso KB3163622

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the computer’s security context.

Se volessimo che una GPO fosse applicata esclusivamente agli utenti appartenenti al gruppo Vendite, presente nel nostro dominio, dovremo impostare la Security in questo modo:

Figura 3 definizione della Security per il Gruppo di Utenti “vendite”

Questa possibilità offerta dal Security Filtering permette di raggiungere una granularità molto precisa sull’applicazione delle Group Policy andando a definire con precisione quali entità del dominio devono ricevere le impostazioni.

Tuttavia con questa modalità non è possibile definire quali GPO saranno applicate al di fuori dell’appartenenza o meno a determinati gruppi di Active Directory.

Uso del WMI Filtering

Se dobbiamo applicare una GPO esclusivamente se la postazione ha un determinato indirizzo IP o appartiene ad una determinata sottorete oppure ad una ben precisa versione di Windows, con i Filtri di Sicurezza non possiamo farlo. In questo caso è necessario ricorrere al Filtro WMI. L’applicazione della Group Policy avviene esclusivamente se la query WMI ritorna un valore positivo.

Che cosa è WMI (pillole)

Windows Management Instrumentation (WMI) è un Framework o meglio una infrastruttura per la standardizzazione della gestione di dati ed informazioni su un dispositivo, è indipendente dal dispositivo stesso ed è presente già Windows 2000 in modo integrato nel Sistema Operativo.

WMI è l’implementazione in casa Microsoft del Web-Based Enterprise Management (WBEM), che è gestito dal Distributed Management Task Force (DMTF). WBEM definisce gli standard in modo che la gestione di ogni componente possa avvenire con caratteristiche di interoperabilità. A puro titolo di informazione la stessa struttura di gestione può essere presente anche in Linux.

Come si utilizza WMI

Possiamo semplificare molto il concetto immaginando WMI come un Database su cui eseguire delle query, che riguardano le componenti del sistema. Le varie query sono contenute all’interno dell’ambiente di gestione delle GPO.

Dalla Group Policy Management Console dovremo utilizzare il container WMI Filters e successivamente New…

Figura 4 Creazione di un filtro WMI

Successivamente dovremo definire il nome ed una eventuale descrizione e proseguire con Add

Figura 5 Definizione del nome del filtro WMI

Nel campo successivo definire la query verso WMI; in questo esempio vogliamo identificare i sistemi operativi di architettura a 32 bit, indipendentemente dalla versione, per cui la query da impostare sarà select * from Win32_Processor where AddressWidth=”32″

Figura 6 Compilazione della Query WMI nel filtro

Procedendo con OK e poi Save abbiamo definito genericamente il filtro che sarà poi utilizzato nella Group Policy da applicare esclusivamente a questi sistemi operativi con architettura a 32 Bit. Riaprendo poi la GPO creata in precedenza potremo scegliere il Filtro WMI da applicare:

Figura 7 Applicazione del filtro WMI alla GPO

Le impostazioni della GPO “Impostazione-PC-32Bit” definite in Figura 7 verranno applicate esclusivamente a sistemi con architettura a 32 Bit.

La definizione di un filtro WMI può essere anche molto complessa a seconda della granularità richiesta dall’applicazione del filtro stesso, l’esecuzione di un test direttamente applicando il filtro stesso alla GPO può essere molto dispendiosa in termini di tempo ed introdurre margini di errore.

È più pratico eseguire un test del filtro, al di fuori della Group Policy, per valutarne eventuali errori ed applicarlo solamente quando sarete certi della correttezza sintattica. A questo scopo possiamo interagire direttamente con il “motore” WMI tramite PowerShell oppure con il tool wbemtest.exe (presente in tutti i Sistemi Operativi)

Per eseguire una Query WMI con PowerShell è necessario richiamare il cmdlet Get-WmiObject specificando poi la query da eseguire nell’ambiente WMI. Ad esempio, la verifica preventiva per il filtro di figura 7 sarà:

Get-WmiObject -Query “select * from Win32_Processor where AddressWidth=’32′”

Figura 8 Validazione della query WMI

In questo caso la select è stata eseguita su un’architettura a 32 Bit, quindi è stato ottenuto un valore di confronto e la query applicata al filtro sappiamo che è sintatticamente corretta e potrà essere eseguita correttamente

Qui di seguito potete trovare alcune query già strutturate per filtrare differenti Sistemi Operativi

Windows 10
select * from Win32_OperatingSystem WHERE Version like “10.%” AND ProductType=”1″

Windows 8.1
select * from Win32_OperatingSystem WHERE Version like “6.3%” AND ProductType=”1″

Windows Server 2012 R2 – 64-bit – DC
select * from Win32_OperatingSystem WHERE Version like “6.3%” AND ProductType=”2″

Windows Server 2012 R2 – 64-bit – non-DC
select * from Win32_OperatingSystem WHERE Version like “6.3%” AND ProductType=”3″

Come possiamo notare le query differiscono per la diversa ricerca del valore nelle classi Win32_OperatingSystem e ProductType che ci permettono di rilevare i diversi sistemi operativi, troviamo riportato nelle tabelle qui sotto il valore proprio di ognuna delle due classi.

Win32_OperatingSystem

• 5.1 – Windows XP
• 5.2 – Windows Server 2003
• 5.2.3 – Windows Server 2003 R2
• 6.0 – Windows Vista & Windows Server 2008
• 6.1 – Windows 7 & Windows Server 2008 R2
• 6.2 – Windows 8 & Windows Server 2012
• 6.3 – Windows 8.1 & Windows Server 2012 R2
• 10.0 – Windows 10 & Windows Server 2016 & 2019

ProductType

• ProductType 1 – Sistema Operativo Desktop (Client)
• ProductType 2 – Sistema Operativo Server Domain Controller
• ProductType 3 – Sistema Operativo Server Non Domain Controller

 

Applicare una Group Policy se il sistema è in una specifica sottorete

Potrebbe essere utile rilevare la rete (IP) a cui appartiene una determinata postazione in modo da applicare Group Policy specifiche; questo tipo di rilevazione si può fare a partire dalla Route di Default.

Se la Group Policy è da applicare alle postazioni configurate sulla Subnet con IP 192.168.200.0/24 che ha il Default Gateway all’indirizzo 192.168.200.1, sarà sufficiente rilevare la presenza di quest’ultimo per stabilire che la postazione si trova nella sottorete dove vogliamo che venga applicata la GPO:

select * from Win32_IP4RouteTable Where NextHop=’192.168.200.1′

Figura 9 rilevazione del default gateway tramite WMI filter

Applicare una Specifica Group Policy ogni domenica

La classe WMI Win32_LocalTime ha la proprietà DayOfWeek che contiene valori numerici da 0 a 6, dove 0 è la domenica, per cui la nostra query WMI sarà:

select DayOfWeek from Win32_LocalTime where DayOfWeek = 0

Questi sono solo alcuni esempi di quello che è possibile fare con i filtri WMI. Vi rimando alla lettura della pagina ufficiale https://docs.microsoft.com/it-it/windows/security/threat-protection/windows-firewall/create-wmi-filters-for-the-gpo per maggiori informazioni.

 

Gestione dei backup e restore delle Group Policy

Benché le GPO siano parte del System State backup, la procedura di restore in questo caso è laboriosa e lunga. Il modo più rapido per gestire il salvataggio delle GPO è di utilizzare la GPMC dalla quale possiamo effettuare backup e restore selettivi o completi degli oggetti Group Policy.

All’interno della console dobbiamo posizionarci sul ramo Group Policy Objects e premere il tasto desto del mouse sulla selezione dove è presente il menù di gestione.

Figura 10 Gestione backup GPO

Selezionando Back Up All possiamo scegliere la posizione in cui eseguire il salvataggio completo.

Figura 11 Backup GPO

Tramite la funzione di Manage Backup possiamo invece visualizzare e gestire il restore di ogni singola GPO nei vari salvataggi eseguiti, è anche possibile verificare le impostazioni presenti prima del restore

Figura 12 Gestione backup e restore

Naturalmente le funzioni di backup possono essere svolte tramite PowerShell per mezzo del Cmd-Let Backup-Gpo, ad esempio se volessimo salvare tutte le nostre Group Policy in un percorso di rete in modo automatizzato, dovremmo utilizzare questo comando:

Eseguendo poi il restore come visto in Figura 11 non dovremo preoccuparci di gestire una sorta di Versione di Backup in quanto la console GPMC è in grado di rilevare tutte le sessioni di salvataggio e di visualizzarle per il restore.

Figura 13 Archivio di backup delle GPO

Anche per il restore abbiamo a disposizione un Cmd-Let che in questo caso è Restore-GPO, quindi se volessimo rispristinare tutte le Group Policy del backup più recente, dovremmo utilizzare questo comando:

Oppure se volessimo ripristinare una Group policy specifica ad esempio “Impostazione-PC-32Bit” utilizzeremo:

Nota Importante:

Il restore di una Group Policy NON RIPRISTINA anche le posizioni nell’albero AD in cui questa era collegata.

Il restore di una Group Policy RIPRISTINA i Security Filters ed i Filtri WMI collegati alla GPO stessa.

Salvataggio della Struttura delle GPO

Finora abbiamo visto come eseguire il salvataggio ed il ripristino degli oggetti Group Policy all’interno del nostro dominio, abbiamo anche visto alcuni limiti che gli oggetti base hanno, non ultimo il fatto di perdere completamente il riferimento alla collocazione nell’albero AD delle varie GPO, a questo punto ci può venire incontro un altro cmdlet che è Get-GPOReport
tramite il quale possiamo esportare in formato Html o XML l’intera configurazione del nostro sistema di Group Policy:

 

Figura 14 Report completo sulle impostazioni delle GPO in Dominio

Il cmdlet visto sopra può chiaramente essere utilizzato per riportare le impostazioni di una singola GPO

 

Precisazioni Ulteriori

Gli oggetti Group Policy sono a tutti gli effetti oggetti di AD, quindi la loro eliminazione (se il cestino di Active Directory è attivo) non è una eliminazione vera e propria, ma un flag di “delete” abilitato per l’oggetto eliminato. Il cmdlet Restore-Gpo non esegue il restore di oggetti che sono stati cancellati; praticamente esegue il recupero di oggetti che sono stati sovrascritti o erroneamente modificati, ma che sono ancora presenti in AD.

Per effettuare il restore di un oggetto “cancellato” è necessario usare la console GPMC, in quanto un semplice “restore” anche dal cestino di AD non recupera la struttura della GPO che può includere diversi altri oggetti quali script eccetera che risiedono nella Cartella Sysvol.

Se volessimo ripristinare una Group Policy erroneamente cancellata dal ramo “Group Policy Objects” senza utilizzare le funzioni disponibili in GPMC dovremo quindi per prima cosa recuperarla dal cestino di AD (inviduandola tramite la GUI) e successivamente ripristinarla tramite il cmdlet Powershell Restore-GPO, a questo punto anche utilizzando il nome della GPO stessa.

All’interno del backup così come abbiamo visto sopra, ogni GPO è archiviata con un proprio (del backup) ID, che nulla ha a che vedere con il GUID della GPO, all’interno di questa cartella possiamo trovare un file Gpreport.xml che riporta tutte le informazioni della Group Policy salvata, comprese le informazioni del link alle OU in Active Directory.

La sezione del file è <LinksTo>

 

Considerazioni

Le possibilità offerte dalle Group Policy sono enormi: possiamo gestire decine e decine di postazioni, server, stampanti, utenti con pochissimi click del mouse. Tuttavia, un ambiente come questo può diventare un’arma a doppio taglio, se non lo gestiamo correttamente, e nella gestione corretta sono da considerare anche i backup e la possibilità di ricostruire le configurazioni a seguito di un guasto o di una errata configurazione che necessita di essere racuperata.

Riferimenti:

Gestione delle Group Policy tramite PowerShell
https://docs.microsoft.com/en-us/powershell/module/grouppolicy/?view=win10-ps

Applicazione del Security Filtering alla Group Policy
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/assign-security-group-filters-to-the-gpo

Creazione di filtri WMI per l’applicazione alle GPO
https://docs.microsoft.com/it-it/windows/security/threat-protection/windows-firewall/create-wmi-filters-for-the-gpo

Interazione di PowerShelll con WMI
https://docs.microsoft.com/it-it/powershell/scripting/learn/ps101/07-working-with-wmi?view=powershell-7.1