65 votos

IIS se queja de una sección bloqueada, ¿cómo puedo averiguar dónde está bloqueada?

Tengo esta sección en mi web.config:

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

IIS7 se bloquea y se queja de la sección de autenticación:

Módulo AnonymousAuthenticationModule
Notificación AuthenticateRequest
Manejador StaticFile
Código de error 0x80070021
Config Error Esta sección de configuración no se puede utilizar en esta ruta. Esto ocurre cuando la sección está bloqueada en un nivel superior. El bloqueo es por defecto (overrideModeDefault="Deny"), o establecido explícitamente por una etiqueta de ubicación con overrideMode="Deny" o el legado allowOverride="false".

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

Así que la forma habitual de resolver esto es entrar en %windir%\system32\inetsrv\config\applicationHost.config y desbloquear la sección:

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

(alternativamente, appcmd unlock config ).

Lo raro: lo he hecho y sigue quejándose.

Busqué Ubicaciones (MVC es el nombre de mi sitio web que es root de todos los sitios que estoy usando):

<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ún así, explota. Estoy desconcertado de por qué sucede esto. No puedo quitarlo del web.config, quiero encontrar el problema de root.

¿Hay alguna forma de obtener información específica de IIS sobre qué regla me está negando finalmente?

Editar: Pude arreglar esto usando la consola de administración de IIS7 yendo a la misma root (mi máquina) y haciendo clic en "Editar configuración" y desbloqueando la sección allí. Aun así me gustaría saber si hay una forma mejor ya que no encuentro el archivo que realmente modifica.

0 votos

De memoria, normalmente hay una sección en el 500.19 que le dice qué archivo en qué ubicación está en cuestión, en la parte inferior (creo)

1 votos

Esto se ha respondido muy bien sobre el SO

98voto

tomfanning Puntos 1709

He encontrado estos pasos que solucionan el problema:

  1. Abrir el Administrador de IIS
  2. Haga clic en el nombre del servidor en el árbol de la izquierda
  3. Panel derecho, sección Gestión, doble clic en Editor de configuración
  4. En la parte superior, elija la sección system.webServer/security/authentication/anonymousAuthentication
  5. Panel derecho, haga clic en Desbloquear sección
  6. En la parte superior, elija la sección system.webServer/security/authentication/windowsAuthentication
  7. Panel derecho, haga clic en Desbloquear sección

1 votos

¿Tiene esto un equivalente en PowerShell? Me gustaría poder scribir esto.

0 votos

Si encuentras uno, no dudes en publicarlo :)

0 votos

Lo haré, esperaba que alguien supiera ya cómo.

17voto

Esto resolvió mi error en Windows Server 2012, IIS 8.5. Debería funcionar también para otras versiones.

  1. Ir a Administrador de servidores , haga clic en añadir Funciones y características
  2. En la sección de roles elige: Servidor web
  3. En Seguridad sub-sección elija todo (excluí el resumen, las restricciones de IP y la autorización de URL, ya que no los usamos)
  4. En Desarrollo de aplicaciones elija .NET Extensibility 4.5 y ASP>NET 4.5 , ambas entradas ISAPI
  5. En el Características sección elegir: NET 3.5 , .NET 4.5 , ASP.NET 4.5
  6. En el Servidor web sección elegir: Web Server (all) , Management Tools (IIS Management Console and Management Service) , Windows

7voto

TristanK Puntos 6159

El bloqueo de la configuración puede ocurrir en:

  1. Applicationhost.config (cadena de configuración: MACHINE/WEBROOT/APPHOST)

  2. un archivo Web.config del sitio (MACHINE/WEBROOT/APPHOST/Nombre del sitio web)

  3. Cualquier archivo web.config de la aplicación que (MÁQUINA/WEBROOT/APPHOST/Nombre del sitio/Nombre de la aplicación)

Bloquear una sección (sección: Sección de configuración de IIS, por ejemplo <asp> ) te permite negar la capacidad de configurar esos ajustes a cualquier persona que se encuentre en un nivel jerárquico inferior al tuyo.

El uso de la función de delegación de la interfaz gráfica de usuario no está mal, y hace algo muy similar a lo que hace AppCMD, bajo las cubiertas - establece OverrideMode para una sección determinada en un <location> en cualquier nivel de configuración en el que te centres.

APPCMD puede usarse para desbloquear archivos, pero presta atención a dónde dice que lo hace - no es tan inteligente como la GUI al respecto.

Añadir -commit:apphost al final de su APPCMD UNLOCK se dirige a Applicationhost.config, que es el archivo de claves para el funcionamiento de IIS (sustituye a la metabase de versiones anteriores; almacena todas las configuraciones centralizadas pero permite anularlas (si lo hace) en los archivos web.config).

Sin -commit:apphost, APPCMD se dirigirá al lugar lógico más cercano para un archivo web.config - ya sea a nivel de sitio o de aplicación, e indicará que ha cambiado la configuración utilizando una cadena de configuración como la establecida anteriormente. (Nota: puede seguir apuntando sólo a las configuraciones en los sub-sitios web, pero commit a apphost - utiliza etiquetas de ubicación para lograrlo)

Así que si dijera (parafraseando la memoria) "Changes committed to MACHINE/WEBROOT/APPHOST" , eso significaría el nivel superior de la jerarquía de IIS.

Si dice "comprometido con MACHINE/WEBROOT/APPHOST/Dodgy Web Site", eso significaría que buscó la ruta física detrás de Dodgy Web Site, y escribió un archivo web.config (o lo actualizó) en esa ubicación.

5voto

Yoshi Puntos 1023

Si está utilizando IISExpress y Visual Studio 2015, el applicationHost.config se almacena en $(solutionDir).vs\config\applicationhost.config (gracias a Nime Cloud's responder ).

Sólo cambia overrideModeDefault="Allow" siempre que sea apropiado.

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

1voto

jaywon Puntos 3820

Pruebe en su Applicaiton Pool, desactivar el soporte de aplicaciones de 32 bits IIS Manager -> Application Pools -> seleccione [Your AppPool] -> Advanced Settings -> Enable 32-Bit Applications - cambie a 'False'

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: