IIS authentifiziert Browserclients

Artikel
01/25/2022
8 Minuten Lesedauer

In diesem Artikel wird erläutert, 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öher Windows Versionen verfügbar sind. Eine ausführlichere Beschreibung der informationen, die in diesem Artikel behandelt werden, finden Sie in den Ressourcenhandbüchern Windows NT 4.0 und Windows 2000.

Für Windows NT 4.0 verfügbare Authentifizierungsmethoden

Anonym – Es ist keine Anmeldung erforderlich, und jeder Benutzer kann auf Daten zugreifen, 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
Erforderliche Benutzerrechte: Das auf dem Server definierte anonyme Benutzerkonto muss über lokale Anmeldeberechtigungen verfügen.
Verschlüsselungstyp: Keine

Einfach (Klartext): Der Server fordert den Benutzer zur Anmeldung auf, und im Browser wird ein Dialogfeld angezeigt, in dem der Benutzer die erforderlichen Anmeldeinformationen eingeben kann. Diese Anmeldeinformationen müssen mit den Anmeldeinformationen übereinstimmen, die für die Dateien definiert sind, auf die der Benutzer zuzugreifen versucht.

Unterstützte Browser: alle
Einschränkungen: Nicht sicher. Kennwörter können leicht entschlüsselt werden.
Erforderliche Benutzerrechte: 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 zur Anmeldung auf. Wenn der Browser Windows NT Challenge/Response unterstützt, werden die Anmeldeinformationen des Benutzers automatisch gesendet, 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 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 eine Punkt-zu-Punkt-Verbindung. In der Regel wird eine Schaltung nach einer Fehlermeldung "401 nicht autorisiert" geschlossen. Beim Aushandeln einer Windows NT Challenge/Response-Authentifizierungssequenz (die mehrere Roundtrips erfordert) hält der Server die Schaltung 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. Darüber hinaus unterstützt Windows NT Challenge/Response keine Double-Hop-Identitätswechsel (d. h., nachdem sie an den IIS-Server übergeben wurden, können dieselben Anmeldeinformationen nicht zur Authentifizierung an einen Back-End-Server übergeben werden).
Erforderliche Benutzerrechte: Das Benutzerkonto, das auf den Server zugreift, muss über die Berechtigungen "Über das Netzwerk auf diesen Computer zugreifen" verfügen.
Verschlüsselungstyp: NTLM-Hashalgorithmus, der ebenfalls nicht codiert ist.

Rangfolgen: Wenn der Browser eine Anforderung sendet, wird immer davon aus, dass die erste Anforderung anonym ist. Daher werden keine Anmeldeinformationen gesendet. Wenn der Server "Anonym" nicht akzeptiert ODER wenn das auf dem Server festgelegte anonyme Benutzerkonto nicht über Berechtigungen für die angeforderte Datei verfügt, antwortet der IIS-Server mit einer Fehlermeldung "Zugriff verweigert" und sendet eine Liste der Authentifizierungstypen, die mit 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 für die Kommunikation mit dem Server unterstützen. Andernfalls kann er nicht mit dem Server aushandeln, 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 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 Authentifizierung eine Verbindung mit einer Website Basic NTLM herstellt, greift er während der restlichen Sitzung mit dem Server nicht auf "Anonym" zurück. Wenn Sie versuchen, eine Verbindung mit einer Webseite herzustellen, die erst nach der Authentifizierung für Anonym gekennzeichnet ist, wird ihnen dies verweigert. (Dies gilt möglicherweise oder nicht für Netscape).
Wenn Internet Explorer mithilfe oder Authentifizierung eine Verbindung mit dem Server hergestellt Basic NTLM 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 Benutzer kann auf daten zugreifen, 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
Erforderliche Benutzerrechte: Das auf dem Server definierte anonyme Benutzerkonto muss über "Anmeldeberechtigungen lokal" verfügen.
Verschlüsselungstyp: Keine

Unterstützte Browser: alle
Einschränkungen: Nicht sicher. Kennwörter können leicht entschlüsselt werden.
Erforderliche Benutzerrechte: 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 zum Verschlüsseln des Kennworts und sendet diese 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.
Erforderliche Benutzerrechte: Erfordert, dass Kennwörter "Kennwort als verschlüsselten Klartext speichern" vorhanden sind.
Verschlüsselungstyp: Basierend auf vom Server gesendeter NONCE.

Windows Integriert (in zwei Unterkategorien aufgeteilt)

Kerberos: Der Server fordert einen Benutzer zur Anmeldung an. 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 in Internet Explorer ein Dialogfeld angezeigt, in dem Anmeldeinformationen angefordert werden. Anschließend wird der KDC kontaktiert, um ein Ticketgewährungsticket anzufordern und zu erhalten. Anschließend wird das Ticket-Granting-Ticket zusammen mit Informationen zum IIS-Server an den KDC gesendet.
Wenn sich der IE-Client bereits erfolgreich bei der Domäne angemeldet hat und ein Ticket granting Ticket 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 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.
Erforderliche Benutzerrechte: Das auf dem Server definierte anonyme Benutzerkonto muss über lokale Anmeldeberechtigungen verfügen.
Verschlüsselungstyp: Verschlüsseltes Ticket.

Windows NT Challenge/Response: Der Server fordert den Benutzer zur Anmeldung auf. Wenn der Browser Windows NT Challenge/Response unterstützt, werden die Anmeldeinformationen des Benutzers automatisch gesendet, 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 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 eine Punkt-zu-Punkt-Verbindung. In der Regel wird eine Schaltung nach einer Fehlermeldung "401 nicht autorisiert" geschlossen. Beim Aushandeln einer Windows NT Challenge/Response-Authentifizierungssequenz (die mehrere Roundtrips erfordert) hält der Server die Schaltung 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. Darüber hinaus unterstützt Windows NT Challenge/Response keine Double-Hop-Identitätswechsel (d. h., nachdem sie an den IIS-Server übergeben wurden, können dieselben Anmeldeinformationen nicht zur Authentifizierung an einen Back-End-Server übergeben werden, z. B. wenn IIS Windows NT Challenge/Response verwendet, kann der Benutzer nicht SQL Server mithilfe von SQL Integrierte Sicherheit).
Erforderliche Benutzerrechte: Das Benutzerkonto, das auf den Server zugreift, muss über die Berechtigungen "Über das Netzwerk auf diesen Computer zugreifen" verfügen.
Verschlüsselungstyp: NTLM-Hashalgorithmus, der ebenfalls nicht codiert ist.

Rangfolgen: Wenn der Browser eine Anforderung sendet, wird immer davon aus, dass die erste Anforderung anonym ist. Daher werden keine Anmeldeinformationen gesendet. Wenn der Server "Anonym" nicht akzeptiert oder wenn das auf dem Server festgelegte anonyme Benutzerkonto nicht über Berechtigungen für die angeforderte Datei verfügt, antwortet der IIS-Server mit einer Fehlermeldung "Zugriff verweigert" und sendet eine Liste der Authentifizierungstypen, die mit 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 für die Kommunikation mit dem Server unterstützen. 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 angezeigt, in dem die Anmeldeinformationen abgerufen werden, und diese werden dann an den Server übergeben. Es wird versucht, die Anmeldeinformationen bis zu dreimal zu senden. Wenn alle 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 nicht auf Basic zurückfallen. Wenn Windows NT Challenge/Response und Kerberos nicht unterstützt werden, verwendet der Browser Basic, Digest oder Fortezza, wenn er diese unterstützt. Die Rangfolge lautet hier Einfach, Digest und dann Fortezza.

Hinweis

Wenn Ihr Browser eine Verbindung mit einer Website mithilfe der standardbasierten oder Windows integrierten Authentifizierung herstellt, greift er während der restlichen Sitzung mit dem Server nicht auf Anonym zurück. Wenn Sie versuchen, eine Verbindung mit einer Webseite herzustellen, die erst nach der Authentifizierung für Anonym gekennzeichnet ist, wird ihnen dies verweigert. (Dies gilt möglicherweise oder nicht für Netscape).
Wenn Internet Explorer eine Verbindung mit dem Server mithilfe einer anderen Authentifizierungsmethode als Anonym hergestellt hat, 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.