Freigeben über

IIS authentifiziert Browserclients

In diesem Artikel wird erläutert, wie IIS Browserclients authentifiziert.

Originalproduktversion: Internet Explorer
Ursprüngliche KB-Nummer: 264921

Zusammenfassung

In diesem Artikel werden die verschiedenen Authentifizierungsmethoden beschrieben, die in IIS für Windows NT 4.0, Windows 2000 und höher verfügbar sind. Eine ausführlichere Beschreibung der informationen, die in diesem Artikel erläutert werden, finden Sie in den Ressourcenhandbüchern für Windows NT 4.0 und Windows 2000.

Authentifizierungsmethoden, die für Windows NT 4.0 verfügbar sind

Anonym – Es ist keine Anmeldung erforderlich, und jeder kann zugriff auf Daten erhalten, die mit dieser Methode geschützt sind. Der Server verwendet ein integriertes Konto (IUSR_[Computername] standardmäßig), um die Berechtigungen für die Dateien zu steuern. Der Browser sendet keine Anmeldeinformationen oder Benutzerinformationen mit diesem Anforderungstyp.

  • Unterstützte Browser: alle
  • Einschränkungen: Keine
  • Benutzerrechte erforderlich: Das auf dem Server definierte anonyme Benutzerkonto muss über lokale Berechtigungen verfügen.
  • Verschlüsselungstyp: Keine

Einfach (Klartext) – Der Server fordert den Benutzer auf, sich anzumelden, und ein Dialogfeld wird im Browser angezeigt, mit dem der Benutzer die erforderlichen Anmeldeinformationen eingeben kann. Diese Anmeldeinformationen müssen mit den für die Dateien definierten Benutzeranmeldeinformationen übereinstimmen, auf die der Benutzer zugreifen möchte.

  • Unterstützte Browser: alle
  • Einschränkungen: Nicht sicher. Kennwörter werden leicht entschlüsselt.
  • Benutzerrechte erforderlich: Das Benutzerkonto muss über lokale Berechtigungen verfügen.
  • Verschlüsselungstyp: Base64-Codierung (keine echte Verschlüsselung)

Windows NT Challenge/Response – Der Server fordert den Benutzer auf, sich anzumelden. Wenn der Browser Windows NT Challenge/Response unterstützt, sendet er automatisch die Anmeldeinformationen des Benutzers, wenn der Benutzer angemeldet ist. Wenn die Domäne, auf der sich der Benutzer befindet, von der Domäne des Servers abweicht oder der Benutzer nicht angemeldet ist, wird ein Dialogfeld angezeigt, in dem die zu sendenden Anmeldeinformationen angefordert werden. Windows NT Challenge/Response verwendet einen Algorithmus, um einen Hash basierend auf den Anmeldeinformationen des Benutzers und dem Computer zu generieren, den der Benutzer verwendet. Anschließend wird dieser Hash an den Server gesendet. Der Browser sendet das Kennwort des Benutzers nicht an den Server.

  • Unterstützte Browser: Internet Explorer-Versionen 3.01 und höher

  • Einschränkungen: Erfordert Punkt-zu-Punkt-Verbindung. In der Regel wird ein Schaltkreis nach einer Fehlermeldung "401 nicht autorisiert" geschlossen; Beim Aushandeln einer Windows NT Challenge/Response-Authentifizierungssequenz (die mehrere Roundtrips erfordert), hält der Server den Schaltkreis jedoch für die Dauer der Sequenz geöffnet, nachdem der Client angegeben hat, dass er Windows NT Challenge/Response verwendet. CERN-Proxys und bestimmte andere Internetgeräte verhindern, dass dies funktioniert. Außerdem unterstützt Windows NT Challenge/Response keine Identitätswechsel mit doppelten Hops (in diesem Fall, wenn sie an den IIS-Server übergeben wurden, können dieselben Anmeldeinformationen nicht an einen Back-End-Server zur Authentifizierung übergeben werden).

  • Benutzerrechte erforderlich: Das Benutzerkonto, das auf den Server zugreift, muss über berechtigungen "Zugriff auf diesen Computer aus dem Netzwerk" verfügen.

  • Verschlüsselungstyp: NTLM-Hashalgorithmus, der ebenfalls nicht codiert ist.

Rangfolgen: Wenn der Browser eine Anforderung vorlegt, wird immer die erste Anforderung als anonym betrachtet. Daher werden keine Anmeldeinformationen gesendet. Wenn der Server anonym ODER nicht akzeptiert, wenn das auf dem Server festgelegte Benutzerkonto über keine Berechtigungen für die angeforderte Datei verfügt, antwortet der IIS-Server mit einer Fehlermeldung "Zugriff verweigert" und sendet eine Liste der Authentifizierungstypen, die mithilfe eines der folgenden Szenarien unterstützt werden:

  • Wenn Windows NT Challenge/Response die einzige unterstützte Methode ist (oder wenn Anonym fehlschlägt), muss der Browser diese Methode unterstützen, um mit dem Server zu kommunizieren. Andernfalls kann er nicht mit dem Server verhandeln, und der Benutzer erhält eine Fehlermeldung "Zugriff verweigert ".
  • Wenn Basic die einzige unterstützte Methode ist (oder wenn anonym ein Fehler auftritt), wird ein Dialogfeld im Browser angezeigt, um die Anmeldeinformationen abzurufen, und übergibt diese Anmeldeinformationen dann an den Server. Es versucht, diese Anmeldeinformationen bis zu dreimal zu senden. Wenn dies alles fehlschlägt, ist der Browser nicht mit dem Server verbunden.
  • Wenn sowohl basic als auch Windows NT Challenge/Response unterstützt werden, bestimmt der Browser, welche Methode verwendet wird. Wenn der Browser Windows NT Challenge/Response unterstützt, wird diese Methode verwendet und nicht auf Basic zurückfallen. Wenn Windows NT Challenge/Response nicht unterstützt wird, verwendet der Browser Basic.

Notiz

  • Wenn Ihr Browser eine Verbindung mit einer Website mithilfe Basic oder NTLM Authentifizierung herstellt, fällt er während der restlichen Sitzung mit dem Server nicht auf "Anonym" zurück. Wenn Sie versuchen, eine Verbindung mit einer Webseite herzustellen, die nur nach der Authentifizierung für "Anonym" gekennzeichnet ist, werden Sie verweigert. (Dies kann für Netscape wahr sein oder nicht.
  • Wenn Internet Explorer eine Verbindung mit dem Server mithilfe Basic oder NTLM Authentifizierung hergestellt hat, werden die Anmeldeinformationen für jede neue Anforderung für die Dauer der Sitzung übergeben.

Authentifizierungsmethoden, die für Windows 2000 und höher verfügbar sind

Anonym – Es ist keine Anmeldung erforderlich, und jeder kann zugriff auf daten erhalten, die mit dieser Methode geschützt sind. Der Server verwendet ein integriertes Konto (IUSR_[Computername] standardmäßig), um die Berechtigungen für die Dateien zu steuern. Der Browser sendet keine Anmeldeinformationen oder Benutzerinformationen mit diesem Anforderungstyp.

  • Unterstützte Browser: alle
  • Einschränkungen: Keine
  • Benutzerrechte erforderlich: Das auf dem Server definierte anonyme Benutzerkonto muss über berechtigungen "Lokal anmelden" verfügen.
  • Verschlüsselungstyp: Keine

Einfach (Klartext) – Der Server fordert den Benutzer auf, sich anzumelden, und ein Dialogfeld wird im Browser angezeigt, mit dem der Benutzer die erforderlichen Anmeldeinformationen eingeben kann. Diese Anmeldeinformationen müssen mit den für die Dateien definierten Benutzeranmeldeinformationen übereinstimmen, auf die der Benutzer zugreifen möchte.

  • Unterstützte Browser: alle
  • Einschränkungen: Nicht sicher. Kennwörter werden leicht entschlüsselt.
  • Benutzerrechte erforderlich: Das Benutzerkonto muss sich lokal anmelden
  • Verschlüsselungstyp: Base64-Codierung (keine echte Verschlüsselung)

Digest : Der Server fordert den Benutzer auf, sich anzumelden, und sendet auch eine NONCE, die zum Verschlüsseln des Kennworts verwendet wird. Der Browser verwendet die NONCE zum Verschlüsseln des Kennworts und sendet dieses an den Server. Der Server verschlüsselt dann seine eigene Kopie des Kennworts des Benutzers und vergleicht die beiden. Wenn sie übereinstimmen und der Benutzer über Berechtigungen verfügt, wird der Zugriff gewährt.

  • Unterstützte Browser: Internet Explorer 5 und höhere Versionen
  • Einschränkungen: Nicht so sicher wie integriert. Erfordert, dass der Server Zugriff auf einen Active Directory-Server hat, der für die Digestauthentifizierung eingerichtet ist.
  • Benutzerrechte erforderlich: Erfordert Kennwörter, um "Kennwort als verschlüsselten Klartext speichern" zu haben.
  • Verschlüsselungstyp: Basierend auf NONCE, die vom Server gesendet wird.

Windows Integriert (aufgeteilt in zwei Unterkategorien)

Kerberos – Der Server fordert einen Benutzer auf, sich anzumelden. Wenn der Browser Kerberos unterstützt, erfolgt Folgendes:

  • IIS fordert die Authentifizierung an.
  • Wenn sich der Client nicht bei einer Domäne angemeldet hat, wird in Internet Explorer ein Dialogfeld angezeigt, das Anmeldeinformationen anfordert, und kontaktiert dann den KDC, um ein Ticketgewährungsticket anzufordern und zu erhalten. Anschließend sendet er das Ticketgewährungsticket zusammen mit Informationen zum IIS-Server an den KDC.
  • Wenn sich der IE-Client bereits erfolgreich bei der Domäne angemeldet und ein Ticketgewährungsticket erhalten hat, sendet er dieses Ticket zusammen mit Informationen zum IIS-Server an den KDC.
  • Der KDC gibt dem Client ein Ressourcenticket aus.
  • Der Client übergibt dieses Ticket an den IIS-Server.

Kerberos verwendet Tickets, die bei einer Ticketgewährungsserver (KDC) zur Authentifizierung generiert werden. Dieses Ticket wird an den IIS-Server gesendet. Der Browser sendet das Kennwort des Benutzers NICHT an den Server.

  • Unterstützte Browser: Internet Explorer-Versionen 5.0 und höher
  • Einschränkungen: Der Server muss Zugriff auf einen Active Directory-Server haben. Sowohl der Server als auch der Client müssen über eine vertrauenswürdige Verbindung mit einem KDC verfügen.
  • Benutzerrechte erforderlich: Das auf dem Server definierte anonyme Benutzerkonto muss über lokale Berechtigungen verfügen.
  • Verschlüsselungstyp: Verschlüsseltes Ticket.

Windows NT Challenge/Response – Der Server fordert den Benutzer auf, sich anzumelden. Wenn der Browser Windows NT Challenge/Response unterstützt, sendet er automatisch die Anmeldeinformationen des Benutzers, wenn der Benutzer angemeldet ist. Wenn die Domäne, auf der sich der Benutzer befindet, sich von der Domäne des Servers unterscheidet oder der Benutzer nicht angemeldet ist, wird in Internet Explorer ein Dialogfeld angezeigt, in dem die zu sendenden Anmeldeinformationen angefordert werden. Windows NT Challenge/Response verwendet einen Algorithmus, um einen Hash basierend auf den Anmeldeinformationen des Benutzers und dem Computer zu generieren, den der Benutzer verwendet. Anschließend wird dieser Hash an den Server gesendet. Der Browser sendet das Kennwort des Benutzers nicht an den Server.

  • Unterstützte Browser: Internet Explorer-Versionen 3.01 und höher.
  • Einschränkungen: Erfordert Punkt-zu-Punkt-Verbindung. In der Regel wird ein Schaltkreis nach einer Fehlermeldung "401 nicht autorisiert" geschlossen; Beim Aushandeln einer Windows NT Challenge/Response-Authentifizierungssequenz (die mehrere Roundtrips erfordert), hält der Server den Schaltkreis jedoch für die Dauer der Sequenz geöffnet, nachdem der Client angegeben hat, dass er Windows NT Challenge/Response verwendet. CERN-Proxys und bestimmte andere Internetgeräte verhindern, dass dies funktioniert. Außerdem unterstützt Windows NT Challenge/Response keine Identitätswechsel mit doppelten Hops (d. h., dass nach der Übergabe an den IIS-Server dieselben Anmeldeinformationen nicht an einen Back-End-Server für die Authentifizierung übergeben werden können, z. B. wenn IIS Windows NT Challenge/Response verwendet, kann er den Benutzer nicht mit einer SQL Server-Datenbank auf einem anderen Computer mithilfe von SQL Integrated Security authentifizieren).
  • Benutzerrechte erforderlich: Das Benutzerkonto, das auf den Server zugreift, muss über berechtigungen "Zugriff auf diesen Computer aus dem Netzwerk" verfügen.
  • Verschlüsselungstyp: NTLM-Hashalgorithmus, der ebenfalls nicht codiert ist.

Rangfolgen: Wenn der Browser eine Anforderung vorlegt, wird immer die erste Anforderung als anonym betrachtet. Daher werden keine Anmeldeinformationen gesendet. Wenn der Server anonym nicht akzeptiert oder das auf dem Server festgelegte Benutzerkonto über keine Berechtigungen für die angeforderte Datei verfügt, antwortet der IIS-Server mit einer Fehlermeldung "Zugriff verweigert" und sendet eine Liste der Authentifizierungstypen, die mithilfe eines der folgenden Szenarien unterstützt werden:

  • Wenn Windows Integrated die einzige unterstützte Methode ist (oder wenn Anonym fehlschlägt), muss der Browser diese Methode unterstützen, um mit dem Server zu kommunizieren. Wenn dies fehlschlägt, versucht der Server keine der anderen Methoden.
  • Wenn "Basic" die einzige unterstützte Methode ist (oder wenn Anonym fehlschlägt), wird ein Dialogfeld angezeigt, um die Anmeldeinformationen abzurufen, und übergibt diese dann an den Server. Es versucht, die Anmeldeinformationen bis zu dreimal zu senden. Wenn dies alles fehlschlägt, stellt der Browser keine Verbindung mit dem Server her.
  • Wenn sowohl Basic als auch Windows Integrated unterstützt werden, bestimmt der Browser, welche Methode verwendet wird. Wenn der Browser Kerberos oder Windows NT Challenge/Response unterstützt, wird diese Methode verwendet. Sie fällt nicht auf "Basic" zurück. Wenn Windows NT Challenge/Response und Kerberos nicht unterstützt werden, verwendet der Browser "Basic", "Digest" oder "Fortezza", wenn er diese unterstützt. Die Reihenfolge der Rangfolge hier ist Basic, Digest und dann Fortezza.

Notiz

  • Wenn Ihr Browser eine Verbindung mit einer Website mithilfe der standard- oder der integrierten Windows-Authentifizierung herstellt, fällt er während der restlichen Sitzung mit dem Server nicht auf "Anonym" zurück. Wenn Sie versuchen, eine Verbindung mit einer Webseite herzustellen, die nach der Authentifizierung nur für "Anonym" gekennzeichnet ist, werden Sie verweigert. (Dies kann für Netscape wahr sein oder nicht.
  • Wenn Internet Explorer eine Verbindung mit dem Server hergestellt hat, indem eine andere Authentifizierungsmethode als Anonym verwendet wird, werden die Anmeldeinformationen für jede neue Anforderung während der Dauer der Sitzung automatisch übergeben.

References

Weitere Informationen zum Konfigurieren der IIS-Websiteauthentifizierung in Windows Server 2003 finden Sie unter Konfigurieren der IIS-Websiteauthentifizierung in Windows Server 2003.