Supporto Tecnico Enterprise : Matteo Belloni

Kerberos delegation – Capire e configurare correttamente

itentblg — Mon, 28 Sep 2009 02:00:00 GMT

Sempre più spesso sono coinvolto nella risoluzione di problemi di configurazione di Kerberos in infrastrutture con più server dove le credenziali devono essere “delegate” dai front-end server ai back-end server.

Ho pensato di scrivere questo post dove riportare tutti i punti per configurare i parametri usati da kerberos per funzionare correttamente.

Come funziona

La configurazione su mi trovo a lavorare sempre più spesso prevede uno o più server IIS e un back-end server con un SQL server o un File server. Per comprendere meglio i passi di configurazione è utile spiegare come funziona il meccanismo che permette di arrivare al server di back-end con le credenziali del client.

Il client passa le credenziali al Domain Controller/KDC che ritorna il TGT al client
Il client usa il TGT per richiedere il Service Ticket per connettersi al server IIS
Il client si connette al server IIS passandogli il TGT e il service Ticket
Il Server IIS usa il TGT passato dal client per richiedere il service ticket per accedere al Server SQL
Il Server IIS si connette a Server SQL usando le credenziali dell’utente loggato al client

Configurazione

Per permettere ad una sistema come quello rappresentato nell’immagine sopra di lavorare correttamente è necessario configurare diversi parametri nei diversi software utilizzati (IIS, IE, AD..)

Internet Explorer

Configurare FQDN del sito che verrà utilizzato nel “Local Intranet Zone” di Internet Explorer. Nel nostro esempio useremo l’FQDN blogs.technet.com

Abilitare l’opzione “Enable Windows Integrated Authentication” sotto “Internet Options->Advanced->Security-> Advanced”

Abilitare l’opzione “Automatic logon with current username and password" o "Automatic Logon only in Intranet Zone" sotto “Internet Options->Advanced->Security-> Custom level”

IIS

Eseguire il seguente comando per verificare la configurazione di IIS e assicurarsi che l’output mostri “Negotiate, NTLM”.

<system drive>\inetpub\adminscripts\cscript adsutil.vbs get w3svc/ WebSite /root/NTAuthenticationProviders

Bisogna sostituire WebSite con il numero del sito in IIS che sarà usato.

Configurare IIS con la sola “Windows Integrated Authentication”

Se si usano più IIS server è necessario configurare l’AppPool di entrambi i server IIS con un utente di dominio creato appositamente ( esempio: AppPoolUser). Nel caso di un solo server IIS si può lasciare l’utente Local System.

Active Directory

L’account AppPoolUser deve essere configurato con l’opzione per permettere la “delega”.

Bisogna precisare la differenza tra “Kerberos Delegation” (immagine sopra a sx) e “Contrained Delegation” (immagine sopra a dx). La“Kerberos Delegation” permette al primo server (front-end) di richiedere a nome del client il ticker kerberos per accedere al secondo server (back-end). La “Constrained Delegation” a differenza della “Kerberos Delegation” non è supportata su tutti i sistemi e per funzionare richiede che il “domain functional level” sia impostato a 2003. Con la “Constrained Delegation” l’amministratore può configurare un utente per richiedere il ticker kerberos solo per specifici servizi. Nell’esempio sopra abbiamo specificato solo il server SQLServer con la porta 1433 e il service principal name MSSQLSvc.

L’account AppPoolUser deve essere aggiunto al gruppo IIS_WPG group su ogni IIS server.
Registrare l’SPN per l’FQDN blogs.techenet.com all’account AppPoolUser

Setspn –A http/<FQDN> <Domain user account>

Setspn –A http/<Netbios Name> <Domain user account>

Verificare che SQL abbia registrato durante l’installazione l’SPN nell’oggetto computer del server SQLServer

Setspn –L <Domain user account>

Configurare i seguenti diritti per l’account AppPoolUser su tutti i server IIS tramite le Local Policy o tramite una GPO

Troubleshooting

Se avete seguito i passi sopra il sistema dovrebbe usare Kerberos senza problemi. Nel caso ci fossero problemi vi suggerisco di scaricare questa applicazione ASP.NET dal sito:

http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/delegconfig-delegation-configuration-reporting-tool.aspx

Dopo aver scaricato l’applicazione create un nuovo sito usando i file scaricati. A questo punto puntando sul nuovo sito avrete un report completo con indicato gli errori e la procedura per risolverli. Vi riporto un esempio di report nel caso tutto sia configurato correttamente:

Se l’uso dell’applicazione Delegconfig non è sufficiente vi riporto una lista di azioni da fare per identificare la causa del problema:

Pulire la cache kerberos con il tool Klist.exe o Kerbtray.exe sul client e su tutti i server. In questo modo tutti i ticket kerberos verranno richiesti al KDC utilizzando la nuova configurazione
Aumentare il livello del log di Kerberos (KB262177). Con l’attivazione di questo log verranno generati degli eventi in caso di errori nel registro degli eventi di sistema.
Collezionare una trace di rete sul client, il front-end e il back-end e analizzare il traffico kerberos sulla porta 88. Con l’analisi della trace di rete siete in grado di capire se ci sono problemi nella configurazione degli SPN. Gli errori kerberos tipici sono:

KDC_ERR_S_PRINCIPAL_UNKNOWN= Non è stato registrato l’spn
KDC_ERR_PRINCIPAL_NOT_UNIQUE= Ci sono più oggetti che hanno registrato lo stesso SPN. Per identificare gli oggetti si possono usare diversi tool. Avendo un server Windows 2008 si può sfruttare una nuova funzionalità del tool SetSpn:

http://blogs.msdn.com/saurabh_singh/archive/2009/01/09/new-features-in-setspn-exe-on-windows-server-2008.aspx

Altrimenti bisogna utilizzare il tool LDIFDE con la seguente sintassi:Syntax:

ldifde -f <filename> -d "<dc=domain-netbiosname,dc=primary-domain>" -l serviceprincipalname -r "(serviceprincipalname=<serviceprincipalname-to-check-for-duplicates>)" -p subtree

For example, if the domain name is test.abcd.com and the site URL is http//test.abcd.com command should be as shown below:

ldifde –f C:\log.txt -d "dc=test, dc=abcd, dc=com"-l serviceprincipalname –r "(serviceprinicpalname=http/test.abcd.com)" -p subtree

Se non volete usare il tool LDIFDE potete usare lo script contenuto nell’articolo 929650

Articoli utili

Kerberos on IIS, http://support.microsoft.com/kb/326985 , is a good resource that goes discusses using IIS for the front end server.
Kerberos on 2000 server clusters, http://support.microsoft.com/kb/235529
Kerberos in SQL Server, http://support.microsoft.com/kb/319723
Kerberos with network load balancing, http://support.microsoft.com/kb/325608
Kerberos with SMS 2003, http://support.microsoft.com/kb/326985

Documenti utili

Kerberos RFC - http://www.ietf.org/rfc/rfc1510.txt
Microsoft Kerberos Tech Ref - http://technet2.microsoft.com/windowsserver/en/library/b748fb3f-dbf0-4b01-9b22-be14a8b4ae101033.mspx?mfr=true
Kerberos Double Hop webcast - http://support.microsoft.com/kb/887682
Constrained Delegation -http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/constdel.mspx
Protocol Transition - http://technet2.microsoft.com/windowsserver/en/library/4c8b5ac7-368b-45b9-91d7-1ae7c5e0da311033.mspx?mfr=true
How the Kerberos Version 5 Authentication Protocol Works - http://technet2.microsoft.com/windowsserver/en/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx

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

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