Mensagem de erro quando você tenta acessar um servidor localmente usando seu FQDN ou seu alias CNAME depois de instalar o Windows Server 2003 Service Pack 1: Access negado ou Nenhum provedor de rede aceitou o caminho de rede fornecido

  • Artigo

Este artigo fornece uma solução para um erro que ocorre quando você tenta acessar um servidor localmente usando seu FQDN ou seu alias CNAME.

Aplica-se a: Windows 7 Service Pack 1, Windows Server 2012 R2
Número de KB original: 926642

Observação

Este artigo contém informações que mostram como ajudar a reduzir as configurações de segurança ou como desativar recursos de segurança em um computador. Você pode fazer essas alterações para contornar um problema específico. Antes de fazer essas alterações, recomendamos que você avalie os riscos associados à implementação dessa solução alternativa em seu ambiente específico. Se você implementar essa solução alternativa, siga as etapas adicionais apropriadas para ajudar a proteger seu sistema.

Sintomas

Considere o seguinte cenário. Você instala o Microsoft Windows Server 2003 Service Pack 1 (SP1) em um computador baseado no Windows Server 2003. Depois de fazer isso, você enfrenta problemas de autenticação ao tentar acessar um servidor localmente usando seu nome de domínio totalmente qualificado (FQDN) ou seu alias CNAME no caminho da Convenção Universal de Nomenclatura (UNC):\nomede nome deservidor\.

Nesse cenário, você experimenta um dos seguintes sintomas:

  • Você recebe janelas de logon repetidas.
  • Você recebe uma mensagem de erro "Acesso negado".
  • Você recebe uma mensagem de erro "Nenhum provedor de rede aceitou o caminho de rede determinado".
  • A ID do evento 537 está registrada no log de eventos de segurança.

Observação

Você pode acessar o servidor usando seu FQDN ou seu alias CNAME de outro computador na rede diferente desse computador no qual você instalou o Windows Server 2003 SP1. Além disso, você pode acessar o servidor no computador local usando os seguintes caminhos:

  • \\IPaddress-of-local-computer
  • \\Netbiosname ou \\ComputerName

Motivo

Esse problema ocorre porque o Windows Server 2003 SP1 inclui um novo recurso de segurança chamado loopback marcar funcionalidade. Por padrão, a funcionalidade de marcar de loopback é ativada no Windows Server 2003 SP1 e o valor da entrada do registro DisableLoopbackCheck é definido como 0 (zero).

Observação

A funcionalidade de marcar de loopback é armazenada na subchave do registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck.

Resolução

Importante

Esta seção, método ou tarefa contém etapas que descrevem como modificar o Registro. Entretanto, sérios problemas poderão ocorrer caso você modifique o Registro incorretamente. Portanto, siga essas etapas cuidadosamente. Para mais proteção, faça o backup do registro antes de modificá-lo. Em seguida, você poderá restaurar o registro se ocorrer um problema. Para saber mais sobre como fazer o backup e restaurar o registro, consulte Como fazer o backup e restaurar o registro no Windows.

Observação

Essa solução alternativa pode tornar seu computador ou rede mais vulnerável a ataques de usuários mal-intencionados ou softwares mal-intencionados, como vírus. Não recomendamos essa solução alternativa, mas estamos fornecendo essas informações para que você possa implementar essa solução alternativa a seu próprio critério. Você é responsável pelo uso dessa solução alternativa.

Para resolve esse problema, defina a entrada do registro DisableStrictNameChecking como 1. Em seguida, use qualquer um dos métodos a seguir, conforme apropriado para sua situação.

Para fazer isso, siga estas etapas para todos os nós no computador cliente:

  1. Clique em Iniciar e, em Executar, digite regedit e clique em OK.

  2. Localize e clique na seguinte subchave do Registro:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

  3. Clique com o botão direito do mouse em MSV1_0, aponte para Novo e clique em Valor de Várias Cadeias de Caracteres.

  4. Na coluna Nome , digite BackConnectionHostNames e pressione ENTER.

  5. Clique com o botão direito do mouse em BackConnectionHostNames e clique em Modificar.

  6. Na caixa de dados Valor , digite o alias CNAME ou DNS, que é usado para os compartilhamentos locais no computador e clique em OK.

    Observação

    • Digite cada nome de host em uma linha separada.
    • Se a entrada do registro BackConnectionHostNames existir como um tipo de REG_DWORD, você precisará excluir a entrada do registro BackConnectionHostNames.

  7. Saia do Editor do Registro e reinicie o computador.

Método 2: desabilitar o marcar de loopback de autenticação

Habilite novamente o comportamento existente no Windows Server 2003 definindo a entrada de registro DisableLoopbackCheck na HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry subchave como 1. Para definir a entrada do registro DisableLoopbackCheck como 1, siga estas etapas no computador cliente:

  1. Clique em Iniciar e, em Executar, digite regedit e clique em OK.

  2. Localize e clique na seguinte subchave do Registro:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

  3. Clique com o botão direito do mouse em Lsa, aponte para Novo e clique em Valor DWORD .

  4. Digite DisableLoopbackCheck e pressione ENTER.

  5. Clique com o botão direito do mouse em DisableLoopbackCheck e clique em Modificar.

  6. Na caixa Dados do valor, digite 1 e clique em OK.

  7. Saia do Editor do Registro.

  8. Reinicie o computador.

Observação

Você deve reiniciar o servidor para que essa alteração entre em vigor. Por padrão, a funcionalidade de marcar de loopback é ativada no Windows Server 2003 SP1 e a entrada do registro DisableLoopbackCheck é definida como 0 (zero). A segurança é reduzida quando você desabilitar o loopback de autenticação marcar e você abre o servidor Windows Server 2003 para ataques MITM (homem no meio) no NTLM.

Status

A Microsoft confirmou que esse é um problema nos produtos da Microsoft listados no início deste artigo.

Mais informações

Depois de instalar 957097 de atualização de segurança, aplicativos como SQL Server ou Serviços de Informações da Internet (IIS) podem falhar ao fazer solicitações locais de autenticação NTLM.

Para obter mais informações sobre como resolve esse problema, consulte a seção "Problemas conhecidos com essa atualização de segurança" do artigo do KB 957097.