Introdução
Este documento descreve a autenticação do NT LAN Manager (NTLM) no nível do pacote.
Como deve ser a autenticação NTLM no nível do pacote?
Uma captura de pacote para seguir este artigo pode ser baixada aqui: https://supportforums.cisco.com/sites/default/files/attachments/document/ntlm_auth.zip
IP do cliente: 10.122.142.190
IP WSA: 10.122.144.182
Número e detalhes do pacote
#4 O cliente envia uma solicitação GET ao proxy.
#7 O proxy retorna um 407. Isso significa que o proxy não permite o tráfego devido à falta de autenticação adequada. Se você observar os cabeçalhos HTTP nesta resposta, verá um "Proxy-authenticate: NTLM". Isso informa ao cliente que um método aceitável de autenticação é o NTLM. Da mesma forma, se o cabeçalho "Proxy-authenticate: Basic" estiver presente, o proxy informará ao cliente que as credenciais básicas são aceitáveis. Se ambos os cabeçalhos estiverem presentes (comum), o cliente decide qual método de autenticação será usado.
Observe que o cabeçalho de autenticação é "Proxy-authenticate:". Isso ocorre porque a conexão na captura usa proxy de encaminhamento explícito. Se essa fosse uma implantação de proxy transparente, o código de resposta seria 401 em vez de 407 e os cabeçalhos seriam "www-authenticate:" em vez de "proxy-authenticate:".
#8 O proxy FINs este soquete TCP. Isso é correto e normal.
#15 Em um novo soquete TCP, o cliente executa outra solicitação GET. Desta vez, observe que GET contém o cabeçalho HTTP "proxy-authorization:". Contém uma cadeia codificada que contém detalhes sobre o Usuário/Domínio.
Se você expandir Proxy-authorization > NTLMSSP, verá as informações decodificadas enviadas nos dados NTLM. No "Tipo de mensagem NTLM", você observará que é "NTLMSSP_NEGOTIATE". Essa é a primeira etapa no handshake triplo do NTLM.
#17 O proxy responde com outro 407. Outro cabeçalho "proxy-authenticate" está presente. Desta vez, ele contém uma cadeia de caracteres de desafio NTLM. Se expandi-lo ainda mais, você verá que o tipo de mensagem NTLM é "NTLMSSP_CHALLENGE". Essa é a segunda etapa no handshake triplo do NTLM.
Na autenticação NTLM, o controlador de domínio do Windows envia uma cadeia de caracteres de desafio ao cliente. Em seguida, o cliente aplica um algoritmo ao desafio NTLM que leva em consideração a senha do usuário no processo. Isso permite que o controlador de domínio verifique se o cliente sabe a senha correta sem nunca enviá-la pela linha. Isso é muito mais seguro do que as credenciais básicas, em que a senha é enviada em texto simples para todos os dispositivos de farejamento verem.
#18 O cliente envia um GET final. Observe que esse GET está no MESMO soquete TCP em que o NTLM Negotiate e o NTLM Challenge ocorreram. Isso é vital para o processo NTLM. Todo o handshake deve ocorrer no MESMO soquete TCP, caso contrário, a autenticação será inválida.
Nessa solicitação, o cliente envia o Desafio NTLM (Resposta NTLM) modificado ao proxy. Esta é a etapa final do handshake NTLM de três vias.
#21 O proxy envia de volta uma resposta HTTP. Isso significa que o procurador aceitou as credenciais e decidiu servir o conteúdo.
Feedback