Identitätswechsel in IIS 7.0

Question

Ich habe eine Website, die unter IIS 6.0 korrekt funktioniert:Es authentifiziert Benutzer mit Windows-Anmeldeinformationen und übergibt dann die Anmeldeinformationen, wenn es mit dem Dienst kommuniziert, der auf die Datenbank zugreift.

In IIS 7.0 übergeben dieselben Konfigurationseinstellungen die Anmeldeinformationen nicht und die Datenbank wird mit NT AUTHORITY\ANONYMOUS getroffen.

Fehlt mir etwas?Ich habe den ANONYMEN Zugriff auf meiner IIS 7.0-Website deaktiviert, aber ich bekomme das Ding nicht zum Laufen.

Dies sind die Einstellungen, die ich sowohl für IIS 6.0 als auch für 7.0 verwende:

<authentication mode="Windows">
<identity impersonate="true">

Was hat sich von 6.0 auf 7.0 geändert?

Answer 1

Es gab Änderungen zwischen IIS7 und IIS6.0.Ich habe für Sie einen Blog-Beitrag gefunden, der Ihnen tatsächlich helfen könnte (Klicken Sie hier, um es zu sehen).

Führen Sie Ihre Anwendung im integrierten Modus oder im klassischen Modus aus?Soweit ich gesehen habe, sollte das Setzen des Impersonate-Attributs auf „true“ einen 500-Fehler mit der folgenden Fehlermeldung anzeigen:

Interner Serverfehler.Dies ist HTTP -Fehler 500.19:Auf die angeforderte Seite kann nicht zugegriffen werden, da die zugehörigen Konfigurationsdaten für die Seite ungültig sind.

Hier ist die vorgeschlagene Problemumgehung:

Problemumgehung:

1) Wenn sich Ihre Anwendung nicht auf die Identität des anfordernden Benutzer in den Stadien von BeginneRequest und authenticateRequest beruht (die einzigen Phasen, in denen die Imitation im integrierten Modus nicht möglich ist), ignorieren Sie diesen Fehler, indem Sie das Web.Config dem folgenden Hinweis auf die folgende Anwendung hinzufügen:

<validation validateIntegratedModeConfiguration="false"

/>

2) Wenn Ihre Bewerbung auf Startrequest und authenticateRequest aufweicht, oder Sie nicht sicher sind, wandeln Sie sich nicht sicher in den klassischen Modus.

Ich hoffte, dass dies hilfreich war, um zu verstehen, wie IIS 7.0 jetzt funktioniert.

Answer 2

Ist Ihr IIS-Server so eingerichtet, dass er für die Delegierung durch den SQLServer vertrauenswürdig ist?Ich bin schon einmal auf dieses Problem bei WebDAV gestoßen, bei dem der Server, auf dem IIS ausgeführt wird, vom Dateiserver als vertrauenswürdig eingestuft werden musste, um sich im Namen des Dateiservers authentifizieren zu können.

Answer 3

Interessant...Ich habe das gegenteilige Problem - Nicht in der Lage sein um die Authentifizierung vom Client-Browser über den Webserver und über Firewalls an die Datenbank innerhalb eines großen Unternehmensnetzwerks weiterzuleiten.

Ich halte auch die „End-to-End-Benutzer“-Authentifizierung bei der Datenbank für eine schlechte Idee und ein potenzielles Sicherheitsrisiko.Nichts hindert den Endbenutzer daran, SQL Query zu laden und eine direkte Verbindung zu Ihrer Datenbank herzustellen. Daher sollten Sie Ihr Schema besser sperren!

@Esteban – Hat meine Meinung geklärt nicht sehr nützlich, um Ihnen zu helfen Antwort.

Answer 4

Wenn Sie eine solche Double-Hop-Authentifizierung durchführen, ist in der Regel Kerberos beteiligt, es sei denn, die erste Authentifizierung ist Basic.

Ich würde die Authentifizierung auf den IIS 6-Servern überprüfen und sicherstellen, dass sie auch auf IIS 7 identisch ist.

Wenn das Feld „IIS 6“ auf „Windows integriert“ eingestellt ist, müssen Sie die Kerberos-Einstellungen überprüfen – SPNs, Delegierung usw.