Topologia actual:
Na topologia em questão existem 3 DC's em três redes diferentes.
- O DC1 está na rede 1 é o primary domain controller e comunica com todos os outros DC's.
- O DC2 está na rede 2 e só consegue comunicar com o DC1 ( não é possível ver a rede nem os servidores na rede 3 ).
- Por seu turno o DC3 está na rede 3 que comunica com o DC1 e não consegue ver nem comunicar com o DC2 nem os respectivos servidores na rede 2.
Este DC serve de apoio a um servidor de Exchange numa rede offsite.
Um pouco de história:
Todos os DC's comunicavam alegremente entre eles anteriormente através de uma ligação VPN, no entanto essa ligação VPN foi substituída por uma ligação directa em fibra, e devido a limitação do datacenter remoto as redes locais tiveram de ser modeladas de acordo com as limitações do mesmo. O que fez com que apenas uma rede local conseguisse comunicar com a rede offsite.
A topologia no AD Sites and Services foi alterada de acordo com a nova topologia de rede.
O Problema:
A partir de uma certa altura o DC3 por alguma razão deixou de se sincronizar com o DC1, logo começaram a haver problemas com os objectos do Exchange com "lingering objects"( objectos que se mantém na base de dados apesar de já ter passado o período de tombstone ) à mistura.
O principal sintoma era quando tentava fazer uma replicação ou aceder a uma partilha de ficheiros no DC3 recebia o seguinte erro:
"Target Principal Name Incorrect"
Em detalhe, qualquer coisa como o seguinte:
The Kerberos client received a KRB_AP_ERR_MODIFIED ... .... ...No entanto se o acesso à partilha fosse por endereço de IP a coisa funcionava bem.
Na primeira vez que tive assistência dos Premier Field Engineer da Microsoft a qual durou cerca de três horas, foram feitas alterações que nem consegui entender bem no entanto ficou a funcionar, mas após 60 dias, deixou de sincronizar e o problema voltou.
Após solicitar ajuda da Microsoft, desta vez consegui perceber o que foi feito no sentido de resolver o problema e percebi que tive muito perto de o resolver sem pedir ajuda.
A resolução:
A solução para o problema passava em efectuar diversos passos seguidos de uma determinada ordem, ora então vamos a eles.
1º - Alterar/criar as chaves de registo que não deixam os DC's replicar se encontrarem falhas na consistência das bases de dados:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency
para 0 nos três DC's.
2º Alterar/criar a chave de registo que permite a replicação entre DC's mesmo que o DC esteja com grandes diferenças na BD e que esteja dado como corrupto:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner
para 1 nos três DC's ( apesar de não ser necessário no DC2 ).
3º Desactivar o serviço de Kerberos no DC1 e no DC2 para que quando formos alterar as passwords kerberos nas máquinas as mesmas sejam feitas no DC3.
net stop kdc
E na consola MMC dos serviços configurar o serviço como desactivado ou em manual.
4º Limpar os tickets Kerberos no DC3 usando o programa psexec para que se possa iniciar a prompt como utilizador SYSTEM ( pois é o utilizador que está a correr o serviço KDC )
Comando:
psexec /s /i CMD
na linha de comandos escrever whoami para verificar se está como system e então limpar os tickets:
klist /purge
5º Efectuar o reset da password no DC3 contra ele mesmo ( executar no DC3 ).
netdom resetpwd /s:DC3 /ud:dominio\administrator /pd: *: *
6º Efectuar o reset da password no servidor DC1 para o DC3 ( executar no DC1 )
netdom resetpwd /s:DC3 /ud:dominio\administrator /pd: *: *
7º Forçar a replicação dos DC's ( correr no DC1 )
repadmin /syncall
Em seguida verificar se existem erros de replicação:
repadmin /showrepl
Em caso de não existirem problemas verificar se já se consegue aceder a uma partilha de ficheiros no DC3 através do nome.
8º Efectuar o ponto 7 no servidor DC3.
No caso do problema ficar resolvido então basta repor as chaves de registo dos pontos 1 e 2 de activar o kerberos nos servidores DC1 e DC2.
E pronto foi assim mais uma aventura no mundo Microsoft.
