O IIS reclama de uma seção bloqueada - como posso descobrir onde ela está bloqueada?

44

Eu tenho esta seção no meu web.config:

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

O IIS7 trava e reclama da seção de autienticação:

Module AnonymousAuthenticationModule
Notification AuthenticateRequest
Handler StaticFile
Error Code 0x80070021
Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

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

Assim, a maneira usual de resolver isso é entrar em %windir%\system32\inetsrv\config\applicationHost.config e desbloquear a seção:

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

A coisa estranha: eu fiz isso e ainda reclama.

Procurei Locations (MVC é o nome do meu site que é a raiz de todos os sites que estou 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>

Ainda explode. Estou intrigado sobre o porquê isso acontece. Não consigo removê-lo do web.config, quero encontrar o problema raiz.

Existe uma maneira de obter informações específicas do IIS cuja regra está eventualmente me negando?

Editar: Consegui consertar isso usando o console de gerenciamento do IIS7 indo até a própria raiz (minha máquina) e clicando em "Editar configuração" e desbloqueando a seção lá. Ainda assim, gostaria de saber se existe uma maneira melhor, pois não consigo encontrar o arquivo realmente modificado.

    
por Michael Stum 15.02.2012 / 17:48

6 respostas

68

Desenvolvemos estes passos para corrigir o problema:

  1. Abra o Gerenciador do IIS
  2. Clique no nome do servidor na árvore à esquerda
  3. Painel da direita, seção Gerenciamento, clique duas vezes em Editor de configuração
  4. Na parte superior, escolha a seção system.webServer/security/authentication/anonymousAuthentication
  5. painel da direita, clique em Desbloquear seção
  6. Na parte superior, escolha a seção system.webServer/security/authentication/windowsAuthentication
  7. painel da direita, clique em Desbloquear seção
por 19.06.2013 / 13:40
10

Isso resolveu meu erro Windows Server 2012, IIS 8.5. Deve funcionar para outras versões também.

  1. Vá para Gerenciador de servidores , clique em adicionar Funções e recursos
  2. Na seção de funções, escolha: Servidor da Web
  3. Na subseção Segurança , escolha tudo (excluí digest, restrições de IP e autorização de URL, pois não os usamos)
  4. Em Desenvolvimento de aplicativos , escolha .NET Extensibility 4.5 e ASP>NET 4.5 , ambas entradas ISAPI
  5. Na seção Recursos , escolha: NET 3.5 , .NET 4.5 , ASP.NET 4.5
  6. Na seção Servidor Web , escolha: Web Server (all) , Management Tools (IIS Management Console and Management Service) , Windows
por 25.04.2015 / 15:41
4

O bloqueio de configuração pode acontecer em:

  1. Applicationhost.config (string de configuração: MACHINE / WEBROOT / APPHOST)

  2. um arquivo Web.config do site (MACHINE / WEBROOT / APPHOST / Nome do site)

  3. Qualquer arquivo web.config do aplicativo que (MACHINE / WEBROOT / APPHOST / Nome do site / Nome do aplicativo)

Bloquear uma seção (seção: seção de configuração do IIS, por exemplo, <asp> ) permite negar a capacidade de definir essas configurações para qualquer pessoa em um nível inferior na hierarquia que você.

Usar a Delegação de Recursos da GUI não é errado, e faz uma coisa muito parecida com o que o AppCMD faz, sob as coberturas - define OverrideMode para uma seção em uma tag <location> em qualquer nível de configuração que você está focado em.

O APPCMD pode ser usado para desbloquear arquivos, mas preste atenção em onde ele diz que está fazendo isso - não é tão inteligente quanto a GUI sobre isso.

Adicionar -commit:apphost ao final do seu comando APPCMD UNLOCK é o aplicativo Applicationhost.config, que é o arquivo para a operação do IIS (substitui a metabase de versões anteriores; armazena todas as configurações centralizadas, mas permite substitui (se você fizer) em arquivos web.config).

Sem -commit: apphost, o APPCMD segmentará o ponto lógico mais próximo para um arquivo web.config - seja no nível do site ou do aplicativo, e indica que ele alterou a configuração usando uma string de configuração como o conjunto acima. (Além: você ainda pode direcionar apenas as configurações em sub-sites, mas comprometer-se a aprofost - ele usa tags de localização para realizar isso)

Então, se ele disse (paráfrase de memória) "Alterações confirmadas no MACHINE / WEBROOT / APPHOST", isso significaria o nível superior da hierarquia do IIS.

Se estiver escrito "comprometido com o MACHINE / WEBROOT / APPHOST / Dodgy Web Site", isso significa que ele pesquisou o caminho físico por trás do Dodgy Web Site e escreveu um arquivo web.config (ou o atualizou) naquele local. .

    
por 15.02.2012 / 22:11
1

Se você estiver usando o IISExpress e o Visual Studio 2015, o applicationHost.config será armazenado em $(solutionDir).vs\config\applicationhost.config (graças ao resposta ).

Altere apenas overrideModeDefault="Allow" , sempre que apropriado.

<sectionGroup name="security">
    <section name="access" overrideModeDefault="Deny" />
    <section name="applicationDependencies" overrideModeDefault="Deny" />
    <sectionGroup name="authentication">
        <section name="anonymousAuthentication" overrideModeDefault="Allow" />
etc...
    
por 03.08.2018 / 21:20
0

Experimente em seu pool de aplicativos, desabilite o suporte a aplicativos de 32 bits Gerenciador do IIS - > Pools de aplicativos - > selecione [Seu AppPool] - > Configurações avançadas - > Ativar aplicativos de 32 bits - altere para 'False'

    
por 10.12.2013 / 20:40
-2

Dê uma olhada IIS - esta seção de configuração não pode ser usada neste caminho (bloqueio de configuração?)

A resposta aceita funcionou perfeitamente para mim no Windows 10, ele instrui para fazer o seguinte:

  • Clique no botão "Iniciar"
  • na caixa de pesquisa, digite "Ativar ou desativar recursos do Windows"
  • na janela de recursos, clique em: "Serviços de Informações da Internet"
  • Clique em: "Serviços da World Wide Web"
  • Clique em: "Recursos de desenvolvimento de aplicativos"
  • Verifique (ative) os recursos. Eu chequei tudo, exceto CGI.
por 30.06.2017 / 19:13