Supporto Tecnico Enterprise : Directory Services

Restricted Group - Problemi con l’applicazione delle Group Policy

itentblg — Mon, 27 Apr 2009 02:00:00 GMT

In questo post approfondiremo i possibili problemi che si possono verificare nell’applicazione dei Restricted Group tramite Group Policy.

Problema

Quando si presenta il problema durante il boot la configurazione del Restricted Group non è applicata completamente ed è creato un evento SceCli 1001:

Event ID     : 1001
Category     : None
Source       : SceCli
Type         : Error
Generated    : 11/10/2008 5:27:44 AM
Written      : 11/10/2008 5:27:44 AM
Machine      : W010010312
Message      : Security policy cannot be propagated. Impossibile eliminare la cache dei criteri di gruppo.

Considerando come funziona l’applicazione dei Restricted Group, leggi il precedente post, ho ipotizzato che il problema fosse causato da un lock sul file tmpgptfl.inf. Per avere una conferma alla mia ipotesi ho abilitato l’audit sui tutti i file e cartelle sotto la cartella C:\Windows\Security\Templates avendo una conferma alla mia idea. Infatti l’evento 560 mostra che il processo con PID 2972 “tocca” il file tenendolo “bloccato”.

Event ID     : 560
Source       : Security
Type         : Audit Success
Generated    : 11/10/2008 5:27:44 AM
Written      : 11/10/2008 5:27:44 AM
Machine      : MBXP
Message      : Object Open:
   Object Server:   Security
   Object Type:   File
   Object Name:   C:\WINNT\security\templates\policies\tmpgptfl.inf
   Handle ID:   -2147478420
   Operation ID:   {0,207111}
   Process ID:   2972
   Image File Name:
   Primary User Name:   MBXP$
   Primary Domain:   DISNEY
   Primary Logon ID:   (0x0,0x3E7)
   Client User Name:   -
   Client Domain:   -
   Client Logon ID:   -
   Accesses:   %%4416
                     %%4423
Privileges:   -
   Restricted Sid Count:   0
   Access Mask:   Security8

Il PID è elevato (2972) e non è sicuramente quello del processo Winlogon. Aprendo task manager scopro che il processo con il PID 2972 è ALG.exe ovvero Application Layer Gateway Service. Questo processo non dovrebbe andare a leggere questi file e quindi è inspiegabile come mai questi file siano letti e soprattutto messi in lock rendendoli illeggibili dal processo Winlogon per l’applicazione delle policy.

Con process monitor, configurandolo per collezionare i dati durante il boot, il sistema ha tracciato l’accesso ai file sotto la cartella “C:\WINNT\security\templates\policies”.

Il log di Process Monitor mostra che il processo ALG.exe accede ad un notevole numero di file e cartelle. Tra le cartelle che sono aperte dal processo ALG.exe c’è anche la cartella C:\WINNT\SECURITY\TEMPLATES\POLICIES e tutti i file contenuti in essa e quindi anche il file TMPGPTFL.INF.

Qui sotto la sequenza del process monitor log:

13:34:41.1974394 alg.exe 3384 QueryDirectory C:\WINNT\security SUCCESS 0: ., 1: .., 2: Database, 3: logs, 4: templates...
13:34:41.2118214 alg.exe 3384 CreateFile C:\WINNT\security\TEMPLATES SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened...
13:34:41.2317561 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:41.2379169 alg.exe 3384 QueryDirectory C:\WINNT\security\templates\policies SUCCESS 0: ., 1: .., 2: gpt00000.dom, 3: gpt00001.inf, 4: gpt00002.inf, 5: tmpgptfl.inf
13:34:41.2380052 alg.exe 3384 QueryDirectory C:\WINNT\security\templates\policies NO MORE FILES
13:34:41.2380490 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies SUCCESS
13:34:42.6791166 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies\tmpgptfl.inf SUCCESS Desired Access: Read Data/List Directory, Read Attributes, Disposition: Open, Options: Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:42.6817174 alg.exe 3384 QueryStandardInformationFile C:\WINNT\security\templates\policies\tmpgptfl.inf SUCCESS AllocationSize: 144, EndOfFile: 142, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:42.7097160 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies\gpt00000.dom SUCCESS Desired Access: Read Data/List Directory, Read Attributes, Disposition: Open, Options: Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:42.7177564 alg.exe 3384 QueryStandardInformationFile C:\WINNT\security\templates\policies\gpt00000.dom SUCCESS AllocationSize: 2,048, EndOfFile: 1,822, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:42.7609479 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies\gpt00001.inf SUCCESS Desired Access: Read Data/List Directory, Read Attributes, Disposition: Open, Options: Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:42.7613351 alg.exe 3384 QueryStandardInformationFile C:\WINNT\security\templates\policies\gpt00001.inf SUCCESS AllocationSize: 5,120, EndOfFile: 4,638, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:42.7811776 alg.exe 3384 CreateFile C:\WINNT\security\templates\policies\gpt00002.inf SUCCESS Desired Access: Read Data/List Directory, Read Attributes, Disposition: Open, Options: Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
13:34:42.7953439 alg.exe 3384 QueryStandardInformationFile C:\WINNT\security\templates\policies\gpt00002.inf SUCCESS AllocationSize: 1,536, EndOfFile: 1,282, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:44.6352280 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies\tmpgptfl.inf SUCCESS
13:34:44.6376565 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies\gpt00000.dom SUCCESS
13:34:44.6379161 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies\gpt00001.inf SUCCESS
13:34:44.6381773 alg.exe 3384 CloseFile C:\WINNT\security\templates\policies\gpt00002.inf SUCCESS

Ho preso il call stack da process monitor per la createfile del processo ALG.exe sul file TMPGPTFL.INF . Qui sotto il call stack preso da process monitor:

13:34:40.5168152 alg.exe 3384 CreateFile C:\ SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
-----------------------------------------------------------------------------------------------------
0 fltMgr.sys   fltMgr.sys + 0x1944     0xf84b1944 C:\WINNT\System32\Drivers\fltMgr.sys
1 fltMgr.sys   fltMgr.sys + 0x3352     0xf84b3352 C:\WINNT\System32\Drivers\fltMgr.sys
2 fltMgr.sys   fltMgr.sys + 0xfccb     0xf84bfccb C:\WINNT\System32\Drivers\fltMgr.sys
3 fltMgr.sys   fltMgr.sys + 0x10142    0xf84c0142 C:\WINNT\System32\Drivers\fltMgr.sys
4 ntkrnlpa.exe ntkrnlpa.exe + 0x17003 0x804ee003 C:\WINNT\system32\ntkrnlpa.exe
5 ntkrnlpa.exe ntkrnlpa.exe + 0x17003 0x804ee003 C:\WINNT\system32\ntkrnlpa.exe
6 ntkrnlpa.exe ntkrnlpa.exe + 0xdc996 0x805b3996 C:\WINNT\system32\ntkrnlpa.exe
7 ntkrnlpa.exe ntkrnlpa.exe + 0xd8e77 0x805afe77 C:\WINNT\system32\ntkrnlpa.exe
8 ntkrnlpa.exe ntkrnlpa.exe + 0x93431 0x8056a431 C:\WINNT\system32\ntkrnlpa.exe
9 ntkrnlpa.exe ntkrnlpa.exe + 0x93da8 0x8056ada8 C:\WINNT\system32\ntkrnlpa.exe
10 ntkrnlpa.exe ntkrnlpa.exe + 0x9647a 0x8056d47a C:\WINNT\system32\ntkrnlpa.exe
11 ntkrnlpa.exe ntkrnlpa.exe + 0x65a48 0x8053ca48 C:\WINNT\system32\ntkrnlpa.exe
12 ntkrnlpa.exe ntkrnlpa.exe + 0x26755 0x804fd755 C:\WINNT\system32\ntkrnlpa.exe
13 ntkrnlpa.exe ntkrnlpa.exe + 0x13e1cc 0x806151cc C:\WINNT\system32\ntkrnlpa.exe
14 ntkrnlpa.exe ntkrnlpa.exe + 0x13eb9d 0x80615b9d C:\WINNT\system32\ntkrnlpa.exe
15 ntkrnlpa.exe ntkrnlpa.exe + 0x13efd4 0x80615fd4 C:\WINNT\system32\ntkrnlpa.exe
16 ntkrnlpa.exe ntkrnlpa.exe + 0xedca7 0x805c4ca7 C:\WINNT\system32\ntkrnlpa.exe
17 ntkrnlpa.exe ntkrnlpa.exe + 0x6a1e2 0x805411e2 C:\WINNT\system32\ntkrnlpa.exe

Process Monitor, non avendo configurato i simboli, non mostra il call stack decodificato, procedendo alla decodifica degli indirizzi che vediamo sul call stack,tramite i simboli di debugging, ho ottenuto quanto segue:

1:34:41.2317561 PM alg.exe 3384       CreateFile            C:\WINNT\security\templates\policies   SUCCESS              Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
-----------------------------------------------------------------------------------------------------
0 fltMgr.sys   fltMgr!FltpPerformPreCallbacks+0x2d4 0xf84b1944 C:\WINNT\System32\Drivers\fltMgr.sys
1 fltMgr.sys   fltMgr!FltpPassThroughInternal+0x32 0xf84b3352 C:\WINNT\System32\Drivers\fltMgr.sys
2 fltMgr.sys   fltMgr!FltpPassThrough+0x1df         0xf84b3c15 C:\WINNT\System32\Drivers\fltMgr.sys
3 fltMgr.sys   fltMgr!FltpDispatch+0xf3             0xf84b3ffb C:\WINNT\System32\Drivers\fltMgr.sys
4 ntkrnlpa.exe nt!IopfCallDriver+0x31               0x804ee003 C:\WINNT\system32\ntkrnlpa.exe
5 ntkrnlpa.exe nt!IopfCallDriver+0x31               0x804ee003 C:\WINNT\system32\ntkrnlpa.exe
6 ntkrnlpa.exe nt!NtQueryDirectoryFile+0x5d         0x8056e29f C:\WINNT\system32\ntkrnlpa.exe
7 ntkrnlpa.exe nt!KiFastCallEntry+0xf8              0x8053ca48 C:\WINNT\system32\ntkrnlpa.exe
8 ntkrnlpa.exe nt!ZwQueryDirectoryObject            0x804fdfc5 C:\WINNT\system32\ntkrnlpa.exe
9 ntkrnlpa.exe nt!CcPfPrefetchMetadata+0x76         0x806151cc C:\WINNT\system32\ntkrnlpa.exe
10 ntkrnlpa.exe nt!CcPfPrefetchScenario+0x6d         0x80615b9d C:\WINNT\system32\ntkrnlpa.exe
11 ntkrnlpa.exe nt!CcPfBeginAppLaunch+0x158          0x80615fd4 C:\WINNT\system32\ntkrnlpa.exe
12 ntkrnlpa.exe nt!PspUserThreadStartup+0xeb         0x805c4ca7 C:\WINNT\system32\ntkrnlpa.exe
13 ntkrnlpa.exe nt!KiThreadStartup+0x16              0x805411e2 C:\WINNT\system32\ntkrnlpa.exe

Analizzando le funzioni riportare sopra si identifica che il sistema di prefetching ha generato la scansione dei file e delle cartelle. Quando il processo ALG parte e crea il primo thread è eseguito in kernel mode il codice che esegue il prefetching.

Riporto il log che mostra questa sequenza:

13:34:40.1881511 alg.exe 3384 Process Start SUCCESS Parent PID: 1100
13:34:40.1966276 alg.exe 3384 Load Image C:\WINNT\system32\alg.exe SUCCESS Image Base: 0x1000000, Image Size: 0xd000
13:34:40.1967013 alg.exe 3384 Load Image C:\WINNT\System32\ntdll.dll SUCCESS Image Base: 0x7c910000, Image Size: 0xb6000
13:34:40.2724867 alg.exe 3384 CreateFile C:\WINNT\Prefetch\ALG.EXE-231187DC.pf SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: None, AllocationSize: n/a, OpenResult: Opened
13:34:40.2725487 alg.exe 3384 QueryStandardInformationFile C:\WINNT\Prefetch\ALG.EXE-231187DC.pf SUCCESS AllocationSize: 54,784, EndOfFile: 54,568, NumberOfLinks: 1, DeletePending: False, Directory: False
13:34:40.2725791 alg.exe 3384 ReadFile C:\WINNT\Prefetch\ALG.EXE-231187DC.pf SUCCESS Offset: 0, Length: 54,568
13:34:40.2728658 alg.exe 3384 CloseFile C:\WINNT\Prefetch\ALG.EXE-231187DC.pf SUCCESS
13:34:40.5168152 alg.exe 3384 CreateFile C:\ SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened

Come potete vedere nel log il processo ALG.exe legge il file alg.exe.<hashcode>.pf per determinare quali cartelle e file caricarsi in memoria durante il prefetching. In questo caso specifico ho riscontrato una dimensione notevole del file alg.exe.<hashcode>.pf (54K) che rivela come il file contenga notevoli cartelle e file da caricare e sicuramente anche il path C:\WINNT\SECURITY\TEMPLATES\POLICIES.

Per comprendere come mai il file alg.exe.<hashcode>.pf contenga cosi tante cartelle e file ho effettuato un test notando che eseguendo un processo qualsiasi, nel nostro caso la calcolatrice, durante la scansione dell’Antivirus, il file Calc.exe.<hashcode>.pg generato è di 60k mentre normalmente è di 10-15k.

Causa

Durante l’aggiornamento del file alg.exe.<hashcode>.pf, l’antivirus o qualsiasi altra applicazione esegue la scansione del sistema accedendo tutti i file e generando un file *.pf di grosse dimensione. Quando il servizio ALG.exe è avviato leggerà, durante il prefetching, il file alg.exe.<hashcode>.pf che contiene tutti i file e cartelle di sistema e anche il file C:\WINNT\security\templates\policies\tmpgptfl.inf

Soluzione

Individuare il software che fa la scansione di tutti i file anche se molto probabilmente si tratta dell’Antivirus. Configurare questa applicazione per non accedere ai file sotto C:\WINNT\SECURITY\TEMPLATES\POLICIES. Nel nostro caso troviamo prima dell’evento 1001 un evento generato dal processo ntrtscan.exe (Trend Micro OfficeScan Real-time Scan Service) che conferma che la causa è l’antivirus.

Description:         Trend Micro OfficeScan Real-time Scan Service (32-bit)
Company:             Trend Micro Inc.
Name:   ntrtscan.exe
Version: 8.00.0000.1189
Path:       C:\Programmi\Trend Micro\OfficeScan Client\ntrtscan.exe
Command Line: "C:\Programmi\Trend Micro\OfficeScan Client\ntrtscan.exe"
PID:        800
Parent PID:           1100
Session ID:           0
User:      NT AUTHORITY\SYSTEM
Auth ID: 00000000:000003e7
Architecture:         32-bit
Virtualized:            n/a
Integrity: n/a
Started: 12/16/2008 1:33:57 PM
Ended:   (Running)
Modules:
NTRtScan.exe     0x400000             0xd8000                C:\Programmi\Trend Micro\OfficeScan Client\NTRtScan.exe
Date & Time:        12/16/2008 1:34:42 PM
Event Class:        Registry
Operation:            RegSetValue
Result: SUCCESS
Path:      HKLM\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion\Misc.\LastScannedFileName
TID:        868
Duration:              0.0000277
Type:      REG_SZ
Length: 101
Data:      C:\WINNT\SECURITY\TEMPLATES\POLICIES\TMPGPTFL.INF

L’evento sopra mostra che l’antivirus verifica i file TMPGPTFL.INF infatti il servizio ha impostato la chiave LastScannedFileName con il valore C:\WINNT\SECURITY\TEMPLATES\POLICIES\TMPGPTFL.INF.

Per verificare velocemente se siete in questa condizione potete provare a disabilitare il prefetching in modo da evitare il comportamento descritto sopra.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters
Name: EnablePrefetcher
Type: REG_DWORD
Value: 0

The EnablePrefetcher key has the following values:

0 = Disabled
1 = Application launch prefetching enabled
2 = Boot prefetching enabled
3 = Application launch and boot enabled

To disable Prefetch, set the value to 0.

Se il problema si risolve con il prefetching disabilitato avete una conferma alla analisi.

In caso affermativo dovrete lavorare con il supporto dell’Applicativo per configurare e applicare l’exclusion dell’antivirus per la cartella C:\WINNT\SECURITY\TEMPLATES\POLICIES

Matteo Belloni
Support Escalation Engineer
Microsoft Enterprise Platform Support

Restricted Group – Funzionalità e Applicazione

itentblg — Mon, 13 Apr 2009 02:00:00 GMT

I Restricted Group permettono agli amministratori di definire e gestire i gruppi locali su server e computer del dominio.
L’esempio classico è l’introduzione di un gruppo di amministratori nel gruppo Administrators locale.

Il processo per l’applicazione dei Restricted Group ai vari computer avviene tramite l’applicazione delle Group Policy:

Il client richiede al Domain Controller la lista delle Group Policy da applicare al computer.
Il Domain Controller risponde con la lista delle Group Policy da applicare.
La lista è processata e, per ogni policy nella SYSVOL, è copiato il file GptTmpl.inf nel file tmpgptfl.inf locale nella cartella C:\Windows\Security\Templates\Policies.
Dopo la copia, il file tmpgptfl.inf è aperto e modificato inserendo due righe (GPOPath… e DSPath…) che riportano l’informazione della policy da dove è stato copiato il file e successivamente è salvato nel formato gpt0000X.dom/inf
Per ogni file GptTmpl.inf nelle Group Policy troviamo un file in locale: gpt00000.dom, gpt00001.dom, gpt0000X2inf.
Un esempio della cartella C:\Windows\Security\Templates\Policies
Successivamente i file sono letti e le policy applicate. Per quanto riguarda i Restricted Group è letta la configurazione sotto [Group Membership].
Prendendo l’esempio sopra troviamo giustamente i due SID del gruppo GruppoAmmComputer e dell’utente Mbelloni
Per controllare che la policy sia applicata correttamente si può analizzare il winlogon.log sotto C:\Windows\Security\Logs.
Nel nostro esempio sono stati rimossi i gruppi e utenti presenti ed è stato aggiunto l’utente Mbelloni
Successivamente è stata modificata la Group Policy aggiungendo il gruppo “GruppoAmmComputer” nei Restricted Group

Questo è il log successivo all’applicazione delle GPO dopo la modifica:
L’evento SceCli 1704 segnala che la policy è stata applicata con successo senza errori.

Maggiori informazioni sono disponibili nel seguente articolo:
MSDN - Restricted Groups

Matteo Belloni
Support Escalation Engineer
Microsoft Enterprise Platform Support

Group Policy – Computer Configuration e User Configuration

itentblg — Mon, 06 Apr 2009 02:00:00 GMT

Ciao a tutti!

La creazione di una policy a volte non è cosa semplice, e una volta creata, potrebbe non essere nemmeno semplice decidere dove collegarla.

Ogni modello di policy definisce due sezioni:

Computer Configuration = Policy per le impostazioni computer
User Configuration = Policy per le impostazioni utente

Alla partenza del computer sono applicate solo le impostazioni computer delle policy che interessano il computer account.
Successivamente al logon dell'utente verranno applicate solo le impostazioni utenti delle policy che interessano l'account utente.
Per i dettagli su come sono scelte le policy vi rimando al mio post "Group Policy: Applicazione e verifica tramite UserEnv.log".

Questo per spiegare che quando si definisce una policy che contiene impostazione per un oggetto, Computer o User, la policy deve essere collegata all'unità organizzativa dove l'oggetto risiede o lungo il percorso che lo contiene.
E' facile confondersi creando magari una policy con alcune impostazioni computer e poi collegare la policy ad una unità organizzativa dove c'è solo l'utente.

Il risultato è che l'utente a cui è collegata la policy, non ha applicate le impostazioni computer specificate.
In pratica: non si possono applicare ad un computer le impostazioni computer di una policy collegata ad una unità organizzativa dove c'è solo l'utente.

Perché?

Beh... semplicemente perché dato che le policy computer sono applicate prima che un utente effettui il logon, non è possibile sapere a priori quale utente userà il computer, e quindi leggere le sue policy!

Risulta invece realizzabile il contrario ovvero è possibile che all'utente siano applicate le policy collegate all'unità organizzativa dove risiede solo il computer account.

Questa funzionalità si chiama "Group Policy LoopBack".

Essa imposta la logica di raccolta delle policy assegnate all'utente in maniera differente.
E’ possibile specificare se le impostazioni utente delle policy indicate nell'unità organizzativa del computer dovranno:

Unirsi, quindi vengono raccolte sia le policy nell'unità organizzativa del computer che quelle nell'unità organizzativa dell'utente, o
Sostituirsi, quindi solo le policy contenute nell'unità organizzativa del computer

a quelle contenute nell'unità organizzativa dove risiede l'utente.

Maggiori informazioni sono disponibili nel seguente articolo:
KB 231287 - Loopback processing of Group Policy

Alla prossima!

Domenico Costa
Senior Support Engineer
Microsoft Enterprise Platform Support

Group Policy – Applicazione e verifica tramite UserEnv.log

itentblg — Mon, 30 Mar 2009 02:00:00 GMT

Ciao a tutti!

Eccoci al successivo appuntamento con il file "UserEnv.Log".
In questo post andremo a verificare come vengono lette, scelte e applicate le Group Policy ad un utente.

Prima cosa: ricordatevi di abilitare il log UserEnv.

Nel registry bisogna impostare:

Chiave: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Nome: UserEnvDebugLevel
Tipo: REG_DWORD
Valore: 10002 (Hex)

il riavvio non è necessario ma vi permette di partire con dei riferimenti "orari" più gestibili.

Con i client XP è preferibile disabilitare il "Fast Logon" in modo da consentire l'applicazione delle policy al logon dell'utente.

Per farlo è necessario impostare tramite policy (locale o di dominio) questo parametro su "Enabled":

Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon

e questo lo consiglio in ogni caso per verificare se un problema con l'applicazione delle policy non sia solo causato dalla rete.

Ora partiamo con le verifiche sul log dove analizzeremo la parte user per semplificare, dato che per la parte computer è tutta identica...

Identificarne l'inizio è semplice, il log ci viene in aiuto con:

USERENV(278.44c) 11:45:26:800 ProcessGPOs:
USERENV(278.44c) 11:45:26:800 ProcessGPOs:
USERENV(278.44c) 11:45:26:800 ProcessGPOs: Starting user Group Policy (Async forground|Background) processing...
USERENV(278.44c) 11:45:26:800 ProcessGPOs:
USERENV(278.44c) 11:45:26:800 ProcessGPOs:

In queste prime linee si vede come l'applicazione delle GPOs sia avvenuta in modalità Asincrona (Async forground -> Fast Logon di XP) o Sincrona (Background -> Fast Logon disabilitato)

Successivamente il sistema effettua un controllo sulla velocità della rete in modo da poter distinguere se il dialogo con il DC è su una rete veloce o lenta.
Per i dettagli vi invito a leggere quanto indcato nel mio post “Group Policy: Slow Link Detection”

Poi calcola la posizione dell'utente all'interno delle varie unità organizzative (OU in Active Directory Users and Computers) ed il DC da cui prendere le policy:

USERENV(278.44c) 11:45:26:815 ProcessGPOs: User name is: CN=Utente,OU=Admin,OU=Office,OU=Reparto,DC=Dominio,DC=it, Domain name is: DOMINIO
USERENV(278.44c) 11:45:26:815 ProcessGPOs: Domain controller is: <\\DC02.dominio.it> Domain DN is dominio.it

Verifica lo stato locale delle estensioni per le policy in modo da segnare che cosa è stato applicato fino ad ora:

USERENV(278.44c) 11:45:26:831 ReadExtStatus: Reading Previous Status for extension {35378EAC-683F-11D2-A89A-00C04FBBCFA2}
USERENV(278.44c) 11:45:26:831 ReadExtStatus: Reading Previous Status for extension {0ACDD40C-75AC-47ab-BAA0-BF6DE7E7FE63}
USERENV(278.44c) 11:45:26:831 ReadExtStatus: Reading Previous Status for extension {25537BA6-77A8-11D2-9B6C-0000F8080861}
.
.
.
USERENV(278.44c) 11:45:26:831 ReadStatus: Read Extension's Previous status successfully.

L'elenco delle estensioni base e la loro specialità sono descritti nel seguente articolo:

KB 216357 - Identifying Group Policy Client-Side Extensions

Tutte le estensioni registrate sul computer sono reperibile nel registro in:

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

Questo stato verrà successivamente confrontato con lo stato delle policy in modo da non dover applicare ogni volta le stesse impostazioni, velocizzando ulteriormente l'applicazione delle policy.

Inizia quindi la fase di raccolta di tutte le policy seguendo un ordine ben preciso, in base all'unità organizzativa di appartenenza.

USERENV(278.44c) 11:45:26:847 SearchDSObject: Searching <OU=Admin,OU=Office,OU=Reparto,DC=Dominio,DC=it>

Se in un OU non ci sono policy troveremo:

USERENV(278.44c) 11:45:26:847 SearchDSObject: No GPO(s) for this object.

altrimenti:

USERENV(278.44c) 11:45:26:847 SearchDSObject: Found GPO(s): <[LDAP://cn={9AE7BFE1-D75E-42C2-B882-2BA60429EE59},cn=policies,cn=system,DC=Dominio,DC=it;0][LDAP://cn={DFB99C69-78B2-42F8-AF08-EAD9A86300BC},cn=policies,cn=system,DC=Domino,DC=it;0][LDAP://cn={EEF0C2F8-7A3D-49F5-8E5D-6D411965F41C},cn=policies,cn=system,DC=Dominio,DC=it;0][LDAP://cn={55F90D04-552E-4DB9-8FA8-942668047EBC},cn=policies,cn=system,DC=Dominio,DC=it;0]>
USERENV(278.44c) 11:45:26:847 ProcessGPO: ==============================
USERENV(278.44c) 11:45:26:847 ProcessGPO: Deferring search for <LDAP://cn={9AE7BFE1-D75E-42C2-B882-2BA60429EE59},cn=policies,cn=system,DC=Dominio,DC=it>
USERENV(278.44c) 11:45:26:847 ProcessGPO: ==============================
USERENV(278.44c) 11:45:26:847 ProcessGPO: Deferring search for <LDAP://cn={DFB99C69-78B2-42F8-AF08-EAD9A86300BC},cn=policies,cn=system,DC=Dominio,DC=it>
USERENV(278.44c) 11:45:26:847 ProcessGPO: ==============================
USERENV(278.44c) 11:45:26:847 ProcessGPO: Deferring search for <LDAP://cn={EEF0C2F8-7A3D-49F5-8E5D-6D411965F41C},cn=policies,cn=system,DC=Dominio,DC=it>
USERENV(278.44c) 11:45:26:847 ProcessGPO: ==============================
USERENV(278.44c) 11:45:26:847 ProcessGPO: Deferring search for <LDAP://cn={55F90D04-552E-4DB9-8FA8-942668047EBC},cn=policies,cn=system,DC=Dominio,DC=it>

e via di seguito:

USERENV(278.44c) 11:45:26:847 SearchDSObject: Searching <OU=Office,DC=Dominio,DC=it>
.
.
.
USERENV(278.44c) 11:45:26:847 SearchDSObject: Searching <DC=Dominio,DC=it>
.
.
.

ed infine (se presenti) quelle del sito di appartenenza:

USERENV(278.44c) 11:45:26:862 SearchDSObject: Searching <CN=MILANO,CN=Sites,CN=Configuration,DC=Dominio,DC=it>

Avendo ora costruito l'elenco delle policy queste verranno applicate in ordine inverso, quindi si parte da quelle trovate nel sito, poi quelle all'origine del dominio e via via verso l'unità organizzativa dove risiede l'utente od il computer.

Per ogni policy da processare il sistema verifica se si ha l'accesso (security o filtri WMI), la versione, se è abilitata o disabilita e con quali estensioni.
Ecco un esempio:

USERENV(278.44c) 11:45:26:878 ProcessGPO: ==============================
USERENV(278.44c) 11:45:26:878 ProcessGPO: Searching <CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=Dominio,DC=it>
USERENV(278.44c) 11:45:26:878 ProcessGPO: User has access to this GPO.
USERENV(278.44c) 11:45:26:878 ProcessGPO: GPO passes the filter check.
USERENV(278.44c) 11:45:26:878 ProcessGPO: Found functionality version of: 2
USERENV(278.44c) 11:45:26:878 ProcessGPO: Found file system path of: <\\Dominio.it\sysvol\Dominio.it\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(278.44c) 11:45:26:893 ProcessGPO: Found common name of: <{31B2F340-016D-11D2-945F-00C04FB984F9}>
USERENV(278.44c) 11:45:26:893 ProcessGPO: Found display name of: <Default Domain Policy>
USERENV(278.44c) 11:45:26:893 ProcessGPO: Found user version of: GPC is 1, GPT is 1
USERENV(278.44c) 11:45:26:893 ProcessGPO: Found flags of: 0
USERENV(278.44c) 11:45:26:893 ProcessGPO: Found extensions: [{3060E8D0-7020-11D2-842D-00C04FA372D4}{3060E8CE-7020-11D2-842D-00C04FA372D4}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}]
USERENV(278.44c) 11:45:26:893 ProcessGPO: ==============================

Dopo aver processato le policy si passa a processare tutte le estensioni:

USERENV(278.44c) 11:45:26:924 ProcessGPOs: Processing extension Registro di sistema
USERENV(278.44c) 11:45:26:924 ReadStatus: Read Extension's Previous status successfully.
USERENV(278.44c) 11:45:26:924 CompareGPOLists: The lists are the same.
USERENV(278.44c) 11:45:26:940 ProcessGPOList: Entering for extension Registro di sistema
USERENV(278.44c) 11:45:26:940 UserPolicyCallback: Setting status UI to Applicazione del criterio Registro di sistema in corso...
USERENV(278.44c) 11:45:26:940 ProcessGPOList: No changes. CSE will not be passed in the IwbemServices intf ptr
USERENV(278.44c) 11:45:26:940 EnterCriticalPolicySectionEx: Entering with timeout 60000 and flags 0x2
USERENV(278.44c) 11:45:26:940 EnterCriticalPolicySectionEx: User critical section has been claimed. Handle = 0x6d8
USERENV(278.44c) 11:45:26:940 EnterCriticalPolicySectionEx: Leaving successfully.
USERENV(278.44c) 11:45:26:940 ResetPolicies: Entering.
USERENV(278.44c) 11:45:27:018 ProcessGPOList: Extension Registro di sistema status was not updated because there was no changes and no transition or rsop wasn't enabled
USERENV(278.44c) 11:45:27:018 ProcessGPOs: -----------------------
.
.
.
USERENV(278.44c) 11:45:27:034 ProcessGPOs: Processing extension Personalizzazione Internet Explorer
USERENV(278.44c) 11:45:27:034 ReadStatus: Read Extension's Previous status successfully.
USERENV(278.44c) 11:45:27:034 CompareGPOLists: The lists are the same.
USERENV(278.44c) 11:45:27:034 ProcessGPOList: Entering for extension Personalizzazione Internet Explorer
USERENV(278.44c) 11:45:27:034 UserPolicyCallback: Setting status UI to Applicazione del criterio Personalizzazione Internet Explorer in corso...
USERENV(278.44c) 11:45:27:034 ProcessGPOList: No changes. CSE will not be passed in the IwbemServices intf ptr
USERENV(278.44c) 11:45:27:734 UserPolicyCallback: Setting status UI to Applicazione delle impostazioni personali in corso...
USERENV(278.44c) 11:45:27:734 ProcessGPOList: Extension Personalizzazione Internet Explorer returned 0x0.
USERENV(278.44c) 11:45:27:734 ProcessGPOList: Extension Personalizzazione Internet Explorer status was not updated because there was no changes and no transition or rsop wasn't enabled
.
.
.

Ho messo queste 2 estensioni per far risaltare che durante queste fasi cambia la scritta a video (Setting status UI to...) prima di presentare il desktop all'utente.
Ed infine:

.
.
.
USERENV(278.44c) 11:45:27:750 ProcessGPOs: User Group Policy has been applied.

Di seguito vi riporto la documentazione ufficiale:

Alla prossima!

Domenico Costa
Senior Support Engineer
Microsoft Enterprise Platform Support

Group Policy – Slow Link Detection

itentblg — Mon, 16 Mar 2009 02:00:00 GMT

Ciao a tutti!

Può capitare che alcune impostazioni delle policy non siano applicate correttamente.
Eppure, spesso si pensa: ma se una parte viene eseguita perché l'altra è ignorata?

Ebbene, escludendo i problemi di allineamento dei Domain Controller o "problemi di terze parti", c'è un motivo prettamente tecnico e funzionale: la velocità della rete.

E’ in base alla banda di rete che il sistema decide se eseguire o meno le parti delle policy che utilizzano la rete in maniera più intensiva: pensate agli script o alla distribuzione di programmi.

Di default vengono sempre applicate:

Registry settings
Security policies
EFS recovery policy
IP security

ma se siamo in presenza di una rete lenta allora queste parti sono "ignorate":

Application Deployment
Scripts
Folder Redirection
Disk Quotas

Se volete modificare questo comportamento si deve creare una policy che definisca come comportarsi modificando le relative sezioni in:

Computer Configuration\Administrative Templates\System\Group Policy

Dove potete indicare per ogni "qualità" se queste impostazioni vanno applicate anche in caso di rete lenta e specificare se applicarle anche se non sono mai cambiate.

Tenete presente che la parte degli scripts riguarda solo logon e logoff per l'utente, gli script di startup/shutdown per la macchina non sono mai eseguiti in caso di rete lenta.

L'esito di una rete veloce è segnalato nel file UserEnv.Log come indicato di seguito:

USERENV(278.44c) 11:45:26:800 PingComputer: PingBufferSize set as 2048
USERENV(278.44c) 11:45:26:800 PingComputer: Adapter speed 1000000000 bps
USERENV(278.44c) 11:45:26:800 PingComputer: First time: 0
USERENV(278.44c) 11:45:26:800 PingComputer: Fast link. Exiting.

Se invece siamo in presenza di qualche latenza di rete potremmo vedere:

USERENV(5c4.85c) 10:36:57:796 PingComputer: Adapter speed 100000000 bps
USERENV(5c4.85c) 10:36:57:953 PingComputer: First time: 159
USERENV(5c4.85c) 10:36:58:000 PingComputer: Second time: 36
USERENV(5c4.85c) 10:36:58:000 PingComputer: Second time less than first time.
USERENV(5c4.85c) 10:36:58:031 PingComputer: First time: 28
USERENV(5c4.85c) 10:36:58:109 PingComputer: Second time: 71
USERENV(5c4.85c) 10:36:58:156 PingComputer: First time: 39
USERENV(5c4.85c) 10:36:58:234 PingComputer: Second time: 79
USERENV(5c4.85c) 10:36:58:250 PingComputer: Transfer rate: 780 Kbps Loop count: 2

La verifica della velocità della rete è misurata in base all'esito di alcuni ping e questa formula:

LinkSpeed=32000/ulTotal

ulTotal è dato dalla media arrotondata della differenza tra i ping, escluso se il primo è più grande del secondo.

Nel caso precedente abbiamo quindi:

ulToal = int((71-28) + (79-39)) / 2 = 83 / 2 = 41

Quindi la velocità è: 32000/41 = 780 Kbps

Confrontando il parametro "Transfer rate" con quanto è dettato dalle policy il sistema decide se la rete è veloce o lenta.

I parametri presi per il confronto sono indicati su:

Computer Configuration\Administrative Templates\System\Group Policy "Group Policy slow link detection"
User Configuration\Administrative Templates\System\Group Policy "Group Policy slow link detection"

Il valore è espresso in kbps e il valore di default è 500 kbps.

Per disabilitare il controllo è sufficiente impostare entrambi i valori a 0.

Una prima verifica è possibile anche con il seguente comando:

GPRESULT -V

nel testo visualizzato compare (per user e per computer):

Connected over a slow link?: No (oppure Yes...)

e l'impostazione della velocità di rete via policy:

Group Policy slow link threshold: 500 kbps

Di seguito vi riporto la documentazione ufficiale:

Alla prossima!!

Domenico Costa
Senior Support Engineer
Microsoft Enterprise Platform Support

Client Apple/Linux non riescono ad usare kerberos per connettersi ad una share su Windows 2008/Vista

itentblg — Wed, 12 Nov 2008 03:00:00 GMT

Questo problema è capitato ad un nostro cliente dopo aver aggiornato alcuni File Server a Windows 2008. I client Apple o Linux, dopo la migrazione del file server, non riescono ad usare kerberos per connettersi ad una share su Windows 2008/Vista mentre funziona con Windows2003/XP. Con Windows 2008/Vista vengono richieste le credenziali per autenticarsi in NTLM.

Analizzando le due trace di rete prese durante l'accesso alla share su Windows 2003/XP e su Windows 2008/Vista si può vedere che l'accesso al file share Windows 2003/XP funziona senza errori. Nella trace presa su Windows 2003/XP è presente nella SPNEGO il principal: fileserver$@DOMAINAME.LOCAL che poi viene usato dal client Apple/Linux per instaurare la sessione.

No.     Time                       Source                Destination           Protocol Info
15 2008-11-07 09:27:34.485849 192.168.2.244         10.62.1.99            SMB      Negotiate Protocol Response
    SMB (Server Message Block Protocol)
        SMB Header
        Negotiate Protocol Response (0x72)
        Security Blob: 606606062B0601050502A05C305AA030302E06092A864882...
            GSS-API Generic Security Service Application Program Interface
                OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
                SPNEGO
                    negTokenInit
                        mechTypes: 4 items
                            Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                            Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                            Item: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User)
                            Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                        mechListMIC: 3024A0221B20737739303030667330312440504F50534F44...
                      principal: fileserver$@DOMAINAME.LOCAL

In Windows 2008/ Vista per design non è restituito questo valore e, infatti, nella trace troviamo principal: not_defined_in_RFC4178@please_ignore:

No.     Time                       Source                Destination           Protocol Info
31 2008-11-06 12:21:13.418875 192.168.2.247         10.62.1.99            SMB      Negotiate Protocol Response
        Security Blob: 606A06062B0601050502A060305EA030302E06092A864882...
            GSS-API Generic Security Service Application Program Interface
        OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
                SPNEGO
                    negTokenInit
                        mechTypes: 4 items
                            Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
                            Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
                            Item: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User)
                            Item: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                       mechListMIC: 3028A0261B246E6F745F646566696E65645F696E5F524643...
                       principal: not_defined_in_RFC4178@please_ignore

Questo campo non è definito nella RFC4178 e per questo non è indispensabile utilizzarlo e sopratutto è più sicuro non usarlo. La parte SMB di Apple/Linux dovrebbe essere in grado di gestire questa situazione.

Da una breve ricerca fatta in internet ho scoperto che questa condizione viene gestita dai client Apple e Linux:

* As such, in early versions of Windows SPNEGO, there were some "extra" fields added to the negTokenInit
* message which are being deprecated in Windows 2008 Server, and eventually service packs for older
* platforms. The most significant of these fields is the principal name - there is really no place in
* either standard which allows the return of a principal in negTokenInit messages. This is being corrected
* in Windows 2008 server by continuing to add the field, but instead of a "real" principal, it now contains
* "not_defined_in_RFC4178 at please_ignore".
*
* From a security standpoint, allowing the server to specify its service principal is a "bad idea" - So we
* need to handle this case. If the SPN is "not_defined_in_RFC4178 at please_ignore" then we will replace it
* with the host name. In the furture we may want to check for an empty SPN also.
*
* Make sure we didn't get an empty SPN.
*/

         if (((strncasecmp ((char *)rq.spn, "cifs/", sizeof(rq.spn))) == 0) ||
                 ((strncasecmp ((char *)rq.spn, WIN2008_SPN_PLEASE_IGNORE_REALM, sizeof(rq.spn))) == 0)) {
                 /* We need to add "cifs/ instance part" */
                 strlcpy((char *)rq.spn, "cifs/", sizeof(rq.spn));
                 /* Now the host name without a realm */

Reference: http://www.opensource.apple.com/darwinsource/10.5/smb-344/lib/smb/ctx.c

Considerando che

#define WIN2008_SPN_PLEASE_IGNORE_REALM "cifs/not_defined_in_RFC4178@please_ignore"Reference:

Reference: http://www.opensource.apple.com/darwinsource/10.5/smb-344/kernel/netsmb/smb_dev.h

Per risolvere questo problema bisogna aggiornare il cliente Apple/Linux. Questo problema può presentarsi anche con le NAS con sistema operativo Linux, in questo caso occorre aggiornare il firmware con l'ultima versione che gestisce la condizione descritta sopra.

Matteo Belloni
Support Escalation Engineer
Microsoft Enterprise Platforms Support

Analisi performance autenticazione NTLM

itentblg — Wed, 17 Sep 2008 17:53:00 GMT

Ciao,

Questo è il mio primo post su questo blog, cercherò con questo e con i prossimi post di spiegare come fare troubleshooting dei componenti di Active Directory ( Group Policy, Kerberos, NTLM … ).

Per iniziare ho scelto un bel problema di autenticazione. Molte applicazioni ancora oggi usano NTLM come protocollo di autenticazione. In alcuni casi è l'applicazione che richiede NTLM mentre in altri casi è una particolare configurazione, un esempio sono le trust tra domini, che forzano l'uso del protocollo di autenticazione NTLM. L'utilizzo di questo protocollo di autenticazione può causare un problema di performance che può arrivare fino blocco del servizio. Tipicamente il problema si manifesta con una continua richiesta di credenziali. Ho riscontrato questo problema con Outlook, Internet Explorer, Sharepoint ma è possibile che si presenti anche con altri software.

Per spiegare questo problema ipotizzerò di avere la seguente infrastruttura. Ipotizziamo quindi l'utilizzo di Internet Explorer con ISA server come Proxy che autentica gli utenti tramite un Domain Controller.

Internet Explorer, fino alla versione 7, non supporta l'autenticazione kerberos attraverso proxy server ( 321728 ) e per questo utilizza solo NTLM. In grosse infrastrutture, ISA server deve continuamente richiedere la validazione delle credenziali per ogni pagina http, generando un intenso volume di richieste di autenticazione NTLM verso il DC con cui ha instaurato il secure channel ( DC01 ). Qui sotto un esempio di come funziona l'autenticazione NTLM nello scenario sopra.

In questa condizione si crea un collo di bottiglia verso il DC01 con cui ISA01 server ha instaurato il secure channel. ISA01 contunua ad accodare le richieste di autenticazione fino a qaundo DC01 è carico e non riesce a rispondere. Le richieste sono tolte dalla coda se processate con successo o se entro 45 secondi non si libera uno slot Api per passare la richiesta al DC. In questo caso avremmo un errore come questo nel netlogon.log.

4430 09/15 18:27:39 [CRITICAL] DOMAIN: NlAllocateClientApi timed out: 0 258

4431 09/15 18:27:39 [CRITICAL] DOMAIN: NlpUserValidateHigher: Can't allocate Client API slot.

4432 09/15 18:27:39 [LOGON] SamLogon: Network logon of DOMAIN\USER from ISA01 Returns 0xC000005E

L’errore 0xC000005E segnala, guardacaso, che il DC non è raggiungibile.

0xC000005E --> STATUS_NO_LOGON_SERVERS --> There are currently no logon servers available to service the logon request.

Come default i server hanno configurato l’uso di uno slot per secure channel, quindi è possibile inviare una richiesta alla volta. Per aumentare il numero di richieste che il server/DC può inviare al DC è stata creata una chiave di registro chiamata MaxConcurrentApi.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Value Name: MaxConcurrentApi
Data Type: REG_DWORD
Value: between 0 and 10

Un disegno è meglio di mille parole .

In aggiunta, in una infrastruttura come quella sopra ( fig 1 ) può accadere che entrambi i server ISA usino lo stesso DC con cui hanno instaurato il secure channel dall'avvio, quindi non si ha un bilanciamento del carico su i due DC. Una soluazione è la creazione dei secure channel tra DC e ISA server in un rapporto 1 a 1 o 1 a 2 in modo da bilanciare il carico su tutti i DC presenti. Nel nostro caso avremmo questa situazione:

O se avessi 4 Isa Servee e 2 DC:

Il tool NLTEST con l’opzione SC_RESET permette di forzare il secure channel verso un DC specificato:

Un altro caso interessante per queste problematiche è la presenza di trust con domini in sedi remote collegate con link lenti. Un esempio:

In questo caso il rallentamento non è legato alle prestazioni del DC01 ma dal rallentamento nella comunicazione tra DC01 e DCA. I passaggi sono i seguenti:

Dal PC parte una richiesta per il Proxy
ISA respinge e richiede le credenziali avendo la policy che richiede l'autenticazione
Il PC rinvia la richiesta del punto 1 con le credenziali.
Il server ISA deve autenticare l'utente PIPPO\USER01 e per questo chiede la verifica delle credenziali al DC con cui ha il Secure channel attivo. Il DC01, considerando che l'utente non è del suo dominio. verifica tra le trust se è presente una trust con il dominio PIPPO. Nel nostro caso il dominio PLUTO ha la trust con PIPPO e il DC01 ha il secure channel con DCA.
DC01 gira la richiesta a DCA che ha in gestione l'utente PIPPO\USER01
DCA ha controllato le credenziali e risponde con "success"
DC01 risponde a ISA01 che le credenziali sono corrette
ISA01 risponde al PC con la pagina richiesta al punto 3.

Le richieste di autenticazione tra DCA e DC1 saranno processate più lentamente, essendoci una linea lenta tra PIPPO e PLUTO, e per questo su DC01 e ISA01 inizzeranno ad accodarsi le richieste di autenticazione. La soluzione più semplice è mettere un DC del dominio PIPPO nella stessa rete di DC01. Lo stessa situazione si può avere se ISA01 instaura il secure channel con un DC in un sito remoto collegato anchesso da una linea lenta.

Con la fix 928576 sono stati integrati dei nuovi performance counter per il netlogon che permettono di monitorare gli API SLOT e le code.

L’immagine sopra mosta che alle 11:36 i 5 slot erano utilizzati completamente e 10 richieste erano in coda ad aspettare. Le 10 richieste non sono andate in timeout, infatti il counter “Semaphone TimeOuts” è rimasto a zero.

Spero di essere stato chiaro in questo mio primo post. Un saluto e arrivederci al prossimo post.

Matteo Belloni
Support Escalation Engineer
Microsoft Enterprise Platforms Support