Restauração e recuperação de um controlador de domínio local corrompido.

Quando um controlador de domínio é corrompido ou restaurado incorretamente, o susto é enorme: O login falha, as GPOs param de ser aplicadas e a replicação para de funcionar quase sem nenhum indício aparente.A boa notícia é que existem procedimentos claros para recuperar um controlador de domínio físico ou virtual, desde que os métodos de backup e restauração aceitos sejam respeitados.

Em ambientes modernos do Windows Server, a restauração de um controlador de domínio exige um bom entendimento de conceitos como: status do sistema, restauração autoritativa/não autoritativa, reversões de SYSVOL, DFSR/FRS e USNSe esses problemas forem abordados às pressas ou com ferramentas de imagem incompatíveis, o resultado pode ser uma floresta repleta de inconsistências silenciosas muito difíceis de diagnosticar.

Por que é fundamental proteger e recuperar adequadamente um controlador de domínio?

O Active Directory é o núcleo da autenticação e autorização em um domínio Windows.Ele armazena usuários, computadores, grupos, relações de confiança, políticas de grupo, certificados e outros elementos críticos. Essas informações residem principalmente no banco de dados. Ntds.dit, os arquivos de log e a pasta associados SISTOL, entre outros componentes que compõem o chamado “estado do sistema”.

O estado do sistema inclui, entre outras coisas, Arquivos de log e dados do Active Directory, o Registro do Windows, o volume do sistema, SYSVOL, o banco de dados de certificados (se houver uma Autoridade Certificadora), o metabase do IIS, arquivos de inicialização e componentes protegidos do sistema operacional.Portanto, qualquer estratégia séria de continuidade de negócios deve incluir backups regulares do estado do sistema de cada centro de dados.

Quando ocorre uma corrupção real do banco de dados do Active Directory, uma falha grave de replicação ou um problema com permissões em SISTOLO controlador de domínio pode parar de processar consultas, falhar ao iniciar os serviços do Active Directory ou desencadear erros em cascata em toda a floresta. Nesses casos, Uma recuperação rápida e adequada faz toda a diferença entre um incidente grave e um desastre prolongado..

Antes de tentar uma restauração, é crucial distinguir entre um problema genuíno no banco de dados e falhas mais comuns. Muitas vezes, A causa reside no DNS, em alterações de rede, em firewalls ou em rotas modificadas com ferramentas como... comando netshPortanto, é aconselhável descartar esses fatores antes de mexer no banco de dados do Active Directory.

Ferramentas básicas de diagnóstico e controle de replicação

Em caso de sintomas de corrupção ou falhas de replicação, o primeiro passo sensato é verificar o estado do ambiente usando ferramentas nativas. DCDiag, Repadmin, ReplMon (em versões mais antigas) e o Visualizador de Eventos Eles são seus melhores aliados antes de considerar restaurações agressivas.

Com DCDiag É realizada uma verificação geral de todos os controladores de domínio, identificando problemas com replicação, DNS, serviços do AD DS, etc. Repadmin Permite visualizar o estado da replicação, os parceiros de replicação, as marcas d'água USN e detectar objetos persistentes. Em versões mais antigas do Windows, ReplSegunda Oferecia uma visão gráfica dos erros de replicação dentro do domínio.

Além dessas ferramentas, é essencial verificar o Visualizador de Eventos em busca de ocorrências relacionadas a “Serviços de Diretório” e “Replicação DFS”. Eventos como 467 e 1018 apontam para uma corrupção real do banco de dados., enquanto os eventos 1113/1115/1114/1116 se referem à ativação ou desativação da replicação de entrada/saída.

Se um suspeito de corrupção precisar ser isolado temporariamente para evitar que espalhe a corrupção, podemos Desative a replicação de entrada e saída com o Repadmin.:

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

Para restaurar a replicação ao normal, basta remover essas opções:

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

Backups de estado do sistema suportados em controladores de domínio

Para poder recuperar um DC com garantias, é essencial ter Cópias de segurança do estado do sistema realizadas usando ferramentas compatíveis com o Active Directory.Essas ferramentas utilizam as APIs de backup e restauração da Microsoft e o Serviço de Cópias de Sombra de Volume (VSS) de maneira compatível.

Entre as soluções mais comuns estão Backup do Windows Server, soluções de terceiros integradas ao VSS (como NAKIVO, Backup Exec e outras)ou serviços públicos mais antigos, como Ntbackup No Windows 2000/2003. Em todos os casos, eles devem respeitar as APIs do AD para garantir a consistência do banco de dados e suas réplicas após a restauração.

O Windows Server 2012 e versões posteriores apresentam uma importante novidade: ID de geração do Hyper-V (GenID)Esse identificador permite que um controlador de domínio virtual detecte que seu disco foi revertido para um ponto anterior no tempo. Quando isso ocorre, O AD DS gera um novo InvocationID e trata a situação como se tivesse sido restaurada a partir de um backup bem-sucedido.notificando seus parceiros de replicação, permitindo assim a reescrita segura sem incorrer em um rollback do USN.

É essencial respeitar o lápide vida inteiraIsso indica por quanto tempo um backup do estado do sistema pode ser usado sem o risco de reintroduzir objetos excluídos há muito tempo. Normalmente, são 180 dias em versões modernas, e recomenda-se realizar backups pelo menos a cada 90 dias para manter uma margem de segurança suficiente.

Métodos não autorizados que causam reversões de USN

Uma das causas mais perigosas de inconsistências silenciosas no Active Directory é a Recuo da Marinha dos EUAEssa situação ocorre quando o conteúdo do banco de dados do Active Directory é revertido usando uma técnica não suportada, sem que o InvocationID seja restaurado ou os parceiros de replicação sejam notificados.

O cenário típico é inicializar um controlador de domínio a partir de um imagem de disco ou um instantâneo de máquina virtual tirado no passadoSem usar uma restauração de sistema compatível. Ou copie o arquivo Ntds.dit diretamente, use programas de criação de imagens como o Ghost, inicialize a partir de um espelho de disco corrompido ou reaplique um snapshot de armazenamento no nível do array.

Nesses casos, o controlador de domínio continua a usar o mesmo InvocationID de antes, mas seu O contador local da USN retrocede.Os outros DCs lembram-se de ter recebido alterações até um USN alto, portanto, quando o DC revertido tenta enviar de volta USNs já reconhecidos, Seus parceiros acreditam que estão atualizados e param de aceitar mudanças concretas..

O resultado é que certas modificações (por exemplo, Criação de usuários, alterações de senha, registro de dispositivos, alterações de associação a grupos, novos registros DNS.Esses erros nunca são replicados do controlador de domínio restaurado para o restante da rede, mas as ferramentas de monitoramento podem não mostrar erros claros. Trata-se de uma falha silenciosa extremamente perigosa.

Para detectar essas situações, os drivers do Windows Server 2003 SP1 e versões posteriores registram o Evento de Serviços de Diretório 2095 Quando um controlador de domínio remoto é detectado enviando USNs já reconhecidos sem alteração no InvocationID, o sistema Isso coloca o controlador de domínio afetado em quarentena, pausa o Netlogon e impede que novas alterações ocorram. que não pôde ser replicado corretamente.

Como prova forense adicional, pode a ser consultado no Registro a chave HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters e o valor Dsa não gravávelSe esse valor estiver definido (por exemplo, 0x4), isso indica que o controlador de domínio foi colocado em um estado de não gravação pela detecção de reversão do USN. Modificar manualmente esse valor para "corrigi-lo" não é suportado. e deixa o banco de dados em um estado permanentemente inconsistente.

Estratégias gerais em caso de corrupção ou reversão de um controlador de domínio.

O procedimento a seguir ao lidar com um controlador de domínio corrompido ou restaurado incorretamente depende de vários fatores: Número de controladores de domínio no domínio/floresta, disponibilidade de cópias válidas do estado do sistema, presença de outras funções (FSMO, CA, catálogo global) e abrangência temporal do problema..

Se houver outros DCs saudáveis ​​no domínio e Não existem dados críticos exclusivos sobre o controlador de domínio danificado.A opção mais rápida e limpa geralmente é remover esse controlador de domínio e recriá-lo. No entanto, se for o único controlador de domínio ou se hospedar funções e dados confidenciais, será necessária uma restauração mais cuidadosa (autoritativa ou não autoritativa).

Em termos gerais, as opções são:

• Rebaixe à força o controlador de domínio corrupto e remova-o do domínio., seguida de limpeza de metadados e, se aplicável, nova promoção.
• Restaurar a partir de um backup válido do estado do sistema, seja em modo autoritativo ou não autoritativo.
• Recrie o controlador de domínio a partir de outro usando o IFM (Instalar a partir da mídia)., quando não há cópia recente, mas existem outros DCs corretos.
• Utilizando um snapshot VHD de um datacenter virtual., aplicando as etapas adicionais para marcar o banco de dados como restaurado a partir do backup (Banco de dados restaurado a partir do backup = 1) e garantir que um novo InvocationID seja gerado.

Se houver forte suspeita de reversão do USN (por exemplo, após restaurar uma VM a partir de um snapshot sem seguir as melhores práticas) e o evento 2095 ocorrer, a conduta mais sensata geralmente é... Retire esse controlador de domínio de serviço e não tente "consertá-lo" no local., a menos que seja possível reverter para um backup do estado do sistema suportado, feito antes do rollback.

Rebaixamento forçado e limpeza de metadados

Quando um controlador de domínio está tão danificado que não pode ser rebaixado normalmente, ou foi restaurado incorretamente e você deseja evitar que ele propague problemas, você pode recorrer a um rebaixamento forçado.

Em versões anteriores, essa operação era realizada com dcpromo /remoçãoforçada, Que Remova a função AD DS sem tentar replicar as alterações para o restante da floresta.Em ambientes modernos, o assistente mudou, mas o conceito é o mesmo: remover o controlador de domínio problemático da topologia do Active Directory sem que ele participe de replicação futura.

Após um downgrade forçado, é obrigatório executar um comando a partir de um controlador de domínio íntegro. limpeza de metadados usando a ferramenta NtdsutilEsse processo remove todas as referências ao controlador de domínio excluído (objetos de configurações NTDS, referências DNS etc.) do banco de dados do Active Directory, de modo que Não restam vestígios "fantasmas" que possam confundir a replicação..

Se o controlador degradado possuía funções FSMO (Emulador PDC, Mestre RID, Mestre de Esquema, etc.), será necessário transferir ou assumir esses cargos para outro controlador de domínio antes ou depois do rebaixamento, dependendo da situação. Posteriormente, o sistema operacional pode ser reinstalado nesse servidor e ele pode ser promovido novamente a um controlador de domínio limpo.

Restauração não autoritativa versus autoritativa no Active Directory

Quando uma cópia válida do estado do sistema estiver disponível, a recuperação do AD pode ser feita de duas maneiras: não autoritativo e autoritativoCompreender a diferença é fundamental para não perder alterações recentes ou replicar dados desatualizados.

Em uma restauração não autorizadaO DC retorna a um ponto anterior, mas assim que inicia, Os demais controladores de domínio são considerados a referência.Em outras palavras, após a inicialização, o controlador de domínio restaurado solicita replicação de entrada e atualiza seu banco de dados com quaisquer alterações ausentes dos outros controladores de domínio. Essa opção é ideal quando Existem outros controladores saudáveis, e queremos que o restaurado alcance os demais..

Em uma restauração autoritáriaNo entanto, afirma-se explicitamente que Os dados restaurados são os que devem prevalecer. sobre o que os outros DCs possuem. Isso significa que, após a restauração, os objetos recuperados terão um número de versão mais alto para forçar sua replicação desse DC para o restante do domínio. É a escolha apropriada quando Excluímos objetos ou UOs acidentalmente, ou queremos reverter o conteúdo do SYSVOL e do GPO para um estado anterior e replicá-lo..

Um detalhe importante é que a restauração autorizada não precisa necessariamente abranger todo o banco de dados. Com o utilitário Ntdsutil Objetos individuais, subárvores (por exemplo, uma Unidade Organizacional) ou o domínio inteiro podem ser marcados como autoritativos. Isso oferece considerável flexibilidade para, por exemplo, Recuperar apenas um usuário, um grupo, uma Unidade Organizacional (UO) ou a subárvore dc=mycompany,dc=local.

Procedimento geral para restaurar o estado do sistema em um data center.

O esquema básico para restaurar o estado do sistema de um controlador de domínio (seja físico ou virtual) com ferramentas compatíveis é sempre semelhante: Inicialize o sistema no Modo de Restauração de Serviços de Diretório (DSRM), restaure usando a ferramenta de backup e reinicie..

Em resumo, os passos típicos para um controlador de domínio virtual seriam:

1. Inicie a máquina virtual no Gerenciador de Inicialização do Windows. (geralmente pressionando F5/F8 durante a inicialização). Se a máquina virtual for gerenciada por um hipervisor, pode ser necessário pausar a máquina para capturar a tecla pressionada.
2. Nas opções avançadas de inicialização, selecione modo de restauração de serviços de diretório (Modo de Restauração dos Serviços de Diretório). Este modo inicia o servidor sem montar o banco de dados do Active Directory de forma funcional.
3. Faça login com a conta de administrador do DSRM. definido durante a promoção original do controlador de domínio (não com uma conta de administrador de domínio padrão).
4. Execute a ferramenta de backup. Utilize um programa (como o Backup do Windows Server, NAKIVO ou outro compatível) e escolha restaurar o estado do sistema para o ponto de backup desejado.
5. Conclua o assistente de restauração e Reinicie o DC no modo normal.Em uma restauração não autoritativa, o servidor iniciará a replicação para se sincronizar com os outros controladores de domínio.

Quando falamos de produtos de backup de terceiros, como Backup e replicação NAKIVOSeu modo "compatível com aplicativos" é capaz de reconhecer que a máquina que está sendo recuperada é um DC e Ajustar automaticamente o processo para preservar a consistência do AD.Na maioria dos cenários com múltiplos controladores, uma recuperação completa em modo não autoritativo é suficiente.

Restauração confiável com Ntdsutil

Se você deseja que as alterações no controlador de domínio restaurado tenham precedência sobre as demais, é necessário adicionar uma etapa extra após a restauração não autoritativa: Use Ntdsutil para marcar objetos como autoritativos..

O fluxo simplificado seria:

1. Restaure o estado do sistema da maneira padrão e deixe o servidor ainda em Modo DSRM (Não reinicie no modo normal ainda).
2. Abra uma prompt de comando com privilégios elevados e corra ntdsutil.
3. Ative a instância do AD com ativar instância ntds.
4. Entrando no contexto da restauração autorizada com restauração autorizada.
5. Use comandos como restore object <DN_objeto> o restore subtree <DN_subarbol>, onde DN é o nome distinto do objeto ou subárvore a ser restaurado de forma definitiva.
6. Confirme a transação e, assim que estiver concluída, Reinicie o DC no modo normal. de forma que os objetos marcados sejam replicados com prioridade em relação ao restante do domínio.

Esse tipo de restauração exige muita cautela. Se todo o domínio for restaurado de forma definitiva e o backup for antigoExiste o risco de perder alterações legítimas feitas após o backup (por exemplo, criação de usuários, alterações de senhas ou modificações de grupos). Portanto, é prática comum limitar as restaurações autoritativas apenas aos objetos ou árvores estritamente necessários.

Restauração e recuperação do SYSVOL (FRS vs DFSR)

SYSVOL é um componente essencial do controlador de domínio: Ele armazena scripts de inicialização, políticas de grupo, modelos de segurança e outros recursos compartilhados essenciais.Falhas nas permissões, corrupção de arquivos ou problemas de replicação podem tornar as GPOs inutilizáveis ​​ou causar comportamento errático nos clientes.

Dependendo da versão do Windows Server e do status da migração, o SYSVOL pode ser replicado por FRS (Serviço de Replicação de Arquivos) o por DFSR (Replicação de Sistema de Arquivos Distribuído)O procedimento para uma restauração definitiva do SYSVOL varia dependendo de qual dos dois está em uso.

Para determinar isso, você pode verificar a chave no Registro. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateSe essa subchave existir e seu valor for 3 (EXCLUÍDO), o DFSR está sendo usado. Se ela não existir ou seu valor for diferente, estamos lidando com um ambiente que ainda usa o FRS.

Em ambientes com FRS, a recuperação autorizada do SYSVOL geralmente envolve o ajuste do valor. Burbandeiras en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process para um valor específico (por exemplo, 212 decimal / 0xD4 hexadecimal) para indicar que este DC é a fonte autorizada.

Se o SYSVOL for replicado pelo DFSR, o processo é um pouco mais complexo: envolve o uso de ADSIEdit para modificar objetos de assinatura SYSVOL (atributos) ativado para msDFSR y Opções msDFSR) no DC autoritativo e nos outros, force a replicação do AD, execute dfsrdiag pollad e confirme no registro de eventos a ocorrência de eventos 4114, 4602, 4614 e 4604 que certificam que o SYSVOL foi inicializado e replicado corretamente.

Recuperando controladores de domínio virtuais de VHD

Em ambientes virtualizados, é muito comum ter Arquivos VHD/VHDX de controladores de domínioSe você não tiver um backup do estado do sistema, mas tiver um VHD "antigo" em funcionamento, poderá montar um novo controlador de domínio a partir desse disco, embora deva fazê-lo com muito cuidado para evitar causar um rollback do USN.

A recomendação é Não inicie essa máquina virtual diretamente no modo normal.Em vez disso, você deve inicializar a partir do VHD anterior em DSRMAbra o Editor do Registro e navegue até HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersAli, é aconselhável verificar o valor. Contagem de restaurações DSA anteriores (se existir) e, acima de tudo, crie um novo valor DWORD (32 bits) chamado Banco de dados restaurado a partir do backup. com valor 1.

Ao selecionar esse valor, o Active Directory é informado de que o banco de dados foi restaurado a partir de um backup, o que força Gerando um novo InvocationID ao inicializar no modo normal.Dessa forma, os outros DCs interpretam como uma nova instância e ajustam corretamente suas marcas d'água de replicação, impedindo o rollback do USN.

Após reiniciar o controlador de domínio no modo normal, é recomendável verificar o Visualizador de Eventos, especificamente o registro de eventos. serviços de diretório, procurando pelo Evento 1109Este evento confirma que o atributo InvocationID do servidor foi alterado e exibe os valores antigo e novo, bem como o USN mais alto no momento do backup. Além disso, o valor de Contagem de restaurações DSA anteriores Deveria ter sido aumentado em um.

Se esses eventos não aparecerem ou a contagem não aumentar, você deve verificar as versões do sistema operacional e os Service Packs, pois Certos comportamentos de restauração dependem de áreas específicas.Em qualquer caso, é sempre aconselhável trabalhar com uma cópia do VHD original, mantendo uma versão intacta caso o processo precise ser repetido.

Cenários práticos e recomendações adicionais

Na prática, problemas de corrupção ou restaurações indevidas frequentemente surgem em situações do dia a dia: Modificações manuais de permissões no SYSVOL, tentativas de atualização de modelos ADMX/ADML, alterações de GPO que não são replicadas.etc. É relativamente fácil causar inconsistências se pastas compartilhadas forem modificadas manualmente, como por exemplo SYSVOL\Policies sem respeitar a replicação.

No caso de um controlador de domínio primário com replicação interrompida (tanto de dados do AD quanto do SYSVOL) e mensagens de monitoramento do tipo “O banco de dados foi restaurado usando um procedimento não suportado. Possível causa: reversão do USN.O mais prudente a fazer é:

• Verificar com dcdiag y repadmin a extensão dos erros e se existem "objetos persistentes".
• Verifique o evento 2095 e o valor. Dsa não gravável no Registro.
• Avalie se é possível. Remova esse controlador de domínio e reconstrua-o. (Se houver três ou mais outros DCs saudáveis, esta geralmente é a melhor opção).
• Se for o único crítico ou membro da DC, levante uma questão. restauração do estado do sistema a partir de um backup compatível, idealmente recente e dentro do período de exclusão (tombstone period).

Em domínios com múltiplos controladores, é altamente recomendável que os controladores de domínio sejam o mais "puros" possível: sem funções adicionais ou dados de usuário locaisDessa forma, se uma unidade falhar ou for corrompida, uma nova pode ser formatada e promovida com base em outro controlador de domínio ou por meio do IFM, reduzindo consideravelmente a complexidade da recuperação.

Além disso, vale a pena lembrar limitações como essa. As cópias do estado do sistema são válidas apenas durante o período de exclusão (tombstone). (60, 90, 180 dias, dependendo da configuração) para evitar a recuperação de objetos excluídos, e que as chaves NTLM da máquina mudem a cada 7 dias. Em restaurações muito antigas, pode ser necessário redefinir contas de equipe problemas com o “Active Directory Users and Computers” ou até mesmo a remoção e reintegração dos usuários ao domínio.

Ter procedimentos implementados para fazer backup regular do estado do sistema, Documente claramente as funções FSMO, o catálogo global e a topologia de replicação.Testar os passos de restauração em um ambiente de laboratório é um investimento de tempo que evita muitas dores de cabeça quando um controlador de domínio é corrompido ou alguém aplica um snapshot sem pensar.