IIS se plaint d'une section verrouillée. Comment puis-je savoir où elle est verrouillée?

J'ai cette section dans mon web.config:

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

IIS7 se bloque et se plaint de la section Autientication:

Module AnonymousAuthenticationModule
Notification
Gestionnaire AuthenticateRequest StaticFile
Error Code 0x80070021
Erreur de configuration Cette section de configuration ne peut pas être utilisée sur ce chemin. Cela se produit lorsque la section est verrouillée au niveau parent. Le verrouillage est soit par défaut (overrideModeDefault = "Deny"), soit défini explicitement par une balise d'emplacement avec overrideMode = "Deny" ou par le legs allowOverride = "false".

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

Donc, la façon habituelle de résoudre ce problème consiste à %windir%\system32\inetsrv\config\applicationHost.configouvrir et à déverrouiller la section:

    <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>

(alternativement appcmd unlock config).

La chose étrange: je l'ai fait et il se plaint toujours.

J'ai cherché des emplacements (MVC est le nom de mon site Web qui est la racine de tous les sites que j'utilise):

<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>

Ça explose quand même. Je suis perplexe quant à pourquoi cela se produit. Je ne peux pas le supprimer du web.config, je veux trouver le problème racine.

Existe-t-il un moyen d'obtenir des informations spécifiques d'IIS dont la règle me refuse finalement?

Éditer: J'ai pu résoudre ce problème à l'aide de la console de gestion IIS7 en allant à la racine même (ma machine), en cliquant sur "Modifier la configuration" et en déverrouillant la section correspondante. J'aimerais quand même savoir s'il existe un meilleur moyen, car je ne trouve pas le fichier qu'il modifie réellement.

Élaboré ces étapes qui résolvent le problème pour moi:

1. Ouvrez le gestionnaire IIS
2. Cliquez sur le nom du serveur dans l'arborescence à gauche
3. Volet de droite, section Gestion, double-cliquez sur l'éditeur de configuration
4. En haut, choisissez la section system.webServer/security/authentication/anonymousAuthentication
5. Dans le volet de droite, cliquez sur Déverrouiller la section.
6. En haut, choisissez la section system.webServer/security/authentication/windowsAuthentication
7. Dans le volet de droite, cliquez sur Déverrouiller la section.

Cela a résolu mon erreur sur Windows Server 2012, IIS 8.5. Devrait fonctionner pour d'autres versions aussi.

1. Allez dans le Gestionnaire de serveur , cliquez sur Ajouter des rôles et des fonctionnalités.
2. Dans la section des rôles, choisissez: Serveur Web
3. Dans la sous-section Sécurité , choisissez tout (j'ai exclu Digest, les restrictions IP et l'autorisation d'URL, car nous ne les utilisons pas).
4. Sous Développement d'applications, choisissez .NET Extensibility 4.5et ASP>NET 4.5, les deux entrées ISAPI.
5. Dans la Caractéristiques section choisissez: NET 3.5, .NET 4.5,ASP.NET 4.5
6. Dans le serveur Web section choisissez: Web Server (all), Management Tools (IIS Management Console and Management Service),Windows

Le verrouillage de la configuration peut se produire à:

1. Applicationhost.config (chaîne de configuration: MACHINE / WEBROOT / APPHOST)

2. un fichier de site Web.config (MACHINE / WEBROOT / APPHOST / nom du site Web)

3. Tout fichier web.config d'application qui (MACHINE / WEBROOT / APPHOST / Nom du site / Nom de l'application)

Verrouiller une section (section: section de configuration IIS, par exemple <asp>) vous permet de refuser la possibilité de configurer ces paramètres à quiconque se trouvant à un niveau inférieur de la hiérarchie.

Utiliser la fonction de délégation de fonctions de l'interface graphique n'est pas une erreur, et fait la même chose que ce que fait AppCMD, sous les couvertures - définit OverrideMode pour une section donnée dans une <location>balise, quel que soit le niveau de configuration sur lequel vous vous concentrez.

APPCMD peut être utilisé pour déverrouiller des fichiers, mais soyez attentif aux endroits où il est écrit: ce n'est pas aussi intelligent que l'interface graphique.

Ajout -commit:apphostà la fin de vos APPCMD UNLOCKcibles de commande Applicationhost.config, qui est le fichier de clé pour l'opération IIS (remplace la métabase des versions antérieures; stocke tous les paramètres centralisés mais autorise les remplacements (si vous le faites) dans les fichiers web.config).

Sans -commit: apphost, APPCMD cible l'emplacement logique le plus proche pour un fichier web.config - que ce soit au niveau du site ou de l'application, et indique qu'il a modifié le paramètre à l'aide d'une chaîne de configuration similaire à celle définie ci-dessus. (De plus, vous pouvez toujours cibler uniquement les paramètres des sous-sites Web, mais valider sur apphost. Il utilise des balises d'emplacement pour y parvenir.)

Donc, si elle disait (paraphrase de la mémoire) "Modifications validées dans MACHINE / WEBROOT / APPHOST", cela signifierait le niveau supérieur de la hiérarchie IIS.

S'il est écrit "engagé dans MACHINE / WEBROOT / APPHOST / Dodgy Web Site", cela signifierait qu'il recherchait le chemin physique derrière le site Web Dodgy et écrivait un fichier web.config (ou le mettait à jour) à cet emplacement.

Si vous utilisez IISExpress et Visual Studio 2015, le applicationHost.configest stocké dans $(solutionDir).vs\config\applicationhost.config(grâce à la réponse de Nime Cloud ).

Il suffit de changer si nécessaire overrideModeDefault="Allow".

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

Essayez dans votre pool d’application, désactivez les applications 32 bits qui prennent en charge le Gestionnaire IIS -> Pools d’applications -> sélectionnez [Votre AppPool] -> Paramètres avancés -> Activer les applications 32 bits - définissez-le sur 'False'

Jetez un coup d'œil à IIS - cette section de configuration ne peut pas être utilisée sur ce chemin (verrouillage de la configuration?)

La réponse acceptée a parfaitement fonctionné pour moi sur Windows 10, elle demande de procéder comme suit:

• Cliquez sur le bouton "Démarrer"
• dans le champ de recherche, entrez "Activer ou désactiver les fonctionnalités de Windows"
• dans la fenêtre des fonctionnalités, cliquez sur "Services Internet"
• Cliquez sur "Services World Wide Web"
• Cliquez sur "Fonctionnalités de développement d'applications"
• Cochez (activez) les fonctionnalités. J'ai vérifié tout sauf CGI.