Analisi performance autenticazione NTLM
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 soluzione è 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 mostra che prima delle 15.00 i 5 slot erano utilizzati completamente e un alto numero di richieste erano in coda ad aspettare. Molte richieste sono andate in timeout, infatti il counter “Semaphone TimeOuts” è saltato da zero a 30.
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