Freigeben über

NTLM-Benutzerauthentifizierung

  • Artikel

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

Ursprüngliche KB-Nummer: 102716

Übersicht

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

  • Passwortspeicher in der Kontodatenbank
  • Benutzerauthentifizierung mithilfe des MSV1_0 Authentifizierungspakets
  • Passthrough-Authentifizierung

Weitere Informationen

Passwortspeicher in der Kontodatenbank

Benutzerdatensätze werden in der SAM-Datenbank (Security Accounts Manager) oder in der Active Directory-Datenbank gespeichert. Jedes Benutzerkonto ist zwei Kennwörtern 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 von LAN Manager verwendet wird. Dieses Kennwort basiert auf dem Originalgerätehersteller (OEM)-Zeichensatz. 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 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 verwendet, um die zweiten 8 Bytes des LAN Manager OWF-Kennworts zu computern.

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 mit variabler Länge von Klartextkennwortbytes.

Bei jedem 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 von einer LAN-Manager-UAS-Datenbank mithilfe von PortUas portiert wird oder 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 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 nicht im OEM-Zeichensatz dargestellt werden können.)

Benutzeroberflächenbeschränkungen in Windows lassen Windows-Kennwörter nicht mehr 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

Notiz

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-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 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 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 Pass-Through-Authentifizierung erforderlich ist, da der übergebene Domänenname nicht der eigene Domänenname ist. Wenn die Pass-Through-Authentifizierung erforderlich ist, übergibt MSV die Anforderung an den Netlogon-Dienst. Der Netlogon-Dienst leitet dann die Anforderung 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 einige Funktionen des Kennworts des Benutzers. Die verschiedenen Arten der Anmeldung 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 an den ersten Teil des MSV-Authentifizierungspakets übergeben. Für Dienstanmeldungen und Batchanmeldungen bieten der Dienststeuerungs-Manager und der Taskplaner 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 erhielt der Client, der eine Verbindung mit dem Computer herstellt, zuvor eine 16-Byte-Abfrage oder "Nonce". Wenn es sich bei dem Client um einen LAN-Manager-Client handelt, hat der Client eine 24-Byte-Abfrageantwort berechnet, indem die 16-Byte-Abfrage mit dem 16-Byte-LAN-Manager-OWF-Kennwort verschlüsselt wird. Der LAN-Manager-Client übergibt dann diese LAN-Manager-Abfrageantwort an den Server. Wenn der Client ein Windows-Client ist, wird eine "Windows NT Challenge Response" mithilfe desselben Algorithmus berechnet. Der Windows-Client verwendet jedoch die 16-Byte-Windows OWF-Daten anstelle der LAN Manager OWF-Daten. Der Windows-Client übergibt dann sowohl die LAN-Manager-Abfrageantwort als auch die Windows NT-Abfrageantwort an den Server. In beiden Fällen authentifiziert der Server den Benutzer, indem er folgendes an die LsaLogonUser-API übergibt:

  • Der Domänenname
  • Benutzername
  • Die ursprüngliche Herausforderung
  • Die Lan-Manager-Abfrageantwort
  • 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 Abfrageantwort mithilfe des OWF-Kennworts aus der Datenbank und der abfrage, die übergeben wurde. Der zweite Teil vergleicht dann die berechnete Abfrageantwort mit der Antwort der übergebenen Abfrage.

Notiz

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

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 der Beiden Versionen des Kennworts aus dem 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, die Groß-/Kleinschreibung zu erzwingen, wenn Netzwerkanmeldungen von Windows zu Windows auftreten. Diese Regel ermöglicht auch die Abwärtskompatibilität.

Passthrough-Authentifizierung

Der NetLogon-Dienst implementiert die Pass-Through-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 dem Namen der SAM-Datenbank entspricht, wird die Authentifizierung auf diesem Computer verarbeitet. Auf einer Windows-Arbeitsstation, die Mitglied einer Domäne ist, wird der Name der SAM-Datenbank als Der Name des Computers betrachtet. Bei 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 Anmeldeanforderungen 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 einfach 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 als vertrauenswürdig eingestuft wird, wird die Authentifizierungsanforderung auf dem Computer verarbeitet, mit dem eine Verbindung hergestellt wird, als ob der angegebene Domänenname diesen Domänennamen wäre. 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 Discovery 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 durchfü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 Typ der Domäne und Vertrauensstellung, die konfiguriert ist.