IIS bietet viele verschiedene Authentifizierungstechnologien an. Eine davon ist die Integration der Windows-Authentifizierung. Die integrierte Windows-Authentifizierung nutzt Negotiation Kerberos oder NTLM, um Nutzer basierend auf verschlüsselten Ticket-Nachrichten zwischen Browser und Server zu authentifizieren.
Das häufigste Anwendungsszenario der NTLM-Authentifizierung ist wahrscheinlich die in Browsern verwendete Authentifizierung (HTTP-Protokoll). In Wirklichkeit spezifiziert NTLM jedoch nur den Authentifizierungsprozess und das Authentifizierungsnachrichtenformat. Es bezieht sich nicht auf konkrete Vereinbarungen. Es besteht also keine notwendige Verbindung zu http. Der Browser trägt die NTLM-Nachricht nur im HTTP-Protokoll-Header und überträgt die Authentifizierung. Wir wissen, dass HTTP meist im Klartext vorliegt, sodass NTLM dieses Problem effektiv verhindert, wenn die direkte Übertragung von Passwörtern sehr unsicher ist.
Zertifizierungsprozess
Die NTLM-Authentifizierung erfordert drei Schritte, und Sie können den detaillierten Anforderungsprozess über die Fiddler-Toolbox einsehen.
Schritt 1
Der Benutzer meldet sich beim Client-Host an, indem er die Windows-Kontonummer und das Passwort eingibt. Vor dem Einloggen speichert der Client den Hash des eingegebenen Passworts, und das ursprüngliche Passwort wird verworfen ("das ursprüngliche Passwort darf unter keinen Umständen zwischengespeichert werden", dies ist eine grundlegende Sicherheitsrichtlinie). Ein Nutzer, der sich erfolgreich im Client-Windows anmeldet, muss eine Anfrage an die andere Partei senden, wenn sie versucht, auf Serverressourcen zuzugreifen. Die Anfrage enthält einen Benutzernamen im Klartext.
Schritt 2
Wenn der Server die Anfrage erhält, erzeugt er eine 16-Bit-Zufallszahl. Diese Zufallszahl wird als Challenge oder Nonce bezeichnet. Die Herausforderung wird gespeichert, bevor der Server sie an den Client sendet. Herausforderungen werden im Klartext verschickt.
Schritt 3
Nachdem der Client die vom Server zurückgesendete Herausforderung erhalten hat, verschlüsselt er sie mit dem in Schritt 1 gespeicherten Passwort-Hash und sendet dann die verschlüsselte Herausforderung an den Server.
Schritt 4
Nach Erhalt der vom Client zurückgesendeten verschlüsselten Herausforderungen sendet der Server eine Authentifizierungsanfrage an den Client an den DC (Domain). Die Anfrage umfasst hauptsächlich die folgenden drei Inhalte: Benutzername des Kunden; Herausforderung und ursprüngliche Herausforderung mit verschlüsseltem Client-Passwort-Hash.
Schritte 5 und 6
DC verschlüsselt die ursprüngliche Herausforderung, indem er den Passwort-Hash des Kontos basierend auf dem Benutzernamen erhält. Wenn die verschlüsselte Herausforderung dieselbe ist wie die, die vom Server gesendet wurde, bedeutet das, dass der Nutzer das korrekte Passwort hat und die Verifizierung besteht, andernfalls scheitert die Verifizierung. Der DC sendet die Verifizierungsergebnisse an den Server und gibt schließlich eine Rückmeldung an den Client.
Nachschlageartikel:
Der Hyperlink-Login ist sichtbar.
Der Hyperlink-Login ist sichtbar.
Der Hyperlink-Login ist sichtbar.
|
Veröffentlicht am 5.9.2020, 13:28:14
|
|
|
|
