NTLM-Benutzerauthentifizierung

Dieser Artikel enthält einige Informationen zur NTLM-Benutzerauthentifizierung.

Ursprüngliche Produktversion:   Windows Server 2012 R2
Ursprüngliche KB-Nummer:   102716

Zusammenfassung

In diesem Artikel werden die folgenden Aspekte der NTLM-Benutzerauthentifizierung in Windows erläutert:

  • Kennwortspeicherung in der Kontodatenbank
  • Benutzerauthentifizierung mithilfe des MSV1_0 Authentifizierungspakets
  • Pass-Through-Authentifizierung

Weitere Informationen

Kennwortspeicherung in der Kontodatenbank

Benutzerdatensätze werden in der SAM-Datenbank (Security Accounts Manager) oder in der Active Directory-Datenbank gespeichert. Jedem Konto werden zwei Kennwörter zugeordnet: das LAN-Manager-kompatible Kennwort und das Windows-Kennwort. Jedes Kennwort wird verschlüsselt und in der SAM-Datenbank oder in der Active Directory-Datenbank gespeichert.

Das LAN Manager-kompatible Kennwort ist mit dem Kennwort kompatibel, das vom LAN Manager verwendet wird. Dieses Kennwort basiert auf dem Zeichensatz des Originalgeräteherstellers (OEM). Bei diesem Kennwort wird die Kleinschreibung nicht beachtet und kann bis zu 14 Zeichen lang sein. Die OWF-Version dieses Kennworts wird auch als OWF- oder ESTD-Version des LAN Managers bezeichnet. Dieses Kennwort wird mithilfe der DES-Verschlüsselung berechnet, um eine Konstante mit dem Klartextkennwort zu verschlüsseln. Das LAN Manager-OWF-Kennwort ist 16 Byte lang. Die ersten 7 Bytes des Klartextkennworts werden verwendet, um die ersten 8 Bytes des LAN Manager-OWF-Kennworts zu berechnen. Die zweiten 7 Bytes des Klartextkennworts werden zum Computer der zweiten 8 Byte des LAN Manager-OWF-Kennworts verwendet.

Das Windows-Kennwort basiert auf dem Unicode-Zeichensatz. Bei diesem Kennwort wird die Kleinschreibung beachtet und kann bis zu 128 Zeichen lang sein. Die OWF-Version dieses Kennworts wird auch als Windows OWF-Kennwort bezeichnet. Dieses Kennwort wird mithilfe des RSA MD-4-Verschlüsselungsalgorithmus berechnet. Dieser Algorithmus berechnet einen Digest mit 16 Byte einer Zeichenfolge mit variabler Länge aus Klartextkennwortbytes.

Bei jedem Benutzerkonto fehlt möglicherweise entweder das LAN-Manager-Kennwort oder das Windows-Kennwort. Es wird jedoch versucht, beide Versionen des Kennworts zu verwalten.

Wenn das Benutzerkonto beispielsweise mithilfe von PortUas aus einer LAN-Manager-UAS-Datenbank portiert wird oder wenn das Kennwort von einem LAN-Manager-Client oder von einem Windows for Workgroups-Client geändert wird, ist nur die LAN -Manager-Version des Kennworts vorhanden. Wenn das Kennwort auf einem Windows-Client festgelegt oder geändert wird und das Kennwort keine LAN-Manager-Darstellung hat, ist nur die Windows-Version des Kennworts vorhanden. (Das Kennwort hat möglicherweise keine LAN-Manager-Darstellung, da das Kennwort länger als 14 Zeichen ist oder weil die Zeichen nicht im OEM-Zeichensatz dargestellt werden können.)

Benutzeroberflächenbeschränkungen in Windows lassen keine Windows-Kennwörter von mehr als 14 Zeichen zu. Die Auswirkungen dieser Einschränkung werden weiter später in diesem Artikel erläutert.

In Windows 2000 Service Pack 2 und neueren Versionen von Windows ist eine Einstellung verfügbar, mit der Sie verhindern können, dass Windows einen LAN-Manager-Hash Ihres Kennworts speichert. Weitere Informationen finden Sie in der folgenden Artikelnummer, um den Artikel in der Microsoft Knowledge Base zu sehen:

299656 Verhindern, dass Windows einen #A0 Ihres Kennworts in Active Directory und lokalen #A1 speichert

Hinweis

Microsoft unterstützt keine manuelle oder programmgesteuerte Änderung der SAM-Datenbank.

Benutzerauthentifizierung mithilfe des MSV1_0 Authentifizierungspakets

Windows verwendet die LsaLogonUser-API für alle Arten von Benutzerauthentifizierungen. Die LsaLogonUser-API authentifiziert Benutzer durch Aufrufen eines Authentifizierungspakets. Standardmäßig ruft LsaLogonUser das MSV1_0 (MSV) auf. Dieses Paket ist in Windows NT enthalten. Das MSV-Authentifizierungspaket speichert Benutzerdatensätze in der SAM-Datenbank. Dieses Paket unterstützt die Pass-Through-Authentifizierung von Benutzern in anderen Domänen mithilfe des Netlogon-Diensts.

Intern ist das MSV-Authentifizierungspaket in zwei Teile unterteilt. Der erste Teil des MSV-Authentifizierungspakets wird auf dem Computer ausgeführt, mit dem eine Verbindung besteht. Der zweite Teil wird auf dem Computer ausgeführt, der das Benutzerkonto enthält. Wenn beide Teile auf demselben Computer ausgeführt werden, ruft der erste Teil des MSV-Authentifizierungspakets den zweiten Teil ohne Beteiligung des Netlogon-Diensts auf. Der erste Teil des MSV-Authentifizierungspakets erkennt, dass die Pass-Through-Authentifizierung erforderlich ist, da der übergebene Domänenname kein eigener Domänenname ist. Wenn die Pass-Through-Authentifizierung erforderlich ist, übergibt MSV die Anforderung an den Netlogon-Dienst. Der Netlogon-Dienst leitet die Anforderung dann an den Netlogon-Dienst auf dem Zielcomputer weiter. Der Netlogon-Dienst übergibt die Anforderung wiederum an den anderen Teil des MSV-Authentifizierungspakets auf diesem Computer.

LsaLogonUser unterstützt interaktive Anmeldungen, Dienstanmeldungen und Netzwerkanmeldungen. Im MSV-Authentifizierungspaket übergeben alle Arten der Anmeldung den Namen des Benutzerkontos, den Namen der Domäne, die das Benutzerkonto enthält, und eine Funktion des Kennworts des Benutzers. Die verschiedenen Anmeldearten stellen das Kennwort anders dar, wenn sie es an LsaLogonUser übergeben.

Bei interaktiven Anmeldungen, Batchanmeldungen und Dienstanmeldungen befindet sich der Anmeldeclient auf dem Computer, auf dem der erste Teil des MSV-Authentifizierungspakets ausgeführt wird. In diesem Fall wird das Klartextkennwort an LsaLogonUser und den ersten Teil des MSV-Authentifizierungspakets übergeben. Bei Dienstanmeldungen und Batchanmeldungen bieten der Dienststeuerungs-Manager und der Aufgabenplaner eine sicherere Möglichkeit zum Speichern der Anmeldeinformationen des Kontos.

Der erste Teil des MSV-Authentifizierungspakets konvertiert das Klartextkennwort sowohl in ein LAN Manager-OWF-Kennwort als auch in ein Windows NT OWF-Kennwort. Anschließend übergibt der erste Teil des Pakets das Klartextkennwort entweder an den NetLogon-Dienst oder den zweiten Teil des Pakets. Der zweite Teil fragt dann die Sam-Datenbank nach den OWF-Kennwörtern ab und stellt sicher, dass sie identisch sind.

Bei Netzwerkanmeldungen wurde dem Client, der eine Verbindung mit dem Computer herstellt, zuvor eine 16-Byte-Herausforderung (Nonce) angezeigt. Wenn es sich bei dem Client um einen LAN-Manager-Client handelt, hat der Client eine 24-Byte-Antwort zur Herausforderung durch Verschlüsseln der 16-Byte-Herausforderung mit dem OWF-Kennwort des 16-Byte-LAN-Managers berechnet. Der LAN-Manager-Client übergibt dann diese "LAN Manager Challenge Response" an den Server. Wenn es sich bei dem Client um einen Windows-Client handelt, wird eine "Windows NT-Abfrageantwort" mit demselben Algorithmus berechnet. Der Windows-Client verwendet jedoch die Windows OWF-Daten mit 16 Byte anstelle der LAN Manager-OWF-Daten. Der Windows-Client übergibt dann sowohl die LAN Manager Challenge Response als auch die Windows NT Challenge Response an den Server. In beiden Fällen authentifiziert der Server den Benutzer, indem folgendes an die LsaLogonUser-API übergeben wird:

  • Der Domänenname
  • Der Benutzername
  • Die ursprüngliche Herausforderung
  • Antwort auf die LAN-Manager-Herausforderung
  • Die optionale Windows NT-Abfrageantwort

Der erste Teil des MSV-Authentifizierungspakets übergibt diese Informationen unverändert an den zweiten Teil. Zunächst fragt der zweite Teil die OWF-Kennwörter aus der SAM-Datenbank oder aus der Active Directory-Datenbank ab. Anschließend berechnet der zweite Teil die Antwort auf die Herausforderung mithilfe des OWF-Kennworts aus der Datenbank und der übergebenen Herausforderung. Im zweiten Teil wird dann die berechnete Herausforderungsantwort mit der übergebenen Herausforderungsantwort verglichen.

Hinweis

Mit NTLMv2 kann der Client auch eine Herausforderung zusammen mit der Verwendung von Sitzungsschlüsseln senden, um das Risiko häufiger Angriffe zu verringern.

Wie bereits erwähnt, fehlen möglicherweise beide Versionen des Kennworts in der SAM-Datenbank oder in der Active Directory-Datenbank. Außerdem fehlt möglicherweise eine der beiden Versionen des Kennworts beim Aufruf von LsaLogonUser. Wenn sowohl die Windows-Version des Kennworts aus der SAM-Datenbank als auch die Windows-Version des Kennworts von LsaLogonUser verfügbar sind, werden beide verwendet. Andernfalls wird die LAN -Manager-Version des Kennworts zum Vergleich verwendet. Diese Regel hilft bei der Erzwingung der Empfindlichkeit bei Netzwerkanmeldungen von Windows zu Windows. Diese Regel ermöglicht auch die Abwärtskompatibilität.

Pass-Through-Authentifizierung

Der NetLogon-Dienst implementiert die Pass-Through-Authentifizierung. Er führt die folgenden Funktionen aus:

  • Wählt die Domäne aus, an die die Authentifizierungsanforderung übergeben werden soll.
  • Wählt den Server innerhalb der Domäne aus.
  • Übergibt die Authentifizierungsanforderung an den ausgewählten Server.

Das Auswählen der Domäne ist einfach. Der Domänenname wird an LsaLogonUser übergeben. Der Domänenname wird wie folgt verarbeitet:

  • Entspricht der Domänenname dem Namen der SAM-Datenbank, wird die Authentifizierung auf diesem Computer verarbeitet. Auf einer Windows-Arbeitsstation, die Mitglied einer Domäne ist, wird der Name der SAM-Datenbank als Name des Computers betrachtet. Auf einem Active Directory-Domänencontroller ist der Name der Kontodatenbank der Name der Domäne. Auf einem Computer, der kein Mitglied einer Domäne ist, verarbeiten alle Anmeldungen Anforderungen lokal.
  • Wenn der angegebene Domänenname von dieser Domäne als vertrauenswürdig eingestuft wird, wird die Authentifizierungsanforderung an die vertrauenswürdige Domäne übergeben. Auf Active Directory-Domänencontrollern ist die Liste der vertrauenswürdigen Domänen problemlos verfügbar. Bei einem Mitglied einer Windows-Domäne wird die Anforderung immer an die primäre Domäne der Arbeitsstation übergeben, damit die primäre Domäne bestimmt, ob die angegebene Domäne vertrauenswürdig ist.
  • Wenn der angegebene Domänenname von der Domäne nicht als vertrauenswürdig eingestuft wird, wird die Authentifizierungsanforderung auf dem Computer verarbeitet, mit dem eine Verbindung besteht, als wäre der angegebene Domänenname dieser Domänenname. NetLogon unterscheidet nicht zwischen einer nicht vorhandenen Domäne, einer nicht vertrauenswürdigen Domäne und einem falsch eingegebenen Domänennamen.

NetLogon wählt einen Server in der Domäne durch einen Prozess namens Ermittlung aus. Eine Windows-Arbeitsstation ermittelt den Namen eines der Windows Active Directory-Domänencontroller in der primären Domäne. Ein Active Directory-Domänencontroller ermittelt den Namen eines Active Directory-Domänencontrollers in jeder vertrauenswürdigen Domäne. Die Komponente, die die Ermittlung vor sich führt, ist der DC Locator, der im Netlogon-Dienst ausgeführt wird. Der DC Locator verwendet entweder NETBIOS- oder DNS-Namensauflösung, um die erforderlichen Server zu finden, je nach konfigurierter Domänen- und Vertrauenstyp.