Backup do Active Directory: como recuperar o domínio após um desastre

Por que o backup do Active Directory é diferente de qualquer outro backup

O Active Directory (AD) é a base de quase toda a TI de uma empresa que usa Windows. Ele autentica os usuários, aplica as políticas de grupo (GPOs), controla o acesso a pastas compartilhadas e impressoras, e é usado por sistemas como ERP, VPN, Wi-Fi corporativo e Microsoft 365 em ambiente híbrido. Quando o domínio cai, ninguém faz login e nenhum sistema que depende dessa autenticação funciona. Na prática, a empresa para.

Mesmo assim, muitas empresas ainda acham que ter dois controladores de domínio (DCs) basta como proteção. Não basta. A replicação entre DCs foi feita para manter os dados iguais em todos eles, e não para guardar versões antigas. Se alguém apaga uma OU inteira por engano, a exclusão chega a todos os DCs em minutos. Se um ransomware criptografa um controlador de domínio ou altera objetos com uma conta administrativa comprometida, essa alteração também se espalha. Redundância protege contra falha de hardware, não contra erro humano nem contra ataque.

O AD também tem regras próprias de restauração. Não adianta copiar arquivos do servidor ou voltar um snapshot antigo da máquina virtual. Restaurar do jeito errado pode causar USN rollback: o DC restaurado fica fora de sincronia com os outros e passa a replicar dados inconsistentes, ou para de replicar sem avisar. Por isso, fazer backup do AD exige entender o que é o estado do sistema, os tipos de restauração e o limite de tempo que o próprio AD impõe aos backups.

System State: o que é e como fazer o backup corretamente

Em um controlador de domínio, o backup que importa é o do estado do sistema (System State). É ele que guarda os componentes que o AD precisa para ser recuperado de forma consistente. Copiar só o arquivo do banco de dados não funciona: ele fica em uso e depende de outros componentes para estar íntegro.

• NTDS.dit: o banco de dados do Active Directory, com usuários, grupos, computadores, OUs e atributos;
• SYSVOL: a pasta replicada que guarda as GPOs e os scripts de logon;
• Registro do Windows e arquivos de inicialização do servidor;
• Registro de classes COM+;
• Banco de dados dos Serviços de Certificados, se o DC também for autoridade certificadora;
• Configurações de cluster, quando houver.

No próprio Windows Server, o caminho nativo é o Windows Server Backup. Por linha de comando, o backup do estado do sistema é feito com wbadmin start systemstatebackup -backupTarget:E: -quiet, de preferência gravando em um volume dedicado. Em ambientes virtualizados, soluções corporativas como o Veeam, com processamento application-aware, fazem um backup consistente do DC e ainda permitem restaurar objetos individuais sem derrubar o servidor. Seja qual for a ferramenta, ela precisa reconhecer o AD e usar o VSS corretamente. Um snapshot comum de hypervisor não substitui o backup.

Há um detalhe que pouca gente conhece: o tombstone lifetime. Quando um objeto é excluído, o AD guarda um marcador por um período, que é de 180 dias por padrão nas florestas mais recentes. Um backup mais antigo que esse período não deve ser usado para restaurar o AD, porque pode reintroduzir objetos que os outros DCs já descartaram (os chamados lingering objects). Na prática, o backup do estado do sistema precisa ser diário, de pelo menos dois DCs por domínio, e a retenção tem que considerar esse limite.

Uma boa regra: se você não sabe quando foi o último backup bem-sucedido do estado do sistema do seu controlador de domínio, nem a senha do modo de restauração (DSRM), o seu domínio está desprotegido, por mais DCs que existam.

Restauração não autoritativa x autoritativa: quando usar cada uma

Restaurar um DC exige iniciar o servidor no Modo de Restauração dos Serviços de Diretório (DSRM), um modo especial em que o AD fica offline. O acesso é feito com a senha DSRM definida na promoção do servidor. Ela é diferente da senha do administrador do domínio e pode ser redefinida com o ntdsutil (comando set dsrm password). Guarde essa senha em um cofre de senhas, porque sem ela a restauração nem começa.

A restauração não autoritativa é o tipo padrão. O DC volta ao estado do backup e, ao reiniciar normalmente, recebe dos outros DCs todas as alterações feitas desde então. Ela serve para recuperar um controlador de domínio que corrompeu ou perdeu o disco, quando os demais DCs continuam saudáveis. Em muitos casos, porém, é mais simples e seguro rebaixar o DC com problema, limpar os metadados e promover um servidor novo, que recebe o AD por replicação.

A restauração autoritativa serve para outro problema: recuperar objetos que foram excluídos ou alterados de forma errada e cuja mudança já se espalhou pela replicação. Primeiro se faz uma restauração não autoritativa. Depois, ainda em DSRM, os objetos que devem prevalecer são marcados como autoritativos, e o AD aumenta o número de versão deles para que se sobreponham às cópias dos outros DCs. O fluxo básico com o ntdsutil é:

1. Executar ntdsutil e ativar a instância com activate instance ntds;
2. Entrar no contexto authoritative restore;
3. Marcar um objeto com restore object "CN=Joao Silva,OU=Financeiro,DC=empresa,DC=local" ou uma OU inteira com restore subtree "OU=Financeiro,DC=empresa,DC=local";
4. Reiniciar o servidor normalmente e deixar a replicação levar os objetos restaurados aos outros DCs;
5. Importar com ldifde os arquivos .ldf gerados pelo processo, que recuperam os vínculos de associação a grupos (back-links) em ambientes com mais de um domínio.

A pasta SYSVOL também pode precisar de restauração autoritativa, por exemplo quando GPOs foram corrompidas em todos os DCs. Com o wbadmin, isso é feito com o parâmetro -authsysvol na recuperação do estado do sistema. Em ambientes com replicação DFSR, há um procedimento próprio que define um DC como fonte autoritativa e os demais como não autoritativos. São operações delicadas, e o ideal é já tê-las testado em laboratório antes de precisar delas.

Lixeira do AD e outras proteções que evitam chegar ao backup

Restaurar em DSRM é um processo pesado: tira um DC do ar e exige mão de obra especializada. Para os incidentes mais comuns, como um usuário, um grupo ou uma OU apagados por engano, existem recursos que resolvem o problema em minutos e sem parar nada.

• Lixeira do Active Directory (AD Recycle Bin): exige nível funcional de floresta Windows Server 2008 R2 ou superior. Depois de ativada, guarda os objetos excluídos com todos os atributos e associações a grupos. Eles podem ser restaurados pelo Centro Administrativo do AD ou pelo PowerShell com Restore-ADObject. A ativação é irreversível, mas não tem efeito colateral relevante e deveria estar ligada em todo domínio.
• Proteção contra exclusão acidental: opção que impede apagar OUs e objetos críticos sem antes desmarcar a proteção. É simples e evita muitos incidentes.
• Backup de GPOs: com Backup-GPO -All -Path, as políticas de grupo podem ser salvas e restauradas uma a uma, sem precisar restaurar a SYSVOL inteira.
• Auditoria e menor privilégio: poucas contas com direitos de Domain Admin, auditoria de alterações no diretório e alertas sobre mudanças em grupos privilegiados.

Esses recursos complementam o backup, não o substituem. A lixeira não ajuda se o banco de dados corromper, se todos os DCs forem criptografados ou se o atacante tiver privilégio para esvaziá-la. Para esses cenários, só há o backup do estado do sistema, isolado e testado.

Recuperação de floresta: o plano para o pior cenário

O pior cenário para um ambiente Windows é perder todos os controladores de domínio ao mesmo tempo. Isso costuma acontecer em ataques de ransomware, em que os criminosos usam credenciais administrativas para criptografar os DCs e todos os servidores do domínio. Também acontece quando o AD foi tão comprometido que não dá mais para confiar em nenhum DC. Nesses casos, é preciso fazer a recuperação de floresta, um procedimento que a Microsoft documenta em detalhe no seu guia de recuperação de floresta do AD.

A ideia central é reconstruir o AD a partir de um único DC confiável por domínio, restaurado de um backup anterior ao incidente, em uma rede isolada. Em resumo, as etapas são:

1. Identificar a causa e escolher um backup comprovadamente anterior ao comprometimento, de preferência de um DC que também seja catálogo global;
2. Restaurar esse DC em rede isolada, sem contato com os servidores afetados;
3. Assumir à força (seize) as funções FSMO que estavam em outros DCs;
4. Invalidar o pool de RIDs atual e aumentar o valor do próximo RID, para não gerar identificadores duplicados;
5. Redefinir duas vezes a senha da conta krbtgt, invalidando tíquetes Kerberos que um atacante possa ter forjado, e redefinir as senhas das contas de computador dos DCs e das relações de confiança;
6. Limpar os metadados dos DCs que não serão recuperados e ajustar o DNS;
7. Promover novos controladores de domínio a partir do DC recuperado e só então reconectar o ambiente à rede de produção.

Esse plano só funciona se o backup sobreviver ao ataque. Por isso, os backups dos DCs precisam ter uma cópia offline ou imutável, fora do alcance das credenciais do domínio, seguindo a regra 3-2-1. Um repositório de backup que entra no mesmo domínio, com as mesmas senhas de administrador, costuma ser o primeiro alvo do invasor.

Recuperar uma floresta não é hora de improvisar. As empresas que voltam em horas, e não em semanas, testaram o procedimento antes, em laboratório isolado, com um backup real.

Como a Duk protege o Active Directory dos clientes

Na Duk Informática & Cloud, o Active Directory faz parte do núcleo da estratégia de continuidade de cada cliente. Em mais de 18 anos atendendo mais de 550 empresas, vimos que os incidentes mais caros raramente vêm de falha de hardware. Eles vêm de exclusões acidentais que ninguém soube desfazer, de backups que nunca foram testados e de ataques que encontraram o repositório de backup dentro do próprio domínio.

Como Microsoft Gold Partner, implementamos e operamos a proteção do AD de ponta a ponta. Isso inclui backup diário e consistente do estado do sistema de mais de um controlador de domínio, cópias imutáveis e isoladas no nosso data center em Alphaville, Lixeira do AD ativada, backup de GPOs, controle da senha DSRM em cofre seguro e monitoramento da saúde da replicação. Também documentamos e testamos os procedimentos de restauração autoritativa e de recuperação de floresta, para que o tempo de retorno seja conhecido antes da crise.

Se você não tem certeza de que conseguiria recuperar o seu domínio depois de um ataque ou de um erro grave, vale fazer uma avaliação. A equipe da Duk pode analisar o seu ambiente, apontar os riscos e montar um plano de backup e recuperação do Active Directory sob medida para a sua operação.