IIS authentifiziert Browserclients

Artikel
03/21/2024

In diesem Artikel wird beschrieben, wie IIS Browserclients authentifiziert.

Ursprüngliche Produktversion: 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öhere Windows-Versionen 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.

Für Windows NT 4.0 verfügbare Authentifizierungsmethoden

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

Unterstützte Browser: Beliebig
Einschränkungen: Keine
Benutzerrechte erforderlich: Das anonyme Benutzerkonto, das auf dem Server definiert ist, muss über Lokale Anmeldeberechtigungen verfügen.
Verschlüsselungstyp: Keine

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

Unterstützte Browser: Beliebig
Einschränkungen: Nicht sicher. Kennwörter lassen sich leicht entschlüsseln.
Benutzerrechte erforderlich: Das Benutzerkonto muss über lokale Anmeldeberechtigungen verfügen.
Verschlüsselungstyp: Base64-Codierung (keine echte Verschlüsselung)

Windows NT-Herausforderung/-Antwort: 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, in 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 anzufordern sind. 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 Version 3.01 und höher
Einschränkungen: Erfordert Eine Punkt-zu-Punkt-Verbindung. In der Regel wird eine Verbindung nach der Fehlermeldung "401 nicht autorisiert" geschlossen. Beim Aushandeln einer Windows NT Challenge/Response-Authentifizierungssequenz (die mehrere Roundtrips erfordert), hält der Server die Verbindung 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 Doppelhop-Identitätswechsel (da nach der Übergabe an den IIS-Server die gleichen Anmeldeinformationen nicht an einen Back-End-Server zur Authentifizierung übergeben werden können).
Benutzerrechte erforderlich: Das Benutzerkonto, das auf den Server zugreift, muss über die 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 sendet, wird die erste Anforderung immer als anonym betrachtet. Daher werden keine Anmeldeinformationen gesendet. Wenn der Server Anonym nicht akzeptiert oder das auf dem Server festgelegte Anonyme Benutzerkonto nicht über Berechtigungen für die angeforderte Datei verfügt, antwortet der IIS-Server mit einer Fehlermeldung Vom Zugriff verweigert und sendet eine Liste der Authentifizierungstypen, die in einem der folgenden Szenarien unterstützt werden:

Wenn Windows NT Challenge/Response die einzige unterstützte Methode ist (oder wenn Anonymous fehlschlägt), muss der Browser diese Methode unterstützen, um mit dem Server zu kommunizieren. Andernfalls kann es nicht mit dem Server ausgehandelt werden, und der Benutzer erhält die Fehlermeldung Zugriff verweigert .
Wenn Basic die einzige unterstützte Methode ist (oder wenn Anonymous fehlschlägt), wird im Browser ein Dialogfeld angezeigt, um die Anmeldeinformationen abzurufen, und diese Anmeldeinformationen werden dann an den Server übergeben. Es wird versucht, diese Anmeldeinformationen bis zu dreimal zu senden. Wenn alle diese Fehler auftreten, 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, verwendet er diese Methode und greift nicht auf Basic zurück. Wenn Windows NT Challenge/Response nicht unterstützt wird, verwendet der Browser Basic.

Hinweis

Wenn Ihr Browser mithilfe oder der BasicNTLM Authentifizierung eine Verbindung mit einer Website 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 markiert ist, wird Ihnen dies verweigert. (Dies kann für Netscape zutreffen oder nicht).
Wenn internet Explorer eine Verbindung mit dem Server über Basic oder NTLM die Authentifizierung hergestellt hat, übergibt es die Anmeldeinformationen für jede neue Anforderung für die Dauer der Sitzung.

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 (standardmäßig IUSR_[Computername] ), um die Berechtigungen für die Dateien zu steuern. Der Browser sendet keine Anmeldeinformationen oder Benutzerinformationen mit dieser Art von Anforderung.

Unterstützte Browser: Beliebig
Einschränkungen: Keine
Benutzerrechte erforderlich: Das auf dem Server definierte anonyme Benutzerkonto muss über die Berechtigungen "Lokale Anmeldung" verfügen.
Verschlüsselungstyp: Keine

Unterstützte Browser: Beliebig
Einschränkungen: Nicht sicher. Kennwörter lassen sich leicht entschlüsseln.
Benutzerrechte erforderlich: Das Benutzerkonto muss über Lokale Anmelderechte verfügen.
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, um das Kennwort zu verschlüsseln, und sendet es an den Server. Der Server verschlüsselt dann seine eigene Kopie des Benutzerkennworts und vergleicht beide. 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: Kennwörter müssen über "Kennwort als verschlüsselten Klartext speichern" verfügen.
Verschlüsselungstyp: Basiert auf nonce, die vom Server gesendet wird.

Windows Integriert (unterteilt in zwei Unterkategorien)

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

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

Kerberos verwendet Tickets, die auf einem Ticket Granting Server (KDC) generiert wurden, um sich zu authentifizieren. 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 Anmeldeberechtigungen verfügen.
Verschlüsselungstyp: Verschlüsseltes Ticket.

Windows NT-Herausforderung/-Antwort: 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 sich die Domäne, in der sich der Benutzer befindet, von der Domäne des Servers unterscheidet oder der Benutzer nicht angemeldet ist, wird ein Dialogfeld im Internet angezeigt, Explorer das die zu sendenden Anmeldeinformationen anfordert. 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 Version 3.01 und höher.
Einschränkungen: Erfordert Eine Punkt-zu-Punkt-Verbindung. In der Regel wird eine Verbindung nach der Fehlermeldung "401 nicht autorisiert" geschlossen. Beim Aushandeln einer Windows NT Challenge/Response-Authentifizierungssequenz (die mehrere Roundtrips erfordert), hält der Server die Verbindung 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 Doppelhop-Identitätswechsel (d. h., sobald sie an den IIS-Server übergeben wurden, können dieselben Anmeldeinformationen nicht an einen Back-End-Server für die Authentifizierung übergeben werden, z. B. wenn IIS Windows NT Challenge/Response verwendet, kann der Benutzer dann nicht mithilfe der integrierten SQL-Sicherheit bei einer SQL Server Datenbank auf einem anderen Computer authentifiziert werden).
Benutzerrechte erforderlich: Das Benutzerkonto, das auf den Server zugreift, muss über die 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 sendet, wird die erste Anforderung immer als anonym betrachtet. Daher werden keine Anmeldeinformationen gesendet. Wenn der Server Anonym nicht akzeptiert oder das auf dem Server festgelegte Anonyme Benutzerkonto nicht über Berechtigungen für die angeforderte Datei verfügt, antwortet der IIS-Server mit der Fehlermeldung Zugriff verweigert und sendet eine Liste der Authentifizierungstypen, die in einem der folgenden Szenarien unterstützt werden:

Wenn Windows Integrated die einzige unterstützte Methode ist (oder wenn Anonymous 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 Anonymous fehlschlägt), wird ein Dialogfeld in der angezeigt, um die Anmeldeinformationen abzurufen, und übergibt diese dann an den Server. Es wird versucht, die Anmeldeinformationen bis zu dreimal zu senden. Wenn alle diese Fehler auftreten, 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. Es wird kein Fallback auf Basic ausgeführt. Wenn Windows NT Challenge/Response und Kerberos nicht unterstützt werden, verwendet der Browser Basic, Digest oder Fortezza, sofern diese unterstützt werden. Die Rangfolge lautet hier "Basic", "Digest" und dann "Fortezza".

Hinweis

Wenn Ihr Browser eine Verbindung mit einer Website mithilfe der standard- oder windows-integrierten Authentifizierung herstellt, wird während der restlichen Sitzung mit dem Server nicht auf Anonym zurückgegriffen. Wenn Sie versuchen, eine Verbindung mit einer Webseite herzustellen, die nur nach der Authentifizierung für Anonym markiert ist, werden Sie abgelehnt. (Dies kann für Netscape zutreffen oder nicht).
Wenn internet Explorer über eine andere Authentifizierungsmethode als Anonym eine Verbindung mit dem Server hergestellt hat, werden die Anmeldeinformationen für jede neue Anforderung während der Sitzungsdauer 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.