Eu tenho um controlador de domínio remoto que não conseguiu replicar completamente o AD por pelo menos 90 dias, portanto, foi marcado para exclusão, teve seu link site a site cortado e foi removido da infraestrutura principal de AD da organização. Tudo bem, não queremos consertar isso ou trazer o AD local de volta ao grupo; o escritório seguirá em frente como seu próprio escritório AD separado. Estávamos no meio da preparação para uma migração do AD quando o link deles para o restante do AD falhou, mas nenhuma alteração foi feita ainda.
Atualmente, nenhuma das credenciais de administrador de domínio que temos funciona nesse controlador de domínio. Eu tenho 5 administradores de domínio diferentes que juram que sabem sua senha e sabem qual foi a senha da última vez que o AD foi replicado com sucesso. Nenhum de nós consegue fazer login, nem podemos usar a conta master Enterprise Admin, que é uma senha que definitivamente não mudou entre quando tudo estava funcionando corretamente e agora.
Não é possível que todos os nossos administradores de domínio não se lembrem de sua senha. As senhas não têm prazo de validade, e não é que estamos sendo forçados a mudar nossa senha, o DC local apenas acha que elas estão erradas. O administrador local diz que não fez nada em seu DC enquanto estávamos trabalhando na preparação para a migração do AD, e sua conta só tinha direitos administrativos sobre seus usuários e sua UO, então ele não deveria ter sido capaz de alterar nenhum de nossos senhas ou algo semelhante.
Então, como isso pode ter acontecido? A inicialização no DSRM em um DC faz algo para todas as contas de administrador de domínio se você estragar tudo? AKA, nosso cara local tentou resolver o problema com as próprias mãos e quebrar alguma coisa? É possível que o servidor tenha sido comprometido de alguma forma que causaria isso?
O único outro servidor no local é um servidor de arquivos ingressado no domínio que as credenciais do administrador local ainda funcionam para acessar, portanto, não é um grande problema.
O controlador de domínio existente é o Server 2008 R2, assim como o servidor de arquivos existente, e todos os computadores do escritório estão em máquinas Windows 7 totalmente atualizadas.
Mais detalhes relevantes : Temos um domínio global em nossa floresta que possui controladores de domínio remoto em vários escritórios, cada escritório é um site do AD. Um desses escritórios está se separando de nossa infraestrutura global. Antes que pudéssemos migrá-los adequadamente para fora de nosso domínio, seu ISP entrou em colapso e sua conexão com a Internet foi perdida. Como esse site não está voltando ao nosso controle, ele foi removido do domínio. Para ajudá-los a migrar para seu próprio domínio, executaríamos o ADMT, mas como o controlador de domínio local não pode ser autenticado com direitos de administrador, não podemos executar o ADMT.
Os perfis de usuário são estações de trabalho locais com uma unidade inicial armazenada no servidor de arquivos ao qual temos acesso de administrador, portanto, mover manualmente os dados é uma opção.
Tenho vários pensamentos/perguntas sobre como proceder:
- Posso restaurar o site e o DC e passar por todo o processo de desativação, mas é uma quantidade significativa de trabalho apenas para levá-los a um ponto em que possamos removê-los do AD novamente.
- Podemos descartar todo o AD local e fazê-los implantar um novo e migrar todos os computadores para um novo ambiente, mas isso também é uma quantidade significativa de trabalho.
- Se decidirmos pela opção 2, nossa maior preocupação será migrar os perfis de usuário do AD atual para o novo. Existe uma ferramenta que pode ajudar com isso, visto que o acesso administrativo ao domínio atual é inexistente? Ou basicamente será apenas criar o novo AD, entrar no PC, inicializar o novo perfil de usuário e copiar os dados do perfil antigo para o novo e reconfigurar as contas?
- Existe uma maneira melhor de fazer isso que eu não estou pensando? Todas as ferramentas que conheço para ajudar com algo assim requerem acesso administrativo ao AD de origem.
Isso está fora do âmbito do que você poderá consertar sozinho.
A meu ver, você tem duas opções:
O custo da opção 2 em termos de tempo de inatividade, perda de produtividade e tempo de TI provavelmente supera o custo da opção 1.