Introduction
Ce document décrit l'authentification NT LAN Manager (NTLM) au niveau paquet.
À quoi devrait ressembler l'authentification NTLM au niveau du paquet ?
Une capture de paquets pour suivre cet article peut être téléchargée ici : https://supportforums.cisco.com/sites/default/files/attachments/document/ntlm_auth.zip
Adresse IP du client : 10.122.142.190
IP WSA : 10.122.144.182
Numéro et détails du paquet
#4 Le client envoie une requête GET au proxy.
#7 Le proxy renvoie un message 407. Cela signifie que le proxy n'autorise pas le trafic en raison d'une authentification incorrecte. Si vous regardez les en-têtes HTTP dans cette réponse, vous verrez un "Proxy-authenticate : NTLM". Cela indique au client qu'une méthode d'authentification acceptable est NTLM. De même, si l'en-tête « Proxy-authenticate : Basic » est présent, le proxy indique au client que les informations d'identification de base sont acceptables. Si les deux en-têtes sont présents (communs), le client décide de la méthode d'authentification qu'il utilisera.
Une chose à noter est que l'en-tête d'authentification est "Proxy-authenticate:". Cela est dû au fait que la connexion en capture utilise un proxy de transfert explicite. S'il s'agissait d'un déploiement de proxy transparent, le code de réponse serait 401 au lieu de 407 et les en-têtes seraient « www-authenticate: » au lieu de « proxy-authenticate: ».
#8 Le proxy FIN utilise ce socket TCP. C'est correct et normal.
#15 Sur un nouveau socket TCP, le client exécute une autre requête GET. Cette fois, notez que GET contient l'en-tête HTTP « proxy-authorization: ». Il s'agit d'une chaîne codée qui contient des détails sur l'utilisateur / le domaine.
Si vous développez Proxy-authorization > NTLMSSP, vous verrez les informations décodées envoyées dans les données NTLM. Dans le « Type de message NTLM », vous remarquerez qu'il s'agit de « NTLMSSP_NEGOTIATE ». Il s'agit de la première étape de la connexion NTLM en trois étapes.
#17 Le proxy répond avec un autre 407. Un autre en-tête « proxy-authenticate » est présent. Cette fois, elle contient une chaîne de défi NTLM. Si vous l'étendez davantage, vous verrez que le type de message NTLM est "NTLMSSP_CHALLENGE". Il s'agit de la deuxième étape de la connexion NTLM en trois étapes.
Dans l'authentification NTLM, le contrôleur de domaine Windows envoie une chaîne d'interrogation au client. Le client applique ensuite un algorithme au défi NTLM qui tient compte du mot de passe de l'utilisateur dans le processus. Cela permet au contrôleur de domaine de vérifier que le client connaît le mot de passe correct sans jamais envoyer le mot de passe sur la ligne. Il s'agit d'une méthode beaucoup plus sécurisée que les informations d'identification de base, dans laquelle le mot de passe est envoyé en texte clair pour que tous les périphériques de détection puissent le voir.
#18 Le client envoie un GET final. Notez que cette GET est sur le MÊME socket TCP que celui sur lequel NTLM Negotiate et NTLM Challenge se sont produits. C'est essentiel pour le processus NTLM. La connexion doit se faire entièrement sur le MÊME socket TCP, sinon l'authentification ne sera pas valide.
Dans cette demande, le client envoie la demande NTLM modifiée (réponse NTLM) au proxy. Il s'agit de la dernière étape de la connexion NTLM en trois étapes.
#21 Le proxy renvoie une réponse HTTP. Cela signifie que le proxy a accepté les informations d'identification et a décidé de diffuser le contenu.
Commentaires