Temos um ambiente de 2 domínios. Estávamos tendo problemas com conexões lentas, falhas de autenticação e recursos suspensos somente durante as horas em OFF-PEAK quando havia muito poucos usuários conectados.
O problema ocorreu quando um usuário de DOMAIN A acessou um recurso localizado em DOMAIN B e está usando a autenticação ntlm. Não há problemas com usuários de DOMAIN A acessando recursos em DOMAIN A ou com usuários de DOMAIN B acessando recursos em DOMAIN B.
Conseguimos rastrear o problema para os canais seguros usados para o tráfego do netlogon. Quando um recurso do domínio B tinha um canal seguro com um DC particular (eu o chamarei de DC-B1), então tudo funcionou bem. Podemos acompanhar a cadeia de tráfego do cliente (A) - > recurso (B) - > DC-B1 (B) - > DC-A1 (A) (para autenticação) e, em seguida, novamente. No entanto, se o servidor de recursos em B tivesse um canal seguro com qualquer outro DC em DOMAIN B, a autenticação seria interrompida e nunca concluída.
Parece que, com exceção de DC-B1, cada controlador de domínio em DOMAIN B está tendo problemas para criar um canal seguro de confiança de domínio com DOMAIN A. Para testar, executamos nltest / sc_verify: DOMAINA de cada controlador de domínio em DOMAIN B .
Quando executado a partir de DC-B1, a resposta foi instantânea. Quando executado a partir de qualquer outro controlador de domínio no domínio B, ele permaneceu por cerca de 40 segundos antes de mostrar um sucesso (nunca mostrou um erro, demorou muito tempo).
Alguma idéia de por que alguns DCs estariam lutando para estabelecer e usar o canal seguro de confiança de domínio e outro DC no mesmo domínio nunca teve um problema?
Por que vale a pena, o DC que funciona é o server 2008, os que não funcionam são o server 2012 R2, no entanto o problema existia em alguns controladores de domínio antes de migrar para o 2012 R2, nós simplesmente não definimos o problema até depois de terminarmos de migrá-los.
Obrigado pela ajuda.
Editar: informações adicionais ...
Comparou o valor de um final de semana de arquivos NetLogon.log para cada um dos controladores de domínio ...
Todo
[LOGON] SamLogon: Transitive Network logon of DOMAINA\testuser Entered
registro no log DC-B1 (esta é a boa DC) teve um correspondente
[LOGON] SamLogon: Transitive Network logon of DOMAINA\testuser Returns 0x0
no entanto, nos outros DCs no Domínio B, cada retorno teve um dos seguintes 3 erros:
[LOGON] ... DOMAINA\testuser ... Returns 0xC0020017
[LOGON] ... DOMAINA\testuser ... Returns 0xC0020050
[LOGON] ... DOMAINA\testuser ... Returns 0xC000005E
E aqui está com que frequência cada um dos diferentes erros ocorreu:
77% of errors were: 0xC0020017 RPC SERVER UNAVAILABLE
21% of errors were: 0xC0020050 RPC CALL CANCELED
1% of errors were: 0xC000005E NO LOGON SERVERS AVAILABLE
0% of returns were: 0x0 (no error)
Comparamos toda a configuração de segurança entre os DCs que não funcionam e a que executa, mas não encontramos nada que possa causar problemas de RPC. Alguma sugestão sobre onde poderíamos olhar em seguida? Estamos confusos sobre o motivo pelo qual o controlador de domínio 2008 em "B" não teria problemas para falar com os DCs de 2012 em "A", mas os Dcs de 2012 em "B" não podem usar a autenticação de passagem para "A".
Editar: informações adicionais solicitadas ...
Teste executado a partir do DC-B2 & DC-B3 (mesmos resultados)
(passar por autenticação originada aqui não funciona)
C:\>nltest /dsgetdc:DOMAINA.local
DC: \DC-A3.DOMAINA.local
Address: \555.555.555.127
Dom Guid: 9f3a0668-c245-4493-be03-0f7edf534d27
Dom Name: DOMAINA.local
Forest Name: DOMAINA.local
Dc Site Name: Company
Our Site Name: Company
Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9
The command completed successfully
Editar: informações adicionais ...
Resultados do PortQry do Domínio B - > Domínio A (GC DC)
TCP port 135 (epmap service): LISTENING
TCP port 389 (ldap service): LISTENING
UDP port 389 (unknown service): LISTENING or FILTERED
TCP port 636 (ldaps service): LISTENING
TCP port 3268 (msft-gc service): FILTERED
TCP port 3269 (msft-gc-ssl service): FILTERED
TCP port 53 (domain service): NOT LISTENING
UDP port 53 (domain service): NOT LISTENING
TCP port 88 (kerberos service): LISTENING
UDP port 88 (kerberos service): LISTENING or FILTERED
TCP port 445 (microsoft-ds service): LISTENING
UDP port 137 (netbios-ns service): LISTENING or FILTERED
UDP port 138 (netbios-dgm service): LISTENING or FILTERED
TCP port 139 (netbios-ssn service): LISTENING
TCP port 42 (nameserver service): FILTERED