ASP.NET-Authentifizierungsprobleme auf IIS7 - User.Identity.Name ist für die Windows-Authentifizierung leer

8

Wir haben eine ASP.NET-Anwendung auf ASP.NET 4.0, die MVC 3 verwendet, die Windows-Authentifizierung verwendet.

Wenn Visual Studio 2010 ausgeführt wird, funktioniert alles wie erwartet, aber wenn der Rollout auf IIS7 ausgeführt wird, wird der angemeldete Windows-Benutzer nie ausgefüllt (Überprüfung von User.Identity.Name). Es wird auch keine Eingabeaufforderung für Benutzeranmeldeinformationen angezeigt.

Die Einstellung web.config:

%Vor%

In IIS kann ich sehen, dass die Windows-Authentifizierung aktiviert ist, ebenso wie Anonymous (Anonymous-Ergebnisse in einem Forbidden deaktivieren und kein Inhalt angezeigt wird).

Ich habe versucht, die "Kernel-Modus-Authentifizierung" zu aktivieren und zu deaktivieren (useKernelMode="true"), aber das scheint keinen Unterschied zu machen. Obwohl ich mich erinnere, dass wir diese Einstellung auf einer anderen Site auf einem anderen Server deaktivieren mussten, damit die Authentifizierung ordnungsgemäß funktioniert (möglicherweise auf ein potenzielles Problem im weiteren Verlauf des Stacks hinweisen?).

Falls es nützlich ist, von der applicationHost.config von IIS:

%Vor%

Irgendwelche Ideen, was das Problem sein könnte?

Vielen Dank im Voraus für Anregungen.

Update 1

Ich habe einen anderen IIS7-Server zum Testen gefunden und festgestellt, dass, wenn ich den anonymen Zugriff deaktiviert habe, alles wie gewünscht funktioniert hat. Jedoch habe ich immer noch Probleme auf dem ursprünglichen IIS7-Server, auch wenn ich den anonymen Zugriff ebenfalls deaktiviere (ich behalte Anonymous jetzt deaktiviert). Also muss es ein Problem geben, denke ich. Irgendwelche Ideen? Etwas, das ich reparieren muss, weil es immer wieder auftaucht und uns beißt, stelle ich mir vor.

Update 2

Wenn ich die Digestauthentifizierung für die IIS7-Problem-Box aktiviere, werde ich mit dem Anmeldedialog aufgefordert und alles funktioniert wie erwartet, wenn ich geeignete Zugangsdaten zur Verfügung stelle. Aber als interne Web-App mit Benutzern, die bereits in der Domäne angemeldet sind, möchten wir sie nicht wirklich auf diese Weise herausfordern. Anmeldeinformationen sollten transparent weitergegeben werden, da es auf der zweiten IIS7-Box funktioniert.

Update 3

Einige Fortschritte ... Ich habe festgestellt, dass, wenn sich die Webanwendung im Stammverzeichnis und nicht auf einer Untersite befindet, die Datei applicationHost.config für IIS7 mit den folgenden Authentifizierungseinstellungen direkt bearbeitet wird, damit die Site wie erwartet funktioniert:

%Vor%

Die Verwendung der IIS7-Benutzeroberfläche zur Konfiguration der Authentifizierung liefert nicht die richtigen Ergebnisse. Authentifizierungselemente fehlen entweder nach den Stationen (da IIS7 vermutlich davon ausgeht, dass sie vererbt werden) oder sie haben die falschen Einstellungen (windowsAuthentication scheint die oben angegebene Providerkonfiguration zu benötigen, um korrekt zu funktionieren).

Leider ist die fragliche Webanwendung tatsächlich eine Unteranwendung, da es eine interne Version (mit Windows-Authentifizierung & gt; www.site.com/internal) und eine externe Version (mit Formularauthentifizierung & gt; www.site.com/external) gibt ). Ich kann die Authentifizierung noch immer nicht als Unteranwendung verwenden. Ich erhalte nur einen "Error Code: 403 Forbidden".

    
Gavin 28.09.2011, 22:36
quelle

2 Antworten

3

In diesem Fall war es ein Microsoft ISA Server-Problem. Scheint, dass die Anforderung intern über ISA für die Windows-authentifizierte Site geroutet wurde. Sobald ISA entfernt wurde, verschwand das Problem.

Ich weiß nicht viel über ISA und wie es Anfragen weiterleitet, aber ich nehme an, dass es einige wichtige Informationen aus der Anfrage entfernt hat, wegen einer Regel, die jemand konfiguriert hat.

Als eine Randnotiz, falls es hilft, ähnliche Setups zu diagnostizieren: Ich wurde von den Netzwerkadministratoren darauf hingewiesen, dass interner Traffic nicht über ISA geroutet wurde, aber das interne Pingen der Webseite zeigte, dass ISA tatsächlich im Spiel war.

    
Gavin 25.03.2012, 21:59
quelle
0

Sie haben erwähnt, dass die Deaktivierung des anonymen Zugriffs auf einem anderen Server funktioniert hat, aber auf Ihrem Hauptserver sind 403 Fehler aufgetreten. Daher würde ich die dateibasierten Berechtigungen für den Ordner überprüfen, von dem aus Ihre Site ausgeführt wird. In der Vergangenheit musste ich dem \ Network Serivce-Konto die volle Kontrolle über den Site-Ordner und alle Unterordner erteilen, sonst würde ich 403 Fehler bekommen. Überprüfen Sie die Dateiberechtigungen auf dem funktionierenden Server und prüfen Sie, ob es Unterschiede zu dem Server gibt, der nicht funktioniert.

Auch wenn dies nicht das Problem ist, würde ich empfehlen, alle anderen IIS-Einstellungen zwischen den beiden Servern zu vergleichen, da Sie wissen, dass es auf der einen und nicht auf der anderen Seite funktioniert. Finde den Unterschied.

    
Paige Cook 29.09.2011 01:40
quelle