Introduzione
Questo documento descrive l'autenticazione NT LAN Manager (NTLM) a livello di pacchetto.
Come dovrebbe essere l'autenticazione NTLM a livello di pacchetto?
Un'acquisizione di pacchetti per seguire questo articolo può essere scaricata qui: https://supportforums.cisco.com/sites/default/files/attachments/document/ntlm_auth.zip
IP client: 10.122.142.190
IP WSA: 10.12.144.182
Numero e dettagli del pacchetto
#4 Il client invia una richiesta GET al proxy.
#7 Il proxy invia una 407. Ciò significa che il proxy non consente il traffico a causa di una mancanza di autenticazione corretta. Se si esaminano le intestazioni HTTP in questa risposta, verrà visualizzato il messaggio "Proxy-authentication: NTLM". In questo modo il client viene informato che un metodo di autenticazione accettabile è NTLM. Analogamente, se è presente l'intestazione "Proxy-authentication: Basic", il proxy indica al client che le credenziali di base sono accettabili. Se sono presenti entrambe le intestazioni (comune), il client decide quale metodo di autenticazione utilizzare.
Da notare che l'intestazione di autenticazione è "Proxy-authentication:". Questo perché la connessione nell'acquisizione utilizza un proxy di inoltro esplicito. Se si trattasse di una distribuzione proxy trasparente, il codice di risposta sarebbe 401 anziché 407 e le intestazioni sarebbero "www-authentication:" anziché "proxy-authentication:".
#8 Il proxy INVIA questo socket TCP. Si tratta di un comportamento corretto e normale.
#15 Su un nuovo socket TCP, il client esegue un'altra richiesta GET. In questo caso, si noti che il metodo GET contiene l'intestazione HTTP "proxy-authorization:". Contiene una stringa codificata contenente dettagli relativi all'utente o al dominio.
Se si espande Autorizzazione-Proxy > NTLMSSP, le informazioni decodificate verranno inviate nei dati NTLM. In "Tipo di messaggio NTLM", si noterà che è "NTLMSSP_NEGOTIATE". Questo è il primo passaggio dell'handshake NTLM a tre vie.
#17 Il proxy risponde con altri 407. È presente un'altra intestazione "proxy-authentication". Questa volta contiene una stringa di richiesta NTLM. Se si espande ulteriormente, il tipo di messaggio NTLM sarà "NTLMSSP_CHALLENGE". Questo è il secondo passaggio dell'handshake NTLM a tre vie.
Nell'autenticazione NTLM, il controller di dominio di Windows invia una stringa di richiesta al client. Il client applica quindi un algoritmo alla richiesta di verifica NTLM che determina la password dell'utente nel processo. In questo modo, il controller di dominio può verificare che il client conosca la password corretta senza inviare la password da un punto all'altro della linea. Questo è molto più sicuro delle credenziali di base, in cui la password viene inviata in testo normale per tutti i dispositivi di sniffing.
#18 Il client invia un GET finale. Notare che questo GET si trova sullo STESSO socket TCP su cui si sono verificati la negoziazione NTLM e la richiesta NTLM. Si tratta di un aspetto fondamentale per il processo NTLM. L'intero handshake deve essere eseguito sullo stesso socket TCP. In caso contrario, l'autenticazione non sarà valida.
In questa richiesta il client invia al proxy la richiesta NTLM modificata (risposta NTLM). Questo è il passaggio finale dell'handshake NTLM a tre vie.
#21 Il proxy invia una risposta HTTP. Questo significa che il proxy ha accettato le credenziali e ha deciso di rendere disponibile il contenuto.
Feedback