Partilhar via

Mensagem de erro ao tentar acessar um servidor localmente usando seu FQDN ou seu alias CNAME após a instalação do Windows Server 2003 Service Pack 1: Acesso 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.

Número original do KB: 926642

Observação

Este artigo contém informações que mostram como ajudar a reduzir as configurações de segurança ou como desativar os recursos de segurança em um computador. Você pode fazer essas alterações para solucionar um problema específico. Antes de fazer as alterações, é aconselhável avaliar os riscos associados à implementação desta solução alternativa no ambiente específico. Se você implementar essa solução alternativa, tome as medidas adicionais apropriadas para ajudar a proteger seu sistema.

Sintomas

Considere o cenário a seguir. 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 FQDN (nome de domínio totalmente qualificado) ou seu alias CNAME no caminho UNC (Convenção de Nomenclatura Universal): \\servername\sharename.

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 fornecido".
  • A ID do evento 537 é 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 deste 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:

  • \\Endereço IP do computador local
  • \\Netbiosname ou \\Nome_do_computador

Motivo

Esse problema ocorre porque o Windows Server 2003 SP1 inclui um novo recurso de segurança chamado funcionalidade de verificação de loopback. Por padrão, a funcionalidade de verificação 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 verificação 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, certifique-se de seguir essas etapas com atenção. Para proteção acrescida, faça backup do Registro antes de modificá-lo. Em, é possível restaurar o Registro caso ocorra um problema. Para obter mais informações sobre como fazer backup e restaurar o Registro, consulte Como fazer backup e restaurar o Registro no Windows.

Observação

Essa solução alternativa pode tornar seu computador ou sua rede mais vulnerável a ataques de usuários mal-intencionados ou de software mal-intencionado, como vírus. Essa solução alternativa não é recomendável, mas é fornecida para que você possa implementá-la conforme desejar. Você é responsável pelo uso dessa solução alternativa.

Para resolver esse problema, defina a entrada do Registro DisableStrictNameChecking como 1. Em seguida, use 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, clique 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 Dados do valor, digite o CNAME ou o alias 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: Desative a verificação de loopback de autenticação

Reabilite o comportamento existente no Windows Server 2003 definindo a entrada do 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, clique 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 de Dados de valor, digite 1 e, em seguida, 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 verificação de loopback é ativada no Windows Server 2003 SP1 e a entrada do Registro DisableLoopbackCheck é definida como 0 (zero). A segurança é reduzida quando você desabilita a verificação de loopback de autenticação e abre o servidor Windows Server 2003 para ataques MITM (man-in-the-middle) em 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 o 957097 de atualização de segurança, aplicativos como o SQL Server ou o IIS (Serviços de Informações da Internet) podem falhar ao fazer solicitações de autenticação NTLM local.

Para obter mais informações sobre como resolver esse problema, consulte a seção "Problemas conhecidos com esta atualização de segurança" do artigo da base de dados 957097.