Einleitung
In diesem Dokument wird die NT LAN Manager (NTLM)-Authentifizierung auf Paketebene beschrieben.
Wie sollte die NTLM-Authentifizierung auf Paketebene aussehen?
Eine Paketerfassung für diesen Artikel können Sie hier herunterladen: https://supportforums.cisco.com/sites/default/files/attachments/document/ntlm_auth.zip
Client-IP: 10.122.142.190
WSA-IP: 10.122.144.182
Paketnummer und -details
#4 Der Client sendet eine GET-Anforderung an den Proxy.
#7 Der Proxy sendet eine 407 zurück. Das bedeutet, dass der Proxy aufgrund einer fehlenden ordnungsgemäßen Authentifizierung keinen Datenverkehr zulässt. Wenn Sie sich die HTTP-Header in dieser Antwort ansehen, sehen Sie einen "Proxy-Authenticate: NTLM". Dadurch wird der Client informiert, dass eine akzeptable Authentifizierungsmethode NTLM ist. Wenn der Header "Proxy-Authenticate: Basic" vorhanden ist, teilt der Proxy dem Client ebenfalls mit, dass die grundlegenden Anmeldedaten akzeptabel sind. Wenn beide Header vorhanden sind (gemeinsam), entscheidet der Client, welche Authentifizierungsmethode er verwendet.
Zu beachten ist, dass der Authentifizierungsheader "Proxy-Authenticate:" ist. Dies liegt daran, dass die Verbindung in der Erfassung einen expliziten Weiterleitungsproxy verwendet. Wäre dies eine transparente Proxy-Bereitstellung, würde der Antwortcode 401 anstatt 407 lauten, und die Header wären "www-Authenticate:" statt "proxy-Authenticate:".
#8 Der Proxy FINs dieser TCP-Socket. Das ist richtig und normal.
#15 Auf einem neuen TCP-Socket führt der Client eine weitere GET-Anforderung durch. Diesmal wird darauf hingewiesen, dass der GET-Header den HTTP-Header "proxy-authorization:" enthält. Dieser enthält eine codierte Zeichenfolge, die Details zum Benutzer/zur Domäne enthält.
Wenn Sie Proxy-Authorization > NTLMSSP erweitern, werden die decodierten Informationen in den NTLM-Daten gesendet. In der "NTLM Message Type", werden Sie feststellen, dass es sich um "NTLMSSP_NEGOTIATE" handelt. Dies ist der erste Schritt beim Drei-Wege-NTLM-Handshake.
#17 Der Proxy antwortet mit weiteren 407. Ein weiterer Header "proxy-Authenticate" ist vorhanden. Dieses Mal enthält es eine NTLM-Challenge-Zeichenfolge. Wenn Sie sie weiter erweitern, wird der NTLM-Nachrichtentyp "NTLMSSP_CHALLENGE" angezeigt. Dies ist der zweite Schritt beim Drei-Wege-NTLM-Handshake.
Bei der NTLM-Authentifizierung sendet der Windows-Domänencontroller eine Abfragezeichenfolge an den Client. Der Client wendet dann einen Algorithmus auf die NTLM-Herausforderung an, der das Kennwort des Benutzers dabei berücksichtigt. Auf diese Weise kann der Domänencontroller überprüfen, ob der Client das richtige Kennwort kennt, ohne das Kennwort jemals über die Leitung zu senden. Dies ist weitaus sicherer als grundlegende Anmeldedaten, bei denen das Kennwort für alle Sniffing-Geräte im Nur-Text-Format gesendet wird.
#18 Der Client sendet eine letzte GET-Anforderung. Beachten Sie, dass sich dieses GET auf demselben TCP-Socket befindet, auf dem die NTLM-Aushandlung und die NTLM-Herausforderung stattgefunden haben. Dies ist für den NTLM-Prozess von entscheidender Bedeutung. Der gesamte Handshake muss auf demselben TCP-Socket erfolgen, da die Authentifizierung andernfalls ungültig ist.
In dieser Anforderung sendet der Client die geänderte NTLM-Herausforderung (NTLM Response) an den Proxy. Dies ist der letzte Schritt beim Drei-Wege-NTLM-Handshake.
#21 Der Proxy sendet eine HTTP-Antwort zurück. Das bedeutet, dass der Proxy die Anmeldedaten akzeptiert und beschlossen hat, den Inhalt bereitzustellen.
Feedback