Não é possível ingressar nas estações de trabalho Win7 no domínio Win2k8


8

Estou tentando conectar uma máquina Windows 7 Ultimate a um domínio Windows 2k8 e não está funcionando. Eu recebo este erro:

Nota: Esta informação é destinada a um administrador de rede. Se você não é o administrador da sua rede, notifique o administrador de que você recebeu essas informações, que foram registradas no arquivo C: \ Windows \ debug \ dcdiag.txt.

O DNS foi consultado com sucesso pelo registro de recurso SRV (Service Location) usado para localizar um controlador de domínio para o domínio "example.local":

A consulta foi para o registro SRV de _ldap._tcp.dc._msdcs.example.local

Os seguintes controladores de domínio foram identificados pela consulta:
dc1.example.local
dc2.example.local

No entanto, nenhum controlador de domínio pôde ser contatado.

As causas comuns desse erro incluem:

  • Os registros do host (A) ou (AAAA) que mapeiam os nomes dos controladores de domínio para seus endereços IP estão ausentes ou contêm endereços incorretos.

  • Os controladores de domínio registrados no DNS não estão conectados à rede ou não estão em execução.

O cliente está em um escritório conectado remotamente via MPLS ao datacenter onde existem nossos controladores de domínio. Parece que não tenho nada bloqueando a conectividade com os controladores de domínio, mas não tenho controle total sobre o circuito MPLS; portanto, é possível que haja algo bloqueando a conectividade.

Eu tentei vários clientes (Win7 Ultimate e WinXP SP3) em um escritório e sinto os mesmos sintomas em todos eles.

Não tenho problemas para conectar-me a nenhum dos controladores de domínio, embora eu tenha admitido que não tentei todas as portas possíveis. As conexões ICMP, LDAP, DNS e SMB funcionam bem.

O DNS do cliente está apontando para os controladores de domínio e "example.local" resolve os dois endereços IP dos controladores de domínio.

Eu obtenho essa saída do utilitário de linha de comando NetLogon Test:

C:\Windows\System32>nltest /dsgetdc:example.local
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Também criei uma rede separada para emular a configuração do escritório conectada à rede DC via VPN LAN para LAN em vez de MPLS. Juntar computadores Windows 7 a partir dessa rede remota funciona bem.

A única diferença que posso encontrar entre os dois ambientes é a conectividade intermediária, mas estou sem ideias sobre o que testar ou como fazê-lo. Que etapas adicionais devo seguir?

(Observe que essa estação não é realmente minha estação de trabalho cliente e não tenho acesso direto a ela; sou forçado a fazer o acesso remoto por mãos, o que torna mais difíceis alguns dos métodos óbvios de solução de problemas, como detecção de pacotes, como cheirar pacotes. poderia simplesmente configurar um sistema lá no qual eu pudesse conectar remotamente, eu faria, mas as solicitações nesse sentido ficaram sem resposta.)

Atualização de 25/08/2011:
Eu DCDIAG.EXEexecutei um cliente tentando ingressar no domínio:

C:\Windows\System32>dcdiag /u:example\adminuser /p:********* /s:dc2.example.local

Directory Server Diagnosis

Performing initial setup:
   Ldap search capabality attribute search failed on server
   dc2.example.local, return value = 81

Parece que foi possível conectar via LDAP, mas o que estava tentando fazer falhou. Mas não sigo exatamente o que estava tentando fazer, muito menos como reproduzi-lo ou resolvê-lo.

Atualização de 26/08/2011:
usar LDP.EXEpara tentar fazer uma conexão LDAP diretamente nos controladores de domínio resulta nos seguintes erros:

ld = ldap_open ("10.0.0.1", 389);
Erro <0x51>: falha ao conectar-se ao 10.0.0.1.
ld = ldap_open ("10.0.0.2", 389);
Erro <0x51>: falha ao conectar-se ao 10.0.0.2.
ld = ldap_open ("10.0.0.1", 3268);
Erro <0x51>: falha ao conectar-se ao 10.0.0.1.
ld = ldap_open ("10.0.0.2", 3268);
Erro <0x51>: falha ao conectar-se ao 10.0.0.2.

Isso parece apontar o dedo para as conexões LDAP serem bloqueadas em algum lugar. (E 0x51 == 81, que foi o erro DCDIAG.EXEda atualização de ontem.) Eu poderia jurar que testei isso usando TELNET.EXEsemanas atrás, mas agora estou pensando que posso ter assumido que a limpeza da tela estava me dizendo que era esperando e não que ele tivesse se conectado.

Estou rastreando problemas de conectividade LDAP agora. Esta atualização pode se tornar uma resposta.


3
Como o DNS parece estar funcionando, sugiro colar o NetMon ou o Wireshark nas duas extremidades e capturar os pacotes para ver o que está acontecendo no cabo.
ITHedgeHog

BTW, eu amo o erro ortográfico na dcdiagsaída.
Whaulk 25/08

Você está recebendo alguma mensagem de erro / evento nos CDs?
Grizly

@ Grizly: Não que eu tenha visto, não.
precisa saber é

Você acessou algum dispositivo de rede entre as estações de trabalho e os servidores? Você deseja verificar os registros de filtragem / conexão e ver se algum deles está descartando / filtrando pacotes de / para as estações de trabalho.
Ashley

Respostas:


2

Demorou uma eternidade para descobrir onde estava acontecendo, mas verifica-se que havia filtros na VPN bloqueando o tráfego LDAP (e outros). Eu limpei esses filtros e agora está funcionando.


2

Pode haver um firewall entre a máquina Win7 e os controladores de domínio.

Se você tiver acesso ao nmap :

nmap -PN -p389 dc1.example.local dc2.example.local

Atualizar:

nltest /dsgetdc:example.local

nslookup -q=srv _ldap._tcp.dc._msdcs.example.local  
nslookup -q=a $prefered_host  
ldapsearch -h $IPaddress_of_A_record -x -b "" -s base (&(DNSDomain=example.local)(HOST=$localmachineshostname)(NtVer=\\\\16\\\\00\\\\00\\\\00)) netlogon

O NtVer está solicitando o V5 (logon de rede da versão 5), o V5EX (logon estendido da versão 5) e o VCS (o CC mais próximo). Retirado de Win7Ent.

(ldap hex é complicado).


Como eu disse, a conectividade LDAP com os DCs funciona bem.
wfaulk

Foi mal. Ainda tudo o que o nltest faz é 2 pesquisas de DNS e uma pesquisa CLDAP. Vou atualizar com o comportamento.
84104

Boa informação. Vou checar duas dessas coisas.
wfaulk

Alguém sabe se registros PTR inexistentes para os controladores de domínio seriam um problema?
Whaulk

Não deveria ser; todas as outras máquinas se juntaram sem elas. nltestnão os procura. Verifique novamente se o cliente pode obter o registro SRV. Não pense que os servidores MS DNS dividem a exibição, mas ficam sem opções.
84104

1

Parece que o win7 não está apontando seu DNS para um controlador de domínio? Talvez o DHCP esteja apontando o DNS para o DNS dos provedores de internet?


Não, o DNS definitivamente aponta para os controladores de domínio. Eu acho que o fato de a pesquisa LDAP SRV funcionar confirma isso.
wfaulk

você pode executar ping no nome do domínio sem o nome do host? por exemplo, se o controlador de domínio é DC1.mydomain.com, você pode executar ping mydomain.com na caixa win7?
Alan Alan

Sim. resolve para os endereços IP dos dois controladores de domínio.
wfaulk

Estou sem ideias! Boa sorte para você!
Alan Alan

0

Parece que você tentou e testou tudo no que diz respeito ao DNS, mas você verificou se os registros A dos servidores DC / DNS existem e estão corretos? O que acontece quando você executa o nslookup testando os dois servidores quanto à presença dos registros A dos dois servidores? Os DCs retornados na mensagem de erro são realmente os servidores DC / DNS corretos para o domínio?


Dado que ingressar no domínio funciona bem em uma rede diferente, não acho que seja algo tão fundamental quanto isso.
wfaulk

Desculpe, eu perdi essa parte.
precisa saber é o seguinte

Você certificou-se de que o tráfego nas seguintes portas o atravesse no circuito MPLS: Tráfego do Microsoft-DS (445 / tcp, 445 / udp) • Protocolo de autenticação Kerberos (88 / tcp, 88 / udp) • Protocolo de acesso a diretórios leve (LDAP) (389 / udp) • Domain Name System (DNS) (53 / tcp, 53 / udp)
joeqwerty

0

Existe a possibilidade de o cliente no escritório remoto estar executando apenas o IPv6 e, embora encontre o registro SRV para o controlador de domínio, o DNS não está configurado com os registros AAAA (IPV6)?


Palpite interessante, mas não.
precisa saber é
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.