Ich habe eine ASP.NET MVC 3-Intranetsite mit aktivierter Windows-Authentifizierung erstellt:
<authentication mode="Windows"/>
Der anonyme Zugriff ist für all diese drei oben deaktiviert, die web.config sagt <deny users="?"/> . Identitätswechsel ist in der Datei web.config durch die Identität <impersonate="false"/> und in den Websiteeigenschaften auf dem IIS 7.5-Server deaktiviert. Und schließlich ist der NETWORK SERVICE so eingestellt, dass er den App-Pool ausführt und auch den Site-Ordner gelesen hat (nicht sicher, ob er benötigt wird, aber das ist nicht genug, um mein Problem zu lösen).
Wenn sich Benutzer nun über das Standarddialogfeld Windows-Authentifizierung anmelden, erhalten Domänenbenutzer nach drei gültigen Anmeldeversuchen einen 401.3-Fehler. Dies scheint zu sein, bevor sogar der Code meiner MVC-Site erreicht wird, d. H. Es scheint vollständig IIS-bezogen zu sein. Das Ereignisprotokoll gibt die folgende Art von Eintrag (es ist ein Information-Eintrag, kein Fehler, und ich habe es ein wenig verschleiert, um meinen Client zu schützen) für alle Benutzer, die versucht haben, sich anzumelden:
%Vor% Nur wenn ich USER-AD\teh-user oder USER-AD\Domain Benutzern die Berechtigung Read im Stammordner der Site (D: \ Public \ BlahblahManager) ausdrücklich erteilt, kann sich der Benutzer anmelden und die Site tatsächlich sehen.
Warum ist das? Es muss eine Art von Konfiguration geben, die ich vermisse. Sollte es nicht ausreichen, dass der NETWORK SERVICE den Stammordner der Site gelesen hat? Ich habe das eine Weile gegoogelt, und hier und da wird die Personifikation erwähnt, aber die Jury scheint immer noch nicht da zu sein. Einige Websites behaupten, dass Sie mit Identitätswechsel gehen sollten, und sie geben Beispiele dafür, wie es geht, aber wenn ich die Beispiele ausprobiere, funktioniert es immer noch nicht. Andere Websites sagen, dass Identitätswechsel NICHT der richtige Weg ist und dass Sie in diesen Fällen die Ordnerberechtigungen gewähren müssen. Aber das scheint so seltsam zu sein. Benutzer haben keine Geschäfte auf dem tatsächlichen Server, sie sollten nur über die Website arbeiten.
Irgendwelche Vorschläge? Was ist normalerweise die minimale Konfigurationsmenge, die benötigt wird, um dies zum Laufen zu bringen? Irgendwelche Tipps, wie Sie diese Art von Problem beheben und zur Ursache gelangen können?
Ich verweise Sie auf Beitrag , der alle MVC-Authentifizierungsmethoden deklariert. Stellen Sie jedoch sicher, dass Sie die mindestens erforderliche Authentifizierung für Ihre mvc-Anwendung aktiviert haben. Beachten Sie, dass die anonyme Authentifizierung mit Ihren Gruppenrichtlinien funktioniert. Sie können das folgendermaßen konfigurieren: Internetoptionen - & gt; Registerkarte Sicherheit - & gt; Lokales Intranet - & gt; Benutzerdefinierte Ebene, in Ihrem Browser.
1- Eine andere Sache, die das Problem verursachen kann, ist, dass IIS möglicherweise nicht für autorisierte verwandte Benutzer konfiguriert ist. Einige von ihnen sind:
2- Überprüfen Sie auch die zulässigen Verben in IIS.
3- Im Stammverzeichnis Ihrer Anwendung Geben Sie Lesezugriff auf IIS AppPool \ YourAppPool.
4 - Eine weitere Ursache könnten hierarchische Zugriffsregeln in Ihrer Anwendung sein, die davon abhängen, welche Anwendungsdienste Sie verwenden, z. B. Zugangsregeln für Websitespaneele.
5- Einstellung der Datei clientaccesspolicy.xml.
6- Check InitializeService () -Methode, setzen Sie Entitätszugriffsregeln richtig? Zum Beispiel:
%Vor%7 - Überprüfen Sie das FileAuthentication-Modul auf der Website-Ebene.
Doppelprüfung Anonyme Authentifizierung ist in IIS aktiviert. Sehen Sie sich auch diesen Beitrag an.
Wir haben auch mit diesem Problem gekämpft und Sicherheitsgruppen eingerichtet, um unseren Benutzern Berechtigungen auf Dateiebene zu geben. Dann stolperte einer unserer Serveradministratoren über einige neue Eigenschaften, die es der App erlaubten, sich unter festgelegten Anmeldedaten am Dateisystem zu authentifizieren, und löste die Notwendigkeit, dass die Benutzer Zugriff hatten. Hier ist, was er sich ausgedacht hat ...
Es gibt zwei IIS-Einstellungen, die dies steuern:
Physische Pfad Anmeldeinformationen Physische Pfad Anmeldeinformationen Anmeldetyp
Standardmäßig ist Physical Path Credentials auf Application User festgelegt (Passthrough-Authentifizierung) Dies bedeutet, dass IIS keine ausführt Identitätswechsel bei der Behandlung von Windows-Authentifizierungsanfragen. Das kann, jedoch auf einen bestimmten Benutzer festgelegt werden (leider nicht Anwendungspoolidentität, die ideal wäre). Physischer Pfad Anmeldeart Anmeldeart ist standardmäßig auf Clear-Text eingestellt. Für meine Tests Ich setze dies auf Interaktiv (obwohl dies möglicherweise nicht der richtige Wert ist). Mögliche Werte sind Clear-Text, Stapel, Interaktiv und Netzwerk.
Um das einzurichten, habe ich Folgendes getan:
- Ein lokales Konto (IIS-AccessUser) erstellt
- Zugewiesener IIS-AccessUser liest und führt den Zugriff auf das Verzeichnis / home der Site aus.
- IIS-AccessUser zur IIS_IUSRS-Gruppe hinzugefügt (erforderlich für den Zugriff auf temporäre .NET-Dateien)
- Legen Sie IIS-AccessUser als physische Pfadanmeldeinformationen fest
- Anmeldungsart für physische Pfadanmeldeinformationen auf Interaktiv setzen
Durch das obige Vorgehen konnte ich mich direkt bei der Anwendung anmelden. ohne authentifizierte Benutzer zu erlauben, oder ich muss ein Mitglied einer der Gruppen im Ordner / home. Es auch noch Bewährte .NET Autorisierungsrollen, sodass ich immer noch nicht auf Teile zugreifen konnte von der Seite, die ich nicht durfte.
Sie müssen keine Dateizugriffsberechtigungen erteilen, wenn Sie die Windows-Authentifizierung in IIS 7.0 und IIS 7.5 verwenden.
Es gibt einen besseren Weg, den wir nur entdecken konnten, weil unser Server-Administrator die Sicherheits- und Verwaltungsprobleme roch, die entstehen, wenn man Benutzern und Gruppen Zugriff auf Dateiebene gewährt.
Wenn Sie sich mit diesem Problem befassen oder einen neuen IIS7 / IIS7.5-Server einrichten und / oder von IIS 6 wechseln, finden Sie hier einen Artikel, in dem Sie alle erforderlichen Windows-Authentifizierungsoptionen und -konfigurationen finden geändert, um zu verhindern, dass Einzelpersonen oder Gruppen Zugriff auf Dateiebene gewährt wird.
Bitte lesen Sie die beiden Kommentare am Ende des POST für einige gültige Kritiken der in diesem Artikel verwendeten Methoden.
Beachten Sie zusätzlich zu den Informationen in diesem Artikel, dass IIS 7.5 die Webkonfigurationstags für system.web nicht verwendet (zumindest nicht in meiner MVC 4-Anwendung).
Es sucht in den system.webserver -Tags nach Autorisierungskonfiguration (wo Sie die Windows-Domäne \ Gruppen auflisten müssen, die ein Benutzer sein muss, um auf Ihre Anwendung zuzugreifen).
- DSB
Tags und Links asp.net-mvc-3 iis-7.5 windows-authentication acl http-status-code-401