Continua dalla prima parte

LE OPZIONI DEI CSE

Se ci si addentra dentro ciascuna chiave di registro relativa ad un CSE, si scoprono una serie di valori interessanti che dicono come quel CSE dovrà elaborare le policy: quello che segue è un elenco con i valori trovati sulla mia macchia (e quindi non è assolutamente omnicomprensivo), ma comunque sufficiente a mostrare alcune caratteristiche interessanti delle policy.

NoGPOListChanges 
Configura il CSE per applicare una policy anche se non è stata modificata dall'ultima applicazione (valore 0) oppure per applicarla solo se ci sono state modifiche (valore 1 oppure voce non presente). Vale la pena di ricordare che normalmente Windows applica una GPO solo se si accorge che è stata modificata rispetto all'ultima applicazione: ogni GPO ha infatti due version number (uno per la parte user ed uno per quella computer ) che vengono incrementati quando si modifica la policy stessa. 
Questa configurazione è stata fatta per velocizzare il logon dato che (almeno in teoria) un utente non è in grado di "alterare" una configurazione imposta per policy e quindi riapplicarle ogni volta è decisamente controproducente.


NoUserPolicy
Se impostato ad 1, il relativo CSE NON verrà invocato durante l'elaborazione delle policy utente

NoMachinePolicy
Se impostato ad 1, il relativo CSE NON verrà invocato durante l'elaborazione delle policy macchina


NoBackgroundPolicy
Se impostato a 1 impedisce al CSE di essere eseguito durante il refresh periodico delle policy da parte della macchina (di default le policy vengono aggiornate in background). A tal proposito si rammenta che per default una qualunque macchina Windows effettua un "refresh" delle policy ogni 90 minuti (in realtà ogni 90 +x minuti, dove x è un numero casuale da 0 a 30); al contrario, idomain controller fanno un refresh ogni 5 minuti
Normalmente buona parte delle policy viene "refreshata" al momento opportuno ma ci sono però alcune cose che per loro natura non possono essere aggiornate: basti pensare agli script di startup/logon che ovviamente non devono essere ripetuti in background, oppure all'installazione/rimozione del software che rischierebbe di rimuovere un programma mentre l'utente lo sta usando!

NoSlowLink 
Se impostato a 1, le relative impostazioni della policy NON vengono elaborate quando il sistema si accorge che tra il Domain Controller e il client c'è una rete lenta: per default,  WIndows considera lenta una rete se il transfer rate è inferiore a 500 kbps.
La stima viene fatta all'avvio del client attraverso 6 ping al domain controller, 3 con dimensione (ovvero non contengono dati) e 3 ping con 2048 bytes (i tentativi sono inoltre "alternati" ovvero si fa prima un ping con 0, poi uno con 2048 e così via): per ogni ping viene misurato il tempo RTT, ovvero il tempo che intercorre tra quando il sistema ha inviato il pacchetto e quando ha ricevuto la risposta dal Domain Controller. 
Se tutti i ping impiegano meno di 10 ms, allora il sistema considera la rete veloce. In caso contrario, viene fatta una stima della velocità così costruita:
  1. Si prende l'RTT del primo ping con dimensione 0
  2. Si prende l'RTT del secondo ping con dimensione 2048
  3. Si fa la differenza tra i due
  4. Si ripetono i passi da 1 a 3 per gli altri ping rimanenti, arrivando quindi ad avere 3 distinti valori di differenza
  5. SI fa una media di questi 3 valori
  6. La velocità è data da 32000/media_precedentemente_calcolata

Proviamo a capire se questa formula è stata "tirata a caso" oppure è frutto di un calcolo corretto ancorchè approssimato. Prima di tutto, cerchiamo di capire il perchè del primo ping con 0 bytes: questo pacchetto serve come "offset" ovvero come riferimento per il successivo.
In pratica, un ping di 0 bytes è comunque composto da alcuni bytes dati dal protocollo IP e dall'instestazione ICMP e quindi rappresenta il "carico fisso" che si manda in rete ogni volta che si fa un ping. Se quindi al tempo necessario per inviare 2048 bytes tolgo il tempo necessario per inviare il "carico fisso" ottengo proprio il tempo necessario per inviare solo e soltatno 2048 bytes. Tanto per fare una analogia, è l'equivalente di quanto ci hanno insegnato alle elementari con i concetti di peso netto, tara e peso lordo: il primo ping da 0 bytes è la tara, il secondo è il peso lordo e la differenza è quindi il netto.
Ora, la velocità di una rete è data dalla formula:
 
velocità [in bps] = dati [in bit] / tempo [in sec]

Noi sappiamo il tempo di andate e ritorno (la differenza tra i due ping - viene ovviamente "mediata" per avere una stima attendibile), ma sappiamo anche quanti dati stiamo trasferendo: data la peculiarità del ping (che rimanda indietro ESATTAMENTE cosa gli è stato inviato) sappiamo anche che il totale dei dati è 2*2048 (ovvero 2048 bytes in andata e 2048 bytes in ritorno). Se approssimiamo a 2000 bytes, abbiamo che:

2000 bytes * 2 * 8 = 32000 bit

ed ecco spiegato il 32000 della formula!
 

PerUserLocalSettings
Questo parametro imposta il caching del GPC della policy: una GPO è composta da due oggetti, un GPC (oggetto di AD che contiene le info generali della policy ed alcune specifiche configurazioni) ed un GPT (contenente realmente la maggior parte delle impostazioni) che altro non è che un insieme di files salvati nella SYSVOL dei domain controller. 
Normalmente ogni sistema operativo (sia esso XP oppure 2003) tiene traccia del GPC di ciascuna policy applicata inHKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History per le policy applicate all'utente ed inHKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History per quelle applicate alla macchina: una struttura tipica è quella rappresentata in figura sottostante:
 


 
Dentro History è presente un primo livello per ciascun CSE (ed infatti si trovano gli stessi valori visti precedentemente): dentro quindi le impostazioni per uno specifico CSE esiste un livello per ciascuna policy nel corretto ordine di applicazione. Tanto per fare un esempio, il CSE "nel mezzo" nella figura (che corrisponde alla applicazione degli admin templates ovvero delle chiavi di registro) deve elaborare 2 policy (nell'ordine quella indicata con 0 e quindi quella con 1).

Con questa impostazione si impone al client di salvare una copia del GPT, oltre che nella parte utente, anche in quella di macchina: in pratica, dentro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy si troveranno anche le indicazioni di tutte le policy applicate agli utenti che si sono loggati sulla macchina, divise per SID e CSE, come nella figura sottostante.
 


Purtroppo non so quale sia il motivo di questa impostazione, anche se ad occhio credo sia per una maggiore velocità al logon (sa già quali policy applicare all'utente/computer). Se qualcuno ha maggiori info, è il benvenuto.
 

EnableAsynchronousProcessing

Se questo valore è impostato a 1, l'elaborazione delle GPO può proseguire senza attendere la fine dell'elaborazione delle impostazioni relative a questo CSE. Normalmente i CSE vengono elaborati in maniera sincrona, ovvero si attende che un CSE abbia terminato l'elaborazione di tutte le policy relative prima di passare al successivo. E' però ovvio che esistono impostazioni che possono essere elaborate anche senza aspettare le altre: questi CSE hanno quindi questo valore impostato ad 1.


MaxNoGPOListChangesInterval (valore in minuti)

Normalmente una policy viene riapplicata solo se è stata modificata (vedi impostazione NoGPOListChanges): con questa impostazone invece si obbliga la macchina ad elaborare un CSE (e quindi le policy ad esso associate) ogni X minuti, indipendentemente dalla modifica o meno della policy. L'unico CSE con questa impostazione è quello relativo al security.

 

RequiresSuccessfulRegistry

Se attiva, richiede che la DLL del CSE sia registrata (ovvero un bel regsvr32) prima di iniziare l'elaborazione. Se la DLL non è registrata il CSE non deve lavorare

 

ExtensionDebugLevel 
Indica quanto deve essere dettagliato il debug log del CSE. In pratica ha senso solo per la valutazione della parte SCECLI ovvero dell'SCE che controlla l'applicazione delle impostazioni security (vedi oltre).

 

Prosegui alla parte 3 dove si parla di come vengono applicate le policy sul client