GPO: Come capire dove sono i problemi
Da PierGiorgio Malusardi (MCSE – MCSA – MCT) - IT Pro Evangelist Microsoft Italia
Le Group Policy (termine usualmente tradotto in italiano come Criteri di Gruppo) sono uno strumento molto potente per la configurazione e gestione di un sistema informativo basato su tecnologia Microsoft ed in particolare su Active Directory.
Attraverso le Group Policy (che indicherò da ora semplicemente con la sigla GP) è possibile configurare ogni aspetto del funzionamento dei computer connessi alla nostra rete aziendale.
La loro estrema potenza può in alcuni casi, se usate con scarsa attenzione/progettazione e senza seguire delle “buone pratiche”, generare problemi agli utenti finali nell’accesso alle risorse locali o remote, nell’usabilità del sistema o nell’accesso ai dati.
Risalire alla GP che causa di questi problemi può non essere un’operazione banale.
In questo breve articolo cercherò di mostrare alcune tecniche e strumenti disponibili per fare l’analisi dei problemi legati alle GP.
In questa pagina
Come funzionano le GPO?
Ricerca dei problemi
Alcuni esempi di problemi e possibili soluzioni
Conclusioni
Come funzionano le GPO?
Il primo vero strumento per la ricerca e la comprensione dell’origine dei problemi è la conoscenza delle tecnologie e degli strumenti utilizzati; penso sia quindi importante, prima d’ogni altra cosa, fare un riassunto del funzionamento delle GP, senza per altro la pretesa di essere esaustivo.
Cosa sono le GP e dove sono conservate
Ogni singola GP è un insieme di impostazioni che può essere applicato per configurare un ambiente di lavoro, in base all’utente e/o in base alla macchina.
Le impostazioni presenti in una GP sono divise in due sezioni separate (Figura1):
Computer Configuration: applicata al computer qualsiasi sia l’utente che esegue il logon
User Configuration: applicata all’utente indifferentemente dal computer su cui esegue il logon
In ogni GP entrambe le sezioni possono essere utilizzate, e contenere delle impostazioni abilitate, o in alternativa si può usare una sola delle due sezioni disabilitando l’altra; in questo caso avremo delle GP “dedicate” agli utenti (nel caso si disabiliti la parte Computer Configuration) e delle GP “dedicate” ai computer (nel caso si disabiliti la parte User Configuration) e una più rapida applicazione e analisi delle singole GP.
Le GP sono conservate, in un dominio Active Directory, come oggetti (Group Policy Object o GPO).
Ogni GPO è costituito da due elementi distinti:
Group Policy Container:
è mantenuto in Active Directory nel container cn=Policy, cn=System, dc=Domain, dc=domain (Figura 2)
contiene informazioni generali relative alla GP (es. “friendly name”, percorso al GPT, configurazione Wireless,...) (Figura 3)
è referenziato da un GUID che individua univocamente la GP a livello di foresta
Group Policy Template:
è rappresentato da una struttura di directory e file su disco deputata a mantenere le diverse impostazioni indicate nella GP
tutti i GPT sono conservati sotto lo share di rete SYSVOL replicato su tutti i Domain Controller
ogni GPT inizia con un subfolder di SYSVOL\<nome del dominio AD>\Policies con nome corrispondente al GUID della GP collegata
all’interno del folder con nome uguale al GUID della GP, troviamo normalmente la struttura presentata in Figura 4.
La cartella ADM contiene il file ADM usati per costruire la parte Administrative Templates della policy
La cartella Machine contiene le impostazioni relative alla parte Computer Configuration della GP
La cartella User contiene le impostazioni relative alla parte User Configuration della GP
Il file GPT.INI contiene informazioni relative alla versione e al display name della GP
Figura 1: Struttura di una GP
Figura 2: Group Policy Container
Figura 3: Group Policy Template
In funzione del tipo di dato da salvare, alcune parti delle GP sono salvate sia nel GPT sia nel GPC, altre solo nel GPC, altre ancora (es. le policy di IPSec) in nessuno dei due.
Area della Policy |
Posizione dello Storage |
---|---|
Wireless |
In GPC sotto |
Folder Redirection |
In GPT, in un file chiamato fdeploy.ini, nel folder ...\user\Documents and Settings |
Administrative Template |
In GPT, in un file chiamato registry.pol in entrambi i folder |
Disk Quota |
In GPT, sempre in registry.pol, ma solo sotto il folder ...\machine |
Scripts |
In GPT; gli script di Startup e Shutdown sono conservati nei seguenti folder: |
Internet Explorer |
In GPT, nel folder |
Security |
In GPT, dentro un file chiamato gptTmpl.inf nel folder |
Software Installation |
Sia in GPT sia in GPC; |
Software Restriction Policy |
In GPT, dentro il file registry.pol |
IP Security |
Ne in GPC ne in GPT; Salvate in AD nel container cn=IP Security, cn=System, dc=<Dominio> |
Figura 4: Struttura di un GPT
La gestione della versione delle GPT
Ad ogni GP è associato un numero di versione che viene utilizzato principalmente nella fase di replica dei dati tra Domain Controller.
Il numero di versione di una GP è mantenuto in due diversi posti:
nell’attributo versionNumber dell’oggetto GPC in Active Directory
nel file GPT.INI nel folder radice della GP sotto SYSVOL
In Windows 2000, i numeri di versione contenuti nel GPT e nel GPC devono coincidere perché le policy possano essere processate ed applicate. Problemi legati alla replica di Active Directory o alla replica del folder SYSVOL possono rendere i due numeri di versione diversi su un dato Domain Controller.
Windows Server 2003 e Windows XP non presentano più questo problema e le policy vengono processate anche se i numeri di versione in GPT e GPC non corrispondono.
Il numero di versione di una GP viene incrementato secondo la formula:
Versione = 65536 * (Numero di modifiche alla parte User Configuration) + Numero di modifiche alla parte Computer Configuration
Come vengono applicate le GPO
Il primo concetto fondamentale da capire riguardo all’applicazione delle GP è che questo è un processo eseguito strettamente lato client. I Domain Controller fungono solo da storage delle configurazioni e dei permessi.
Il processo di applicazione avviene in due fasi:
GP core: è la fase in cui il sistema operativo client determina quali GP devono essere applicate alla macchina/utente e chi le deve applicare.Le GP possono essere collegate a diversi container di Active Directory e delle Local Policy possono essere definite sulla macchina locale. Ad ogni oggetto di Active Directory (user o computer) possono, quindi, essere applicate più di una GP. In questi casi esiste una gerarchia di applicazione che è determinata durante la fase GP core.Facendo riferimento alla Figura 5 l’ordine di applicazione delle GP per una macchina/utente che risiede nella Organizational Unit OU2a è il seguente:
Local Policy definita sulla singola macchina (LP-1)
Policy di Sito (GP-1)
Policy di Dominio (GP-3 e poi GP-2)
Policy connesse ai diversi livelli di Organizational Unit (GP-6, GP-5 e per ultima GP-4)
È evidente, da quanto descritto, che se, ad un qualsiasi livello, sono collegate più policy queste vengono applicate leggendo dal basso verso l’alto la lista mostrata nell’interfaccia di gestione delle GP. Nel caso in cui policy diverse configurino in modo dissimile lo stesso parametro, la policy applicata per ultima ha il sopravvento.Queste regole di applicazione possono essere sovvertite dai meccanismi di “Non-Sovrascrittura” e di “Blocco dell’ereditarietà” per i la descrizione dei quali si rimanda ai documenti riportati nel paragrafo Risorse.
CSE (Client Site Extensions): è la fase in cui le diverse GP sono realmente applicate richiamando le opportune DLL (le CSE)
Le CSE vengono fornite con Windows e sono registrate sotto la chiave di registry
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensionsÈ possibile sviluppare proprie CSE che eseguano l’applicazione di GP personalizzate. Nel caso si decida di scrivere proprie CSE, deve essere posta molta attenzione nello sviluppo del codice in quanto le extension sono eseguite nel contesto di Winlogon e quindi eventuali bug possono creare seri problemi all’intero sistema.
Figura 5: Gerarchia di applicazione delle GP
Policy |
Client Side Extensions |
---|---|
Wireless |
Gptext.dll |
Folder redirection |
Fdeploy.dll |
Microsoft disk quota |
Dskquota.dll |
QoS packet scheduler |
Gptext.dll |
Scripts |
Gptext.dll |
Internet Explorer zone mapping |
Iedkcs32.dll |
Security |
Scecli.dll |
Internet Explorer branding |
Iedkcs32.dll |
EFS recovery |
Scecli.dll |
Microsoft offline files |
Cscui.dll |
Software installation |
Appmgmts.dll |
IP Security |
Gptext.dll |
Vediamo ora, passo passo, come avviene il processo di applicazione delle GP:
I client eseguono una richiesta DNS alla ricerca del record SRV che indica un server LDAP (un DC) nel proprio sito
Il client si connette al DC usando un normale processo di DC Locator
Il client esegue una verifica della velocità della connessione verso il DC usando ICMP
Il client usa LDAP per costruire le liste di GPO per la OU, il dominio e il sito di appartenenza e determina se ha il permesso di processare le diverse GPO (permessi necessari Read e Apply per l’utente/macchina a cui si applica la policy)
Il client usa LDAP per ricavare dai GPC il percorso dove trovare i relativi GPT, il numero di versione e le CSE implementate
Il client usa SMB per interrogare il GPT, avere il percorso di gpt.ini e determinare il numero di versione
Ogni CSE è eseguita nell’ordine in cui sono registrate e processano le GPO se e solo se queste sono cambiate rispetto all’ultimo ciclo di applicazione (determinato dalla fase di Core processing
Se le GPO risultano modificate, le CSE processano le nuove impostazioni e quindi si passa alla successiva CSE fino al completamente
Ogni CSE passa a Windows Management Instrumentation (WMI) i dati necessari ad eseguire le operazioni di Resultant Set of Policy (RSoP)
Il processo descritto può avvenire in due diverse modalità:
Foreground: è eseguito durante l’avvio del computer o il logon dell’utente e può essere asincrono o sincrono:
Win 2000 ha come default il processamento sincrono
Win XP/2003 ha come default il processamento asincrono
Background: è eseguito periodicamente in base al ruolo del computer (ogni 5 minuti per i DC, ogni 90 minuti più o meno un valore random di minuti compreso tra 0 e 30 per gli altri membri del dominio). L’applicazione delle GP in background è asincrono per definizione.
Ricerca dei problemi
Dalla descrizione del processo di applicazione delle GP, è evidente che ci possono essere diverse fonti di problemi che possono impedirne il corretto funzionamento.
Alcune situazione apparentemente erronee sono in realtà comportamenti corretti:
Alcune CSE non applicano le GP in presenza di link lenti verso il DC (es. Installazione di SW, redirezione dei folder). Questo comportamento è configurabile via GP
Alcune GP sono processate in modo asincrono, ma non fanno nulla fino al successivo evento sincrono (es. scripts)
Nessuna CSE processerà le proprie policy se non ci sono state modifiche dall’ultimo ciclo di applicazione. Questo è determinato confrontando il numero di versione delle GP con un numero di versione mantenuto nel registry del client
In altri casi il problema potrebbe non essere direttamente legato alle GP.
Problemi non legati alle GP
Ci sono diversi problemi legati all’infrastruttura e alla configurazione del client che possono avere un impatto sulla possibilità di applicazione delle GP.
Problemi di raggiungibilità dei DNS server
La prima cosa da verificare è la possibilità per il client di raggiungere il server DNS.Durante la fase di applicazione delle GP il cliente deve fare ripetuti accessi al DNS alla ricerca di diversi record SRV relativi a LDAP.
Per verificare la disponibilità del DNS server e la corretta configurazione del client basta lanciare nslookup da una shell; ci si deve aspettare una risposta come quella riportata in Figura 6.
Figura 6: Verifica funzionamento DNS
Problemi di raggiungibilità dei Domain Controller
La possibilità di contattare i DC è fondamentale per la corretta applicazione delle GP.
La prima cosa da verificare è la possibilità di contattare un Domain Controller.
Il semplice logon dell’utente alla macchina non fornisce indicazioni definitive (potrebbe aver fatto logon con credenziali in cache) e si deve quindi verificare la possibilità di eseguire un ping verso il DC o di accedervi in altro modo.
Una volta stabilito che il client e il DC possono dialogare correttamente si deve verificare che nel DNS il DC sia correttamente registrato.
In fase di applicazione delle GP il client eseguirà una query DNS alla ricerca del record SRV che specifica un LDAP server nel sito di appartenenza:
_ldap._tcp.<SITO_DI_APPARTENENZA>._sites.dc._msdcs.<NOME_DEL_DOMINIO>
Se questo record non viene correttamente trovato e risolto, l’applicazione delle GP non può essere eseguita.
Per verificare la corretta risoluzione del record indicato è necessario eseguire una query DNS usando nslookup come riportato in Figura 7.
Figura 7: Verifica della raggiungibilità dei Domain Controller
Problemi di replica del folder SYSVOL
La cartella SYSVOL contiene i subfolder relativi ai GPT delle diverse GP.
Questo folder deve essere mantenuto allineato tra tutti i Domain Controller per non avere problemi nell’applicazione delle policy (es. problemi di versione delle policy con Windows 2000).
Un tool utile per l’analisi dei problemi di FRS è Ultrasound scaricabile al link:
https://www.microsoft.com/downloads/details.aspx?FamilyID=61acb9b9-c354-4f98-a823-24cc0da73b50&DisplayLang=en
L’analisi dei problemi di funzionamento esula dagli scopi di questo articolo, ma alcune delle operazioni che possono essere compiute sono:
Assicurarsi che i DC abbiano il servizio File Replication Service attivo
Assicurarsi che SYSVOL sia condiviso (fare riferimento agli articoli KB 257338 e 315457 per la risoluzione dei problemi legati a SYSVOL)
Usare GPOTool (presente nel Resource Kit) per confrontare il numero di versione dei GPT sui DC: gptool /verbose
In caso di urgenza si possono copiare I file a mano tra i diversi DC
Problemi con ICMP
Come detto in precedenza alcune CSE non applicano le GP in presenza di un link lento. Per default il discrimine tra link lento e veloce è posto a 500Kbps. La determinazione della velocità è fatta eseguendo dei ping verso il Domain Controller da cui verranno scaricate le GP.
Se il protocollo ICMP è disabilitato lato client o lato server l’applicazione delle GP viene interrotta.
La prima soluzione possibile è ovviamente riabilitare il protocollo ICMP tra client e DC. Se questo non è possibile si deve intervenire disabilitando la verifica della velocità del link.
Questa ultima operazione può essere fatta impostando a 0 le due policy:
Computer Configuration\Administrative Templates\System\Group Policy\Group Policy Slow Link Detection
User Configuration\Administrative Templates\System\Group Policy\Group Policy Slow LinkDetection
Se l’applicazione delle policy non funziona in toto questo metodo ovviamente non risolverà il nostro problema e dovremo intervenire impostando a 0, direttamente sul client, le voci di registry:
GroupPolicyMinTransferRate in HKLM\Software\Policies\Microsoft\Windows\System\
GroupPolicyMinTransferRate in HKCU\Software\Policies\Microsoft\Windows\System\
Un altro problema con il protocollo ICMP può presentarsi nel caso dei router o dei firewall posti tra il DC e il client limitino la dimensione dei pacchetti ICMP consentiti. Il problema è descritto nel documento https://support.microsoft.com/default.aspx?scid=kb;en-us;816045
Problemi legati alle GP
Dopo aver verificato che i problemi di applicazione delle GP non sono legati all’infrastruttura, si deve procedere all’analisi del processo di applicazione delle GP per risalire alla causa.
In questa analisi ci sono di aiuto alcuni tool disponibili con il sistema operativo, il Resource Kit o liberamente scaricabili da internet.
Il miglior strumento disponibile per l’analisi dei problemi legati all’applicazione delle GP è il log degli eventi.
Esistono sostanzialmente due tipi di log legati all’applicazione delle GP:
Application Event Log su ogni client
Log specifico per ogni CSE
Uso dell’Application Log sui client
Gli Application Event legati alle GP sono generati dalle seguenti sorgenti:
Userenv: genera la maggior parte degli eventi legati alla fase GP core
Scecli: Eventi legati alle CSE per la sicurezza
Appmgmt o Application Manager: Eventi legati all’installazione di software via GP
UserInit: Eventi legati agli script
Folder Redirection: Folder Redirection event
È possibile utilizzare la Group Policy Management Console per analizzare gli eventi relativi all’applicazione delle policy su qualsiasi macchina in rete: gli eventi mostrati saranno solo quelli relativi all’applicazione delle policy (Figura 8).
Per aumentare la quantità di informazioni riportate nel log Application è possibile impostare ad uno (1) la seguente voce di registry:
- RunDiagnosticLoggingGroupPolicy (DWORD) in
HKLM\Software\Microsoft\Windows NT\Diagnostics\
L’abilitazione della modalità diagnostica può causare problemi di performance e quindi deve essere abilitata solo in caso di reale necessità.
In alcuni casi, malgrado l’abilitazione della modalità diagnostica, le informazioni riportate nel log Application non sono sufficienti per determinare con esattezza dove risieda il problema.
In questi casi è necessario abilitare il log esteso degli eventi per le singole CSE.
Figura 8: Uso di GPMC per l'analisi di errori di applicazione delle GP
Uso dei log estesi
L’abilitazione dei log estesi richiede la modifica delle voci di registry riportate nei seguenti articoli:
Abilitazione di userenv.log
https://support.microsoft.com/default.aspx?scid=kb;en-us;221833Abilitazione dei log per Scecli
https://support.microsoft.com/default.aspx?scid=kb;en-us;245422Abilitazione dei log per la redirezione dei folder
https://support.microsoft.com/default.aspx?scid=kb;en-us;246509
In realtà, è disponibile un metodo più semplice per l’abilitazione del log Application esteso e dei log per le singole CSE. Questo funziona solo se le policy funzionano almeno parzialmente.
Al link http://www.gpoguy.com/tools.htm è disponibile il file gpolog.adm che consente l’abilitazione di tutti i log estesi per le GP.
Per utilizzare questo file:
Scaricarlo dal sito indicato
Creare una nuova policy e collegarla alla OU entro cui si trovano le macchine/utenti per i quali si vuole abilitare il log esteso.
Espandere il ramo Computer configuration
Fare click con il tasto destro del mouse su Administrative Template e, dal menù contestuale, scegliere l’opzione Add/Remove Templates
Nella finestra di dialog Add/Remove Templates cliccare il bottone Add e navigare nel file system fino a trovare il file gpolog.adm
Selezionare il file e premere OK
In Group Policy Object Editor espandere il menù View e selezionare Filtering
Nella finestra di dialogo Filtering deselezionare l’opzione Only show policy settings that can be fully managed (Figura 9)
A questo punto sono disponibili, sotto Computer Configuration\Administrative Templates\System\Group Policy\Logging, una serie di policy per l’abilitazione dei log estesi delle CSE (Figura 10).
Attenzione |
Figura 9: Abilitazione dei log per le CSE – 1
Figura 10: Opzioni di abilitazione dei log CSE fornite da gpolog.adm
Il log di Userenv.log è il più prolisso ma anche il più utile per l’analisi dei problemi e viene salvato (come gli altri) in %windir%\debug\usermode\.
All’interno possiamo trovare il log dell'applicazione delle GP e dello user profile; può essere un po’ criptico da comprendere, ma dettaglia ogni passaggio del processo di applicazione delle GP.
In fase di analisi del problema, dopo aver attivato le I log estesi delle CSE, rinominate il file userenv.log e quindi forzate la riapplicazione delle policy per avere un nuovo log (usare gpupdate /force su WinXP e Win2003; secedit su Win2000).
Figura 11: userenv.log
Altri tool di analisi dei problemi
Ci sono altri tool che possono essere di grande aiuto nell’analisi dei problemi legati alle GP:
Gptool.exe: questo tool, parte del Resource Kit di Windows Server 2003, può essere utilizzato, anche da remoto, per analizzare le policy realmente applicare ad un computer e/o un utente. Se usato con lo swich /verbose una parte delle informazioni restituite dalla GPMC e tra le altre il numero di versione delle singole policy così come registrato dal GPT e dal GPC (Figura 12).
Replmon.exe: questo tool, parte dei Support Tool presenti sul CD di installazione di Windows Server 2003, consente di verificare il buon funzionamento delle repliche tra i diversi Domain Controller ed è quindi utile in tutte quelle situazioni in cui sono presenti informazioni diverse sui diversi DC.
Snap-in Resultant Set of Policy: questo snap-in (parte integrante di Windows Server 2003) consente di fare l’analisi delle policy effettivamente applicate. È possibile in questo modo tracciare problemi legati all’uso del flag Enforced sulla policy o del flag Block Inheritance sul link. Informazioni simili, ma più estese, possono essere ottenute usando il tool a linea di comando gpresult (parte del sistema operativo) o la Group Policy Management Console (GPMC) scaricabile al link:
ADDiag.exe: questo tool, installabile con i Support Tools presenti sul CD di Windows Server 2003, fornisce informazioni sullo stato del software installato, o disponibile per installazione, su un computer gestito con la tecnologia Intellimirror Software Installation and Maintenance. Le informazioni fornite sono le seguenti:
Utente (credenziali di logon e SID) e piattaforma (processore e località) che possono influenzare l’installazione del software
La presenza o meno di Terminal Server in esecuzione sul computer
Informazioni sull’installazione o la disponibilità di software, dedotte da voci di registry
La presenza di software disponibile per l’installazione via Active Directory
Informazioni relative a Windows Installer
Figura 12: Numero di versione delle GP restituito da gpotool
Alcuni esempi di problemi e possibili soluzioni
Errata assegnazione dei permessi
Perché le GP siano applicate, i computer/utenti a cui devono essere applicate devono avere i diritti di Read e Apply sul policy link
La funzione Resultant Set of Policy della GPMC, e del tool a line di comando gpresult, consente di verificare facilmente se sono state assegnate correttamente le policy per un dato utente.
Un altro problema che può sorgere è legato all’errata assegnazione di permessi sullo share SYSVOL, da cui vengono letti i file che contengono le impostazioni delle policy. In questo caso all’utente può comparire un messaggio di accesso negato. Per verificare la corretta impostazione dei diritti di accesso è di grande utilità gpotool /checkacl /verbose. Fare riferimento agli articoli KB 257338 e 315457 per la risoluzione dei problemi legati a SYSVOL.
Servizio TCP/IP Netbios Helper disattivato
Quando il servizio TCP/IP Netbios Helper è disattivato nessuna GP è processata e nei log sono presenti errori relativa alla lettura di gpt.ini o altri file del GPT.
Per risolvere il problema si deve verificare che il computer client abbia il servizio TCP/IP Netbios Helper attivo che è necessario per risolvere il percorso UNC al GPT
Problema nella redirezione dei folder
Il problema si manifesta con l’impossibilità da parte dell’utente di applicare la policy di redirezione dei folder.
Nella maggior parte dei casi il problema si presenta quando la policy è impostata per creare un folder per ogni utente (uso della macro %username% nella definizione del folder di redirezione) e l’utente non ha tale diritto nel folder parent.
Ci si deve assicurare che l’utente abbia il diritto di creazione di folder nello share di appoggio. Consultare l’articolo KB 274443 per verificare i permessi necessari
Problemi di installazione del software via GP
Il problema si manifesta con l’impossibilità di installare correttamente le applicazioni usando le policy di Software Installation oppure con la necessità di eseguire diversi riavvii/logon utente perché si applichino.
In questo caso si devono verificare diverse cose
di aver inserito, durante la creazione della policy, un UNC come percorso di distribuzione del pacchetto e non una directory locale al server
che non si sia in presenza di un link lento (o visto come tale)
Se sono necessari più logon o riavvii per vedere applicata la distribuzione del software via policy, provare a disabilitare la Fast Logon Optimization (solo XP) abilitando la seguente policy:
Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon
Conclusioni
La ricerca della sorgente degli errori nell’applicazione delle GP è, come quasi tutte le operazioni di questo tipo, un’operazione complessa che richiede pazienza, tempo e che si affina con l’esperienza.
Sono di notevole aiuto, nell’evitare l’insorgere dei problemi e nel determinare la loro causa qualora si presentassero
una buona progettazione dell’infrastruttura di Active Directory e delle policy che si vogliono applicare
il mantenimento di un’infrastruttura semplice
l’uso di policy separate per computer e per utenti
la precisa documentazione di tutto quello che si è posto in essere e delle modifiche apportate nel tempo