Prosegue dalla parte 2.

APPLICAZIONE DELLE POLICY
In questa parte voglio parlare di come una macchina Windows applica le policy, partendo dalle basi che tutti conosciamo: per verificare nel dettaglio quanto detto, conviene attivare il logging avanzato delle policy, attivando, dentro la chiave di registro:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

l'opzione UserEnvDebugLevel (di tipo DWORD) ed impostandola a 0x00030002: in questo modo verrà scritto un log estremamente dettagliato in %systemroot%\debug\UserMode\UserEnv.log. Per semplicità, verrà trattato il caso di logon dell'utente, ma analoghe considerazioni valgono per le policy di macchina.
 

1 - ELENCO DELLE POLICY
Il primo passo che viene fatto è quello di costruire l'elenco delle policy che devono essere applicate. Come sappiamo, le policy possono essere linkate alle OU, al dominio e ai sites: ognuno di questi oggetti in AD ha un attributo chiamato gpLink al cui interno sono specificate le policy linkate attraverso il DN della policy stessa nell'ordine desidetato; il DN di ciascuna policy ha il seguente formato:


[LDAP://percorso_alla_policy;opzioni][LDAP://percorso_ad_altra_policy;opzioni]
 
Il campo OPZIONI è un campo a somma di bit e specifica il tipo di link: se vale allora è un normale link, se vale il link è disabilitato, mentre se vale il link è enforced (naturalmente, trattandosi di un campo a somma bdi bit, il valore significa "link disabilitato ed enforced"). Ad esempio, in un ambiente di test il formato potrebbe essere questo:

[LDAP://cn={F02EEA25-F1B6-4502-A5EC-E89C35ECD3DC},cn=policies,cn=system,DC=prove,DC=com;0][LDAP://cn={04B426CA-80D7-4D4E-AFFD-2250364F310B},cn=policies,cn=system,DC=prove,DC=com;0][LDAP://cn={6AA72418-C18F-4B4A-8AAF-85BD16D4B9C3},cn=policies,cn=system,DC=prove,DC=com;0]

(ho evidenziato le 3 policy applicate in questo esempio per riconoscerle meglio).

E' interessante esaminare l'ordine con cui viene costruito questo elenco: normalmente sappiamo che le policy vengono applicate a partire da quella locale (se presente), poi quelle linkate al site, quindi quelle linkate al dominio ed infine quelle linkate alle OU che si devono attraversare dalla root del dominio per arrivare all'oggetto utente.  Saremmo quindi portati a pensare che la costruzione dell'elenco avvenga nello stesso ordine: ed invece si scopre che viene fatto esattamente l'opposto, ovvero si parte dalle GPO linkate all'OU dell'utente e si risale fino al dominio, quindi al site ed infine si legge l'eventuale policy locale! Attenzione: questo è solo l'ordine di lettura e quindi poi le GPO saranno applicate nell'ordine inverso, ovvero nel classico modo da tutti conosciuto.

2 - LETTURA DI TUTTE LE POLICY LINKATE 
Una volta ottenuto l'elenco delle policy, Windows prova ad accedere ai relativi GPC per ottenere le informazioni generali necessarie: innanzitutto il sistema deve capire se ha il diritto di applicare le relative impostazioni (ovvero, ha il permesso di Apply Group Policy) ed, in caso positivo, deve leggere la versione della policy scritta sia su Active Directory che all'interno del GPT.INI sul file system.  (questa operazione è necessaria dato che il GPC ed il GPT vengono replicati con tempistiche e da servizi diversi - il primo da AD ed il secondo dal File Replication Service) e verificare  se sono allineati (in caso contrario la policy viene skippata dato che non si è sicuri che contenga le impostazioni corrette).

Se i controlli precedenti hanno dato conferma, Windows legge l'attributo gPCUserExtensionNames oppuregPCMachineExtensionNames (a seconda se siamo rispettivamente in logon/refresh utente oppure in avvio/refresh di macchina)che contiene l'elenco dei CSE usati nella policy: in particolare questo attrivuto è formato da una serie di coppie che specificano tutte le Client side Extension e le server-side extensions usate con il seguente formato
 

[{guid_client_ext}{guid_server_ext}][{guid_client_ext}{guid_server_ext}]

Dove i valori presenti sono quelli riportati nel primo articolo di questa serie: ad esempio, una policy potrebbe contenere questa coppia:

[{A2E30F80-D7DE-11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}]
 
che specifica che la policy avrà bisogno della CSE per la gestione dell'IE e dello "snap-in" relativo alla gestione di IE in fase di editing della policy.
Se la policy deve essere processata, il client la aggiunge ad una lista interna che mantiene per ogni CSE.
 

3 - APPLICAZIONE DELLE POLICY
Arrivati a questo punto la macchina ha a disposizione delle liste (suddivise per CSE) che contengono i link alle policy da applicare: il client invoca quindi ciascun CSE che inizia il suo lavoro di applicazione delle singole policy, verificando prima che la policy sia stata modificata dall'ultima applicazione.
Oltre alla verifica della modifica, il client controlla anche che la versione del GPT presente sulla SYSVOL corrisponda alla versione di GPC presente in AD: infatti, GPT e GPC sono salvati in posti diversi e anche replicati da strumenti diversi (il GPC è replicato da Active Directory mentre il GPT dal File Replication Service). Per questo motivo potrebbe accadere che il GPT ed il GPC di una policy non siano allineati: in queste condizioni il client NON applica la policy, dato che non è sicuro delle impostazioni presenti.

NOTA PERSONALE SULL'APPLICAZIONE
Basandosi sullo schema appena analizzato, emergono alcuni interessanti spunti di riflessione legati ad un comune denominatore, ovvero la velocità di avvio delle macchine client
Microsoft in generale suggerisce che il numero di policy applicate ad un oggetto dovrebbe essere relativamente piccolo, senza mai però entrare nel dettaglio di quanto significhi "piccolo": molti amministratori rimangono quindi con il dubbio se sia più giusto averepoche policies ciascuna con tante impostazioni (seguendo quindi i dettami di Microsoft ma perdendo in flessibilità) piuttosto che avere più policies "dettagliate" e magari anche filtrate per particolari utenti/gruppi.
Dopo questa disamina emerge che effettivamente conviene avere meno policies:  infatti, le macchine Windows durante l'elaborazione provano ad accedere a tutte le policies incontrate nel proprio cammino e, di conseguenza, la migliore strada è proprio quella di minimizzare il numero di policies applicate (meno letture o tentativi di lettura da AD).
Tra l'altro è anche importante non lasciare policies "vuote" ovvero GPO senza nessuna impostazione che però rimangono lì e tutte le volte vengono "lette" dai client.
Naturalmente non stiamo parlando di tempi "enormi" ma, come dice un vecchio adagio "un soldo risparmiato è un soldo guadagnato".
 
DOVE VENGONO SALVATE LE IMPOSTAZIONI?
Come detto precedentemente, le impostazioni che vengono fatte in una group policy sono salvate all'interno del GPT, che altro non è che una struttura sul file system dove si trovano appunto i files contenenti i settaggi. In realtà le cose non sono così semplici, dato che non tutti i parametri possono essere salvati sul file system e vengono quindi memorizzati come "oggetto figlio" della policy in Active Directory. Questa tabella riepiloga come sono salvate le varie impostazioni:

Impostazione Active Directory SYSVOL
Wireless Settings Oggetto msieee80211-policy dentro il GPC della policy  
Folder Redirection   file fdeploy.ini (nella parte USER)
Administrative Templates   file registry.pol  e copia degli .adm usati
Disk Quotas   file registry.pol (nella parte MACHINE)
QOS Configuration   file registry.pol (nella parte MACHINE)
Scripts   qualunque file eseguibile nelle directory opportune
IE Configuration   files con estensione .inf .ins
Security Settings       file Gptmpl.inf
 EFS Recovery Agent    file registry.pol (nella parte MACHINE)
Software installation Oggetto packageRegistration dentro il GPC della policy files .aas
IPSec Configuration Oggetto ipsecPolicy dentro il GPC della policy  
Remote Install (non esiste il CSE perchè questa policy si applica al setup della macchina)   file Oscfilter.ini

Rimane solo da capire, nella parte 4, le relazioni che esistono tra i CSE e la policy così come la vediamo nell'editor