Inleiding
Dit document beschrijft de verificatie van NT LAN Manager (NTLM) op pakketniveau.
Hoe moet NTLM-verificatie eruit zien op pakketniveau?
Een pakketopname om dit artikel te volgen kan hier worden gedownload: https://supportforums.cisco.com/sites/default/files/attachments/document/ntlm_auth.zip
IP-telefoon van client: 10.12.142.190
WAE IP-telefoon 10.122.144.182
Packet nummer en details
#4 De client stuurt een GET-verzoek naar de proxy.
#7 De proxy stuurt een 407 terug. Dit betekent dat de proxy geen verkeer toestaat vanwege een gebrek aan juiste authenticatie. Als u in deze reactie kijkt naar de HTTP-headers, ziet u een "Proxy-authenticate: NTLM". Dit vertelt de client dat NTLM een acceptabele verificatiemethode is. Op dezelfde manier, als de kop "Proxy-authenticate: Basic" aanwezig is, vertelt de proxy de client dat basisreferenties acceptabel zijn. Als beide headers aanwezig zijn (gemeenschappelijk), beslist de client welke verificatiemethode zal worden gebruikt.
Een ding om op te merken is dat de authenticatieheader "Proxy-authenticate:" is. Dit komt doordat de verbinding in Capture expliciete voorwaartse proxy gebruikt. Als dit een transparante proxyimplementatie was, zou de responscode 401 zijn in plaats van 407 en zouden de kopregels "www-authenticate:" zijn in plaats van "proxy-authenticate:".
#8 De proxy FIN's deze TCP socket. Dit is juist en normaal.
#15 Op een nieuwe TCP socket voert de client nog een GET request uit. Dit keer merkt op dat de GET de HTTP header "proxy-autorisatie:" bevat. Dit bevat een gecodeerde string die details bevat betreffende de gebruiker / domein.
Als u de Proxy-autorisatie > NTLMSSP uitbreidt, ziet u de gedecodeerde informatie die in de NTLM-gegevens wordt verzonden. In het "NTLM Message Type", zult u opmerken dat het "NTLMSSP_ONDERHANDELING" is. Dit is de eerste stap in de drieweg NTLM handdruk.
#17 De proxy reageert met nog eens 407. Er is een andere header "proxy-authenticate" aanwezig. Dit keer bevat het een NTLM challenge string. Als u het verder uitbreidt, ziet u dat het NTLM Message Type "NTLMSSP_UITDAGGE" is. Dit is de tweede stap in de drieweg NTLM handdruk.
Bij NTLM-verificatie stuurt de Windows-domeincontroller een provocatietekenreeks naar de client. De client past dan een algoritme toe op de NTLM-uitdaging die in het wachtwoord van de gebruiker in het proces factoren. Dit stelt de domeincontroller in staat om te verifiëren dat de client het juiste wachtwoord kent zonder ooit het wachtwoord over de lijn te verzenden. Dit is veel veiliger dan basisreferenties, waarin het wachtwoord wordt verzonden in onbewerkte tekst voor alle snuffelapparaten om te zien.
#18 De client stuurt een laatste GET. Merk op dat dit GET zich op dezelfde TCP socket bevindt als de NTLM Negotiate en NTLM Challenge zijn opgetreden. Dit is essentieel voor het NTLM-proces. De gehele handdruk moet op dezelfde TCP socket staan, anders is de verificatie ongeldig.
In dit verzoek stuurt de client de gewijzigde NTLM Challenge (NTLM Response) naar de proxy. Dit is de laatste stap in de drieweg NTLM handdruk.
#21 De proxy stuurt een HTTP-antwoord terug. Dit betekent dat de proxy de referenties heeft geaccepteerd en heeft besloten om de inhoud op te dienen.
Feedback