IIS beschwert sich über einen gesperrten Bereich - wie kann ich herausfinden, wo er gesperrt ist?

Ich habe diesen Abschnitt in meiner web.config:

<system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
    <security>
        <authentication>
            <anonymousAuthentication enabled="true" />
            <windowsAuthentication enabled="true" />
        </authentication>
    </security>
</system.webServer>

IIS7 stürzt ab und beschwert sich über den Autientication-Bereich:

Modul AnonymousAuthenticationModule-
Benachrichtigung AuthenticateRequest-
Handler StaticFile-
Fehlercode 0x80070021
Konfigurationsfehler Dieser Konfigurationsabschnitt kann für diesen Pfad nicht verwendet werden. Dies geschieht, wenn der Abschnitt auf übergeordneter Ebene gesperrt ist. Das Sperren ist entweder standardmäßig (overrideModeDefault = "Deny") oder wird explizit durch ein Standort-Tag mit overrideMode = "Deny" oder dem Legacy-Wert allowOverride = "false" festgelegt.

Config Source  
   69:  <authentication>
   70:    <anonymousAuthentication enabled="true" />

Der übliche Weg, dies zu lösen, besteht darin, %windir%\system32\inetsrv\config\applicationHost.configden Abschnitt aufzurufen und freizuschalten:

    <sectionGroup name="system.webServer">
        <sectionGroup name="security">
            <section name="access" overrideModeDefault="Deny" />
            <section name="applicationDependencies" overrideModeDefault="Deny" />
            <sectionGroup name="authentication">
                <section name="anonymousAuthentication" overrideModeDefault="Allow" />
                <section name="basicAuthentication" overrideModeDefault="Allow" />
                <section name="clientCertificateMappingAuthentication" overrideModeDefault="Allow" />
                <section name="digestAuthentication" overrideModeDefault="Allow" />
                <section name="iisClientCertificateMappingAuthentication" overrideModeDefault="Allow" />
                <section name="windowsAuthentication" overrideModeDefault="Allow" />
            </sectionGroup>

(alternativ appcmd unlock config).

Das Seltsame: Ich habe das getan und es klagt immer noch.

Ich habe nach Standorten gesucht (MVC ist der Name meiner Website, der das Stammverzeichnis aller von mir verwendeten Websites ist):

<location path="MVC" overrideMode="Allow">
    <system.webServer overrideMode="Allow">
        <security overrideMode="Allow">
            <authentication overrideMode="Allow">
                <windowsAuthentication enabled="true" />
                <anonymousAuthentication enabled="true" />
            </authentication>
        </security>
    </system.webServer>
</location>

Trotzdem explodiert es. Ich bin verwirrt, warum das passiert. Ich kann es nicht aus der web.config entfernen, ich möchte das Root-Problem finden.

Gibt es eine Möglichkeit, bestimmte Informationen von IIS abzurufen, welche Regel mich letztendlich verweigert?

Bearbeiten: Ich konnte dieses Problem mithilfe der IIS7-Verwaltungskonsole beheben, indem ich mich im Stammverzeichnis (auf meinem Computer) befand, auf "Konfiguration bearbeiten" klickte und den dortigen Abschnitt entsperrte. Trotzdem würde ich gerne wissen, ob es einen besseren Weg gibt, da ich die Datei, die sie tatsächlich ändert, nicht finden kann.

Wir haben die folgenden Schritte ausgearbeitet, die das Problem für mich beheben:

1. Öffnen Sie den IIS-Manager
2. Klicken Sie im Baum links auf den Servernamen
3. Doppelklicken Sie im rechten Bereich, Abschnitt Verwaltung, auf Konfigurationseditor
4. Wählen Sie oben den Abschnitt aus system.webServer/security/authentication/anonymousAuthentication
5. Klicken Sie im rechten Bereich auf Abschnitt entsperren
6. Wählen Sie oben den Abschnitt aus system.webServer/security/authentication/windowsAuthentication
7. Klicken Sie im rechten Bereich auf Abschnitt entsperren

Dies löste meinen Fehler unter Windows Server 2012, IIS 8.5. Sollte auch für andere Versionen funktionieren.

1. Wechseln Sie zum Server-Manager , und klicken Sie auf Rollen und Funktionen hinzufügen
2. Wählen Sie im Bereich "Rollen" Folgendes aus: Webserver
3. Unter Sicherheitsunterabschnitt wählt alles (I ausgeschlossen verdauen, IP - Einschränkungen und URL - Autorisierung , da wir diese nicht in )
4. Wählen Sie unter Anwendungsentwicklung.NET Extensibility 4.5 und ASP>NET 4.5beide ISAPI-Einträge
5. In den Eigenschaften Abschnitt wählen: NET 3.5, .NET 4.5,ASP.NET 4.5
6. Im Web - Server - Abschnitt wählen: Web Server (all), Management Tools (IIS Management Console and Management Service),Windows

Konfigurationssperrung kann erfolgen bei:

1. Applicationhost.config (Konfigurationszeichenfolge: MACHINE / WEBROOT / APPHOST)

2. eine Site Web.config-Datei (MACHINE / WEBROOT / APPHOST / Name der Website)

3. Jede App web.config-Datei, die (MACHINE / WEBROOT / APPHOST / Site-Name / App-Name)

Durch das Sperren eines Abschnitts (z. B. Abschnitt: IIS-Konfigurationsabschnitt <asp>) können Sie die Möglichkeit verweigern, diese Einstellungen für alle Benutzer auf einer niedrigeren Hierarchieebene als Sie zu konfigurieren.

Das Verwenden der Feature Delegation-Funktion der GUI ist nicht verkehrt und ähnelt ganz genau dem, was AppCMD im Verborgenen tut. Hiermit wird OverrideMode für einen bestimmten Abschnitt in einem <location>Tag auf einer beliebigen Konfigurationsebene festgelegt, auf die Sie sich konzentrieren.

APPCMD kann zum Entsperren von Dateien verwendet werden. Achten Sie jedoch darauf, wo dies angezeigt wird - es ist nicht so intelligent wie die grafische Benutzeroberfläche.

Hinzufügen -commit:apphostzum Ende des APPCMD UNLOCKBefehls Ziele Applicationhost.config, das ist die Schlüsseldatei für IIS Betrieb (ersetzt die Metabasis aus früheren Versionen; speichert alle zentralen Einstellungen erlaubt aber überschreibt (wenn Sie das tun) in web.config - Dateien).

Ohne -commit: apphost ermittelt APPCMD den nächsten logischen Punkt für eine web.config-Datei - ob auf Site- oder App-Ebene - und gibt an, dass die Einstellung mithilfe einer Konfigurationszeichenfolge wie der oben angegebenen geändert wurde. (Abgesehen davon: Sie können immer noch nur auf die Einstellungen in Unterwebsites abzielen, aber auf apphost festlegen. Hierzu werden Standort-Tags verwendet.)

Wenn dort (Speicherparaphrase) "Änderungen an MACHINE / WEBROOT / APPHOST" steht, bedeutet dies die oberste Ebene der IIS-Hierarchie.

Wenn die Meldung "Für MACHINE / WEBROOT / APPHOST / Dodgy-Website festgeschrieben" angezeigt wird, bedeutet dies, dass der physische Pfad hinter der Dodgy-Website nachgeschlagen und an dieser Stelle eine web.config-Datei geschrieben (oder aktualisiert) wurde.

Wenn Sie IISExpress und Visual Studio 2015 verwenden, applicationHost.configwird das $(solutionDir).vs\config\applicationhost.config(dank der Antwort von Nime Cloud ) in gespeichert .

Ändern Sie einfach, overrideModeDefault="Allow"wo immer dies angebracht ist.

<sectionGroup name="security">
    <section name="access" overrideModeDefault="Deny" />
    <section name="applicationDependencies" overrideModeDefault="Deny" />
    <sectionGroup name="authentication">
        <section name="anonymousAuthentication" overrideModeDefault="Allow" />
etc...

Versuchen Sie es in Ihrem Anwendungspool. Deaktivieren Sie die Unterstützung von 32-Bit-Anwendungen. IIS-Manager -> Anwendungspools -> wählen Sie [Ihr AppPool] -> Erweiterte Einstellungen -> 32-Bit-Anwendungen aktivieren - ändern Sie den Wert in "Falsch".

Werfen Sie einen Blick auf IIS - dieser Konfigurationsabschnitt kann auf diesem Pfad nicht verwendet werden (Konfigurationssperre?)

Die akzeptierte Antwort hat unter Windows 10 einwandfrei funktioniert. Sie weist Folgendes an:

• Klicken Sie auf "Start"
• Geben Sie im Suchfeld "Windows-Funktionen aktivieren oder deaktivieren" ein.
• Klicken Sie im Funktionsfenster auf "Internetinformationsdienste".
• Klicken Sie auf: "World Wide Web Services"
• Klicken Sie auf "Anwendungsentwicklungsfunktionen".
• Überprüfen (aktivieren) Sie die Funktionen. Ich habe alles bis auf CGI überprüft.