Os servidores membros do Active Directory não podem localizar o controlador de domínio

4

Várias horas atrás, alguns de nossos servidores membros ficaram impossibilitados de autenticar os dois controladores de domínio que deveriam estar usando. Os servidores membros e o DC estão localizados no mesmo datacenter e estão em um "site" separado no AD. A execução do DCDiag não apresenta problemas e confirmamos que os servidores e os DCs têm conectividade de rede entre si. Executar o nslookup nos servidores membro mostra o DC apropriado listado como o servidor de nomes em cada caso.

A autenticação LDAP parece estar funcionando, no entanto, a autenticação Kerberos parou de funcionar. Basicamente, todos os principais serviços internos pararam.

Aqui estão alguns detalhes sobre alguns dos problemas que estamos tendo com servidores membros:

Exchange - Topology Service cannot find any domain controllers. Therefore, the Exchange Information Store cannot start.

SharePoint - Authentication is failing at the IIS level and between IIS and SQL (this farm has been up for mutliple years).

Resolução de problemas adicionais:

NLTEST /DCLIST:domainname - No DC can be found to get a DC List

NLTEST /Server:Servername - Both DCs Complete Successfully.

NLTEST /DSGetDC:Domain - Commands complete sucessfully.

NLTEST /dsgetsite - Completes successfully.

GPUpdate - User cannot be found. No domain exists

Saída de nslookup -type=SRV _kerberos._tcp.dc._msdcs.subdomain.mydomain.com no servidor de troca:

Server:  colo-dc-001.subdomain.mydomain.com
Address:  10.11.2.20

_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = branchf-dc-001.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = colo-dc-001.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = hq-dc-003.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = colo-dc-002.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = hq-dc-004.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = branchc-dc-002.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = branchm-dc-001.subdomain.mydomain.com
_kerberos._tcp.dc._msdcs.subdomain.mydomain.com SRV service location:
      priority       = 0
      weight         = 100
      port           = 88
      svr hostname   = branchs-dc-001.subdomain.mydomain.com
branchf-dc-001.subdomain.mydomain.com   internet address = 10.10.2.22
colo-dc-001.subdomain.mydomain.com  internet address = 10.11.2.20
hq-dc-003.subdomain.mydomain.com    internet address = 10.1.2.20
colo-dc-002.subdomain.mydomain.com  internet address = 10.11.2.21
hq-dc-004.subdomain.mydomain.com    internet address = 10.1.2.21
branchc-dc-002.subdomain.mydomain.com   internet address = 10.5.2.21
branchm-dc-001.subdomain.mydomain.com   internet address = 10.6.2.21
branchs-dc-001.subdomain.mydomain.com   internet address = 10.7.2.22

Podemos RDP para qualquer um dos servidores que hospedam os serviços acima, mas os serviços não funcionarão.

Os registros do sistema nos servidores membros incluem algumas mensagens de erro sobre a impossibilidade de localizar um controlador de domínio.

Então, basicamente, a rede parece estar ativa e os DCs parecem estar ativos, mas os servidores membros ali mesmo no mesmo segmento de rede não conseguem encontrá-los. Onde devemos procurar o problema?

    
por Mox 09.07.2013 / 00:43

2 respostas

2

Esse problema foi causado por uma alteração de política de grupo destinada a estações de trabalho de usuários finais, mas foi aplicada por engano a alguns servidores membros. A alteração da política de grupo ativou o DirectAccess.

Para nossos servidores na instalação de hospedagem, a aplicação dessa política fez com que esses servidores concluíssem que estavam em uma rede não confiável. Assim, eles ativaram o Firewall do Windows, o que os impediu de localizar ou se comunicar com nossos controladores de domínio.

Revertemos as alterações aplicadas pela política de grupo, removemos os servidores membros do domínio e os adicionamos novamente ao domínio, o que resolveu o problema.

    
por 10.07.2013 / 15:17
2

Eu começaria a olhar para o DNS. Isso realmente cheira a DNS para mim.

Parece que algumas coisas estão faltando na zona de pesquisa direta _msdcs.domain.com ?

Se você executar um nslookup -type=SRV _kerberos._tcp.dc._msdcs.domain.com , o que está recebendo de volta para a saída?

Sniff o tráfego nos DCs ou nos servidores membros quando você estiver executando seus comandos de diagnóstico com falha e poste a saída aqui se o problema não for claramente óbvio. O comando NLTEST /DCLIST:domain.com , por exemplo, deve fazer com que o cliente emita algum DNS procurando por um servidor LDAP em seu site, seguido por algumas ligações RPC.

    
por 09.07.2013 / 01:32