web-dev-qa-db-fra.com

IIS se plaint d'une section verrouillée - comment 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 d'authentification:

Module AnonymousAuthenticationModule
Notification AuthenticateRequest
Gestionnaire StaticFile
Code d'erreur 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 l'héritage allowOverride = "false".

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

Donc, la façon habituelle de résoudre ce problème est d'aller dans %windir%\system32\inetsrv\config\applicationHost.config et déverrouillez 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 ça continue de se plaindre.

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>

Mais ça explose. Je ne comprends pas 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 de IIS quelle règle me refuse finalement?

Edit: J'ai pu résoudre ce problème en utilisant la console de gestion IIS7 en allant à la racine même (ma machine) et en cliquant sur "Modifier la configuration" et déverrouiller la section là-bas. J'aimerais tout de même savoir s'il existe une meilleure solution car je ne trouve pas le fichier qu'il modifie réellement.

iis-7web.config
59
Michael Stum

A travaillé ces étapes qui résolvent le problème pour moi:

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

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

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

Le verrouillage de la configuration peut se produire à:

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

  2. un fichier 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: IIS section de configuration, par exemple <asp>) vous permet de refuser la possibilité de configurer ces paramètres à quiconque à un niveau inférieur dans la hiérarchie que vous.

L'utilisation de la fonction de délégation de fonctionnalités de l'interface graphique n'est pas mauvaise et fait une chose très similaire à ce que fait AppCMD, sous les couvertures - définit OverrideMode pour une section donnée dans un <location> tag quel que soit le niveau de configuration sur lequel vous vous concentrez.

APPCMD peut être utilisé pour déverrouiller des fichiers, mais faites attention à l'endroit où il est dit - ce n'est pas aussi intelligent que l'interface graphique à ce sujet.

Ajouter -commit:apphost à la fin de votre APPCMD UNLOCK la commande cible 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 ciblera l'emplacement logique le plus proche pour un fichier web.config - que ce soit au niveau du site ou de l'application, et indiquera qu'il a changé le paramètre à l'aide d'une chaîne de configuration comme l'ensemble ci-dessus. (En plus: vous pouvez toujours cibler uniquement les paramètres dans les sous-sites Web, mais vous engagez sur apphost - il utilise des balises de localisation pour accomplir cela)

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

S'il indique "engagé sur MACHINE/WEBROOT/APPHOST/Dodgy Web Site", cela signifie qu'il a recherché le chemin physique derrière Dodgy Web Site et a écrit un fichier web.config (ou l'a mis à jour) à cet emplacement.

5
TristanK

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

Modifiez simplement overrideModeDefault="Allow" Chaque fois que cela est approprié.

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

Essayez dans votre pool d'applications, désactivez la prise en charge des applications 32 bits IIS Manager -> Pools d'applications -> sélectionnez [Votre AppPool] -> Paramètres avancés -> Activer les applications 32 bits - changez-le en ' Faux'

1
JohnR