O controlador de domínio não está funcionando corretamente

Este artigo fornece resoluções comuns para o problema em que o controlador de domínio não está funcionando corretamente.

Aplica-se a: Windows Server 2012 R2
Número original do KB: 837513

Sintomas

Ao executar a ferramenta Dcdiag em um controlador de domínio baseado no Microsoft Windows Server 2000 ou no Windows Server 2003, você pode receber a seguinte mensagem de erro:

Diagnóstico do controlador de domínio
Realizando a configuração inicial:
[DC1] A associação LDAP falhou com o erro 31

Ao executar o utilitário REPADMIN /SHOWREPS localmente em um controlador de domínio, você poderá receber uma das seguintes mensagens de erro:

[D:\nt\private\ds\src\util\repadmin\repinfo.c, 389] Erro LDAP 82 (Erro local).

Falha na última tentativa @ aaaa-mm-dd hh:mm.ss, resultado 1753: Não há mais pontos de extremidade disponíveis no mapeador de pontos de extremidade.

Falha na última tentativa @ aaaa-mm-dd hh:mm.ss, resultado 5: Acesso negado.

Se você usar os Serviços e Sites do Active Directory para disparar a replicação, poderá receber uma mensagem indicando o acesso negado.

Ao tentar usar recursos de rede do console de um controlador de domínio afetado, incluindo recursos UNC ou unidades de rede mapeadas, você pode receber a seguinte mensagem de erro:

Não há servidores de logon disponíveis (c000005e = "STATUS_NO_LOGON_SERVERS")

Se você iniciar qualquer ferramenta administrativa do Active Directory no console de um controlador de domínio afetado, incluindo Serviços e Sites do Active Directory e Usuários e Computadores Usuários e Computadores do Active Directory, poderá receber uma das seguintes mensagens de erro:

As informações de nomenclatura não podem ser localizadas porque: nenhuma autoridade pôde ser contatada para autenticação. Entre em contato com o administrador do sistema para verificar se o domínio está corretamente configurado e está online no momento.

As informações de nomenclatura não podem ser localizadas porque: o nome da conta de destino está incorreto. Entre em contato com o administrador do sistema para verificar se o domínio está corretamente configurado e está online no momento.

Os clientes do Microsoft Outlook conectados a computadores com Microsoft Exchange Server que usam controladores de domínio afetados para autenticação podem ser solicitados a inserir credenciais de logon, mesmo que haja uma autenticação de logon bem-sucedida de outros controladores de domínio.

A ferramenta Netdiag talvez exiba as seguintes mensagens de erro:

Teste de lista DC. . . . . . . . . . . : Falha
[AVISO] Não é possível chamar DsBind para <servername>.<fqdn> (<endereço ip>). [ERRO_CONTROLADOR_DE_DOMÍNIO_NÃO_ENCONTRADO]
Teste de Kerberos. . . . . . . . . . . : Falha
[FATAL] O Kerberos não tem um tíquete para krbtgt/<fqdn>.

[FATAL] O Kerberos não tem um tíquete para <hostname>.
Teste LDAP. . . . . . . . . . . . . : Passou
[AVISO] Falha ao consultar o registro SPN no DC <hostname><fqdn>

O seguinte evento pode ser registrado no log de eventos do sistema do controlador de domínio afetado:

Event Type: Error
Event Source: Service Control Manager
Event ID: 7023
Description: The Kerberos Key Distribution Center service terminated with the following error: The security account manager (SAM) or local security authority (LSA) server was in the wrong state to perform the security operation.

Resolução

Existem várias resoluções para esses sintomas. Veja a seguir uma lista de métodos para tentar. A lista acompanha etapas para realizar cada método. Experimente cada método até o problema ser resolvido. Artigos da Base de Dados de Conhecimento Microsoft que descrevem correções menos comuns para esses sintomas estão listados posteriormente.

1. Método 1: Corrigir erros do Sistema de Nomes de Domínio (DNS).
2. Método 2: Sincronizar o horário entre os computadores.
3. Método 3: Verificar os direitos de usuário para Acesso a este computador através da rede.
4. Método 4: Verificar se o atributo userAccountControl do controlador de domínio é 532480.
5. Método 5: Corrigir o realm do Kerberos (confirmar que as chaves do Registro PolAcDmN e PolPrDmN são correspondentes).
6. Método 6: Redefinir a senha da conta de máquina e, em seguida, obter um novo tíquete do Kerberos.

Método 1: Corrigir erros de DNS

1. No prompt de comando, execute o comando netdiag -v. Esse comando cria um arquivo Netdiag.log na pasta em que o comando foi executado.
2. Resolva quaisquer erros de DNS no arquivo Netdiag.log antes de continuar. A ferramenta Netdiag está disponível nas Ferramenta de Suporte do Windows 2000 Server, no CD-ROM do Windows 2000 Server, ou como um download.
3. Certifique-se de que o DNS esteja configurado corretamente. Um dos erros de DNS mais comuns é apontar o controlador de domínio para um provedor de serviços de Internet (ISP) para DNS em vez de apontar o DNS para si próprio ou para outro servidor DNS que ofereça suporte a atualizações dinâmicas e registros SRV. Recomendamos que você aponte o controlador de domínio para si próprio ou para outro servidor DNS que ofereça suporte para atualizações dinâmicas e registros SRV. Recomendamos que você configure encaminhadores ao ISP para obter a resolução de nomes na Internet.

Para obter mais informações sobre como configurar o DNS para o serviço de diretório Active Directory, clique nos números a seguir para visualizar os artigos correspondentes na Base de Dados de Conhecimento Microsoft:
254680 Planejamento de namespaces DNS

Método 2: Sincronizar a hora entre os computadores

Verifique se o horário está corretamente sincronizado entre os controladores de domínio. Além disso, verifique se o horário está corretamente sincronizado entre computadores clientes e controladores de domínio.

Método 3: Verificar os direitos de usuário para "Acesso a este computador através da rede"

Modifique o arquivo Gpttmpl.inf para confirmar que os usuários apropriados têm o direito de usuário Acesso a este computador pela rede no controlador de domínio. Para fazer isso, siga estas etapas:

1. Modifique o arquivo Gpttmpl.inf para a Política de Controladores de Domínio Padrão. Por padrão, a Política de Controladores de Domínio Padrão é onde os direitos dos usuários são definidos para um controlador de domínio. Por padrão, o arquivo Gpttmpl.inf da Política de Controladores de Domínio Padrão está localizado na seguinte pasta.

   Observação

   Sysvol pode estar em um local diferente, mas o caminho para o arquivo Gpttmpl.inf será o mesmo.

   Para controladores de domínio do Windows Server 2003:

   C:\WINDOWS\Sysvol\Sysvol\<Domainname>\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

   Para controladores de domínio do Windows 2000 Server:

   C:\WINNT\Sysvol\Sysvol\<Domainname>\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

2. À direita da entrada SeNetworkLogonRight, adicione os identificadores de segurança para Administradores, Usuários Autenticados e Todos. Consulte os exemplos a seguir.

   Para controladores de domínio do Windows Server 2003:

   SeNetworkLogonRight = *S-1-5-32-554,*S-1-5-9,*S-1-5-32-544,*S-1-1-0

   Para controladores de domínio do Windows 2000 Server:

   SeNetworkLogonRight = *S-1-5-11,*S-1-5-32-544,*S-1-1-0

   Observação

   Administradores (S-1-5-32-544), Usuários Autenticados (S-1-5-11), Todos (S-1-1-0) e Controladores Corporativos (S-1-5-9) usam identificadores de segurança conhecidos que são idênticos em todos os domínios.

3. Remova quaisquer entradas à direita da entrada SeDenyNetworkLogonRight (Negar acesso a este computador através da rede) para corresponder ao exemplo a seguir.

   SeDenyNetworkLogonRight =

   Observação

   O exemplo é o mesmo para o Windows 2000 Server e para o Windows Server 2003.

   Por padrão, o Windows 2000 Server não possui entradas na entrada SeDenyNetworkLogonRight. Por padrão, o Windows Server 2003 possui apenas a conta Support_random string na entrada SeDenyNetworkLogonRight. (A conta Support_random string é usada por Assistência Remota.) Como a conta Support_random string usa um identificador de segurança (SID) diferente em cada domínio, não é possível diferenciá-la facilmente de uma conta de usuário típica apenas observando o SID. Talvez você queira copiar o SID para outro arquivo de texto e, em seguida, remover o SID da entrada SeDenyNetworkLogonRight. Dessa forma, você poderá recolocá-lo quando terminar de solucionar o problema.

   SeNetworkLogonRight e SeDenyNetworkLogonRight podem ser definidos em qualquer política. Se as etapas anteriores não resolverem o problema, verifique o arquivo Gpttmpl.inf em outras políticas em Sysvol para confirmar que os direitos de usuários também não estão sendo definidos lá. Se um arquivo Gpttmpl.inf não contiver referências a SeNetworkLogonRight ou SeDenyNetworkLogonRight, essas configurações não estão definidas na política e, portanto, esta última não está causando o problema. Se essas entradas existem, certifique-se de que elas correspondam às configurações listadas anteriormente para a política de Controlador de Domínio Padrão.

Método 4: Verificar se o atributo userAccountControl do controlador de domínio é 532480.

1. Clique em Iniciar, Executar e digite adsiedit.msc.
2. Expanda o DOMÍNIO NC, expanda DC=domínio e expanda OU=Controladores de Domínio.
3. Clique com o botão direito do mouse no controlador de domínio afetado e depois clique em Propriedades.
4. No Windows Server 2003, clique para marcar as caixas de seleção Mostrar atributos obrigatórios e Mostrar atributos opcionais na guia Editor de Atributos. No Windows 2000 Server, clique em Ambos na caixa Selecionar quais propriedades exibir.
5. No Windows Server 2003, clique em userAccountControl na caixa Atributos. No Windows 2000 Server, clique em userAccountControl na caixa Selecione uma propriedade para exibir.
6. Se o valor não for 532480, digite 532480 na caixa Editar Atributo, clique em Definir, depois clique em Aplicar e em OK.
7. Feche o Editor ADSI.

Método 5: Corrigir o realm do Kerberos (confirmar que as chaves do Registro PolAcDmN e PolPrDmN são correspondentes).

1. Inicie o Editor do Registro.
2. No painel esquerdo, expanda Segurança.
3. No menu Segurança, clique em Permissões para conceder ao grupo local de Administradores o Controle Total sobre o hive SEGURANÇA e seus contêineres e objetos filho.
4. Localize a chave HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN.
5. No painel à direita do Editor do Registro, clique uma vez na entrada <No Name>: REG_NONE.
6. No menu Exibir, clique em Exibir Dados Binários. Na seção Formato da caixa de diálogo, clique em Byte.
7. O nome do domínio aparece como uma cadeia de caracteres no lado direito da caixa de diálogo Dados Binários. O nome do domínio é o mesmo que o realm Kerberos.
8. Localize a chave do Registro HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN.
9. No painel à direita do Editor do Registro, clique duas vezes na entrada <No Name>: REG_NONE.
10. Na caixa de diálogo Editor Binário, cole o valor de PolPrDmN. (O valor de PolPrDmN será o nome de domínio NetBIOS).
11. Reinicie o controlador de domínio.

Método 6: Redefinir a senha da conta de máquina e, em seguida, obter um novo tíquete do Kerberos

1. Pare o serviço Centro de Distribuição de Chaves Kerberos e defina o valor de inicialização como Manual.

2. Use a ferramenta Netdom nas Ferramentas de Suporte do Windows 2000 Server ou nas Ferramentas de Suporte do Windows Server 2003 para redefinir a senha da conta da máquina do controlador de domínio:

   netdom resetpwd /server: <another domain controller> /userd:domain\administrator /passwordd: <administrator password>  
   

   Certifique-se de que o comando netdom retorne como concluído com êxito. Em caso negativo, significa que o comando não funcionou. Para o domínio Contoso, em que o controlador de domínio afetado é DC1 e um controlador de domínio de trabalho é DC2, execute o seguinte comando netdom a partir do console do DC1:

   netdom resetpwd /server:DC2 /userd:contoso\administrator /passwordd: <administrator password>
   

3. Reinicie o controlador de domínio afetado.

4. Inicie o serviço do Centro de Distribuição de Chaves Kerberos e defina a configuração de inicialização como Automático.

Para obter informações adicionais sobre este problema, clique nos números abaixo para ler os artigos na Base de Dados de Conhecimento Microsoft (alguns artigos podem estar em inglês):
323542 Não é possível iniciar a ferramenta Usuários e Computadores do Active Directory porque o servidor não está operacional