NTLM-Benutzerauthentifizierung

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

Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 102716

Zusammenfassung

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

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

Weitere Informationen

Kennwortspeicher 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 Oem-Zeichensatz (Original Equipment Manufacturer). Bei diesem Kennwort wird die Groß-/Kleinschreibung nicht beachtet und kann bis zu 14 Zeichen lang sein. Die OWF-Version dieses Kennworts wird auch als LAN Manager-OWF- oder ESTD-Version bezeichnet. Dieses Kennwort wird mithilfe der DES-Verschlüsselung berechnet, um eine Konstante mit dem Klartextkennwort zu verschlüsseln. Das OWF-Kennwort des LAN-Managers 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 verwendet, um die zweiten 8 Bytes des LAN-Manager-OWF-Kennworts zu computer.

Das Windows-Kennwort basiert auf dem Unicode-Zeichensatz. Bei diesem Kennwort wird die Groß-/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 der RSA MD4-Hashfunktion berechnet. Diese Funktion berechnet einen 16-Byte-Digest einer Zeichenfolge variabler Länge von Klartextkennwortbytes.

Für jedes Benutzerkonto fehlt möglicherweise entweder das LAN-Manager-Kennwort oder das Windows-Kennwort. Es wird jedoch versucht, beide Versionen des Kennworts beizubehalten.

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 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 aufweist, 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 im OEM-Zeichensatz nicht dargestellt werden können.)

Benutzeroberflächenbeschränkungen in Windows lassen windows-Kennwörter nicht länger als 14 Zeichen zu. Die Auswirkungen dieser Einschränkung werden weiter unten in diesem Artikel erläutert.

In Windows 2000 Service Pack 2 und höheren 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 anzuzeigen:

299656 Verhindern, dass Windows einen LAN-Manager-Hash Ihres Kennworts in Active Directory und lokalen SAM-Datenbanken speichert

Hinweis

Das manuelle oder programmgesteuerte Ändern der SAM-Datenbank wird von Microsoft nicht unterstützt.

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-Authentifizierungspaket (MSV) auf. Dieses Paket ist in Windows NT enthalten. Das MSV-Authentifizierungspaket speichert Benutzerdatensätze in der SAM-Datenbank. Dieses Paket unterstützt die Passthrough-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 hergestellt wird. 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 auf, ohne den Netlogon-Dienst einzubeziehen. Der erste Teil des MSV-Authentifizierungspakets erkennt, dass die Passthrough-Authentifizierung erforderlich ist, da der übergebene Domänenname kein eigener Domänenname ist. Wenn eine Passthrough-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 wiederum die Anforderung an den anderen Teil des MSV-Authentifizierungspakets auf diesem Computer.

LsaLogonUser unterstützt interaktive Anmeldungen, Dienstanmeldungen und Netzwerkanmeldungen. Im MSV-Authentifizierungspaket übergeben alle Formen 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 Anmeldetypen stellen das Kennwort unterschiedlich dar, wenn sie es an LsaLogonUser übergeben.

Für interaktive 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 an den ersten Teil des MSV-Authentifizierungspakets übergeben. Für 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 an 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-Challenge (nonce) erteilt. Wenn der Client ein LAN Manager-Client ist, hat der Client eine 24-Byte-Challenge-Antwort berechnet, indem er die 16-Byte-Challenge mit dem OWF-Kennwort des 16-Byte-LAN-Managers verschlüsselt hat. 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-Anforderungsantwort" mit demselben Algorithmus berechnet. Der Windows-Client verwendet jedoch die 16-Byte-Windows OWF-Daten anstelle der OWF-Daten des LAN-Managers. Der Windows-Client übergibt dann sowohl die LAN-Manager-Anforderungsantwort als auch die Windows NT-Anforderungsantwort an den Server. In beiden Fällen authentifiziert der Server den Benutzer, indem er alle folgenden Elemente an die LsaLogonUser-API übergibt:

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

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 der Herausforderung, indem das OWF-Kennwort aus der Datenbank und die übergebene Challenge verwendet wird. Im zweiten Teil wird dann die Antwort der berechneten Herausforderung mit der Antwort der übergebenen Herausforderung verglichen.

Hinweis

NTLMv2 ermöglicht es dem Client auch, eine Challenge zusammen mit der Verwendung von Sitzungsschlüsseln zu senden, die dazu beitragen, das Risiko häufiger Angriffe zu reduzieren.

Wie bereits erwähnt, fehlt möglicherweise eine version des Kennworts in der SAM-Datenbank oder in der Active Directory-Datenbank. Außerdem fehlt möglicherweise eine version des Kennworts im 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 dabei, die Groß-/Kleinschreibung zu erzwingen, wenn Netzwerkanmeldungen von Windows zu Windows erfolgen. Diese Regel ermöglicht auch die Abwärtskompatibilität.

Pass-Through-Authentifizierung

Der NetLogon-Dienst implementiert die Passthrough-Authentifizierung. Es 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.

Die Auswahl der Domäne ist einfach. Der Domänenname wird an LsaLogonUser übergeben. Der Domänenname wird wie folgt verarbeitet:

• Wenn der Domänenname mit dem Namen der SAM-Datenbank übereinstimmt, 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 nicht 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 leicht verfügbar. Bei einem Mitglied einer Windows-Domäne wird die Anforderung immer an die primäre Domäne der Arbeitsstation übergeben, sodass die primäre Domäne bestimmen kann, ob die angegebene Domäne vertrauenswürdig ist.
• Wenn der angegebene Domänenname von der Domäne nicht vertrauenswürdig ist, wird die Authentifizierungsanforderung auf dem Computer verarbeitet, mit dem eine Verbindung hergestellt wird, 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 seiner 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 durchführt, ist der DC Locator, der im Netlogon-Dienst ausgeführt wird. Der DC-Locator verwendet entweder NETBIOS oder die DNS-Namensauflösung, um die erforderlichen Server zu suchen, abhängig vom Typ der konfigurierten Domäne und Vertrauensstellung.