Group Policy e Group Policy preferences

Su AZ-802 Group Policy non viene chiesta come teoria della precedenza — quella si dà per saputa. Viene chiesta come mestiere operativo: prevedere l’effetto di una modifica prima di farla, spostare un GPO fra domini che non si fidano l’uno dell’altro, e far comportare le preferences come vuoi tu quando un utente esce da un gruppo. Sono tre zone in cui l’intuizione sbaglia quasi sempre, ed è esattamente lì che l’esame costruisce le domande.

Prevedere prima, leggere dopo: Modeling e Results

La console GPMC ha due nodi che sembrano gemelli e non lo sono affatto.

Il Modeling Wizard non si limita a fotografare la situazione attuale: simula le ipotesi. Puoi indicare un contenitore diverso da quello in cui l’oggetto si trova ora (è il modo per rispondere a «che cosa applico se sposto questo server in un’altra OU?»), aggiungere o rimuovere gruppi di sicurezza per utente e per computer, scegliere un sito AD, forzare una connessione lenta e impostare il loopback processing su Replace o Merge. Le due simulazioni — spostamento di contenitore e cambio di appartenenza a un gruppo — si impostano in due passaggi distinti della procedura guidata e si possono combinare nella stessa query: è l’unico modo pulito di validare in anticipo una riorganizzazione che tocca insieme OU e gruppi.

Due limiti da ricordare. Primo: il Modeling non valuta i GPO locali, quindi la simulazione può discostarsi dal risultato reale. Secondo: il report mostra il Winning GPO per ogni impostazione, ma per vedere quali GPO hanno provato a scrivere quel valore senza riuscirci devi aprire Advanced View, che lancia lo snap-in Resultant Set of Policy con la scheda Precedence.

Il ciclo di vita di un GPO: backup, restore, copy, import

Un GPO non è una cartella: metà del contenuto sta in Active Directory (il Group Policy Container) e metà in SYSVOL (il Group Policy Template). Copiare una directory con Explorer non produce un GPO. Le quattro operazioni supportate sono queste, e l’esame le distingue con precisione chirurgica.

Da qui discende la risposta allo scenario «due foreste, nessun trust»: copy non è praticabile, perché presuppone una relazione di fiducia; la strada è Backup-GPO nella foresta di origine, trasporto del file, New-GPO nella foresta di destinazione e Import-GPO. Per l’import bastano i permessi di modifica sul GPO di destinazione, non quelli sul GPO di produzione originale.

Restano da sistemare i riferimenti che nel dominio nuovo non significano niente: SID di gruppi e utenti, e percorsi UNC. Li converte una migration table (file .migtable, in realtà XML), che si costruisce con il Migration Table Editor — comodo il comando Populate from GPO, che estrae automaticamente tutti i riferimenti presenti. Vengono rimappati i security principal dentro user rights assignment, restricted groups, system services, file system, registry, folder redirection avanzata e la DACL del GPO; e i percorsi UNC dentro folder redirection e software installation. Attenzione a due cose: gli oggetti di destinazione citati nella migration table devono già esistere prima dell’operazione, e uno script di logon referenziato fuori dal GPO non viene copiato, viene solo rimappato il percorso.

Preferences: dispongono, non impongono

Policy e preferences finiscono entrambe nel registry, ma le policy vincono sulle preferences in caso di conflitto, e soprattutto una policy impedisce all’utente di cambiare l’impostazione, mentre una preference no. Una preference viene riapplicata a ogni refresh di Group Policy: l’utente può modificarla, e la sua modifica sopravvive fino al refresh successivo, che riscrive il valore dell’amministratore. Le preferences sono erogate da 20 client-side extension (Drive Maps, Registry, Shortcuts, Scheduled Tasks, Local Users and Groups, Printers, Files, Folders, Environment…), ognuna con una lista ordinata di item.

Le opzioni della scheda Common sono quattro, e tre su quattro sono trappole d’esame:

• Stop processing items in this extension if an error occurs on this item — il blocco riguarda solo gli item successivi, solo di quella estensione e solo in quel GPO.
• Run in logged-on user’s security context — di default gli item utente girano come SYSTEM; questa casella li fa girare con le credenziali dell’utente. Drive Maps e Printers usano già da sé il contesto utente.
• Apply once and do not reapply — applica una volta sola e poi lascia libero l’utente.
• Remove this item when it is no longer applied — di default una preference non rimuove niente quando esce dal perimetro. Questa casella la fa rimuovere, e per farlo forza l’azione a Replace; non è disponibile se l’azione è Delete.

Le azioni disponibili sulla maggior parte degli item sono quattro: Create (crea solo se non esiste), Update (modifica l’esistente, e lo crea se manca — è il default e il più usato), Replace (cancella e ricrea da zero) e Delete (rimuove).

Item-level targeting: il filtro che sta dentro l’item

Security filtering e WMI filtering agiscono sull’intero GPO. L’item-level targeting agisce sul singolo item di preference, ed è la ragione per cui un solo GPO con sei item Drive Maps, ciascuno mirato al proprio gruppo di reparto, è la soluzione corretta al posto di sei GPO: gli item vengono valutati indipendentemente l’uno dall’altro, quindi un utente che appartiene a tre gruppi riceve tre drive.

Ogni condizione (Security Group, Operating System, Organizational Unit, IP Address Range, LDAP Query, Registry Match, File Match, Site, Time Range, WMI Query, User, Computer Name, RAM, Portable Computer, Terminal Session…) restituisce vero o falso; le condizioni si combinano con AND e OR, si negano con Is Not e si raggruppano in targeting collection annidabili, che fanno da parentesi. Se il risultato complessivo è falso, l’item non viene applicato — ma, senza Remove this item when it is no longer applied, non viene nemmeno disfatto.

Trappole tipiche d’esame

• Restore ≠ Import. Il restore riporta un GPO nel suo dominio: non esiste un restore cross-domain. Fra foreste senza trust la sequenza corretta è backup → New-GPO → Import-GPO con migration table. Il copy è quello che richiede il trust, non l’import.
• La preference che non se ne va. Quando un utente esce dal gruppo di targeting, il drive resta mappato: l’azione Update non rimuove nulla fuori perimetro. Serve Remove this item when it is no longer applied. E comunque il token Kerberos dell’utente contiene ancora il SID del vecchio gruppo fino al logoff/logon: un gpupdate /force da solo non ricalcola l’appartenenza.
• Modeling contro Results. Se la domanda dice «prima di spostare l’oggetto» o «se aggiungessimo l’utente a questo gruppo», la risposta è Modeling (gira sul DC, non richiede il target acceso). Se dice «verifica che cosa è applicato adesso su quel computer», è Results o gpresult. E il Modeling ignora i GPO locali.
• Un GPO, molti item. Moltiplicare i GPO per moltiplicare i filtri è la risposta sbagliata quando il prodotto è una preference: l’item-level targeting risolve il caso dentro un GPO solo, e sopporta l’appartenenza multipla senza conflitti.
• Il contesto SYSTEM. Un item utente che deve leggere una risorsa di rete o una variabile d’ambiente dell’utente fallisce silenziosamente finché non si spunta Run in logged-on user’s security context.
• L’import non porta con sé i link. Importare le impostazioni in un GPO esistente non crea né modifica i collegamenti a OU, dominio o sito, e non tocca il security filtering: quelli si ricostruiscono a mano nella destinazione.