Falha no backup das informações de recuperação do BitLocker para o Active Directory (criptografia concluída com sucesso): como investigar permissões de diretório e conectividade de domínio?

Ronaldo Cristiano 20 Pontos de reputação
2026-10-27T16:10:23.63+00:00

Tentativas de realizar o backup das informações de recuperação do BitLocker para o Active Directory falham com erro de sincronização nos estações de trabalho do domínio empresarial, mesmo com a criptografia concluída com sucesso no disco local. Como investigamos as permissões de diretório, a conectividade com o domínio, os requisitos de política de grupo e o status do backup da senha de recuperação em nosso ambiente corporativo ativo?

Windows para empresas | Windows 365 Enterprise
0 comentários Sem comentários

1 resposta

Classificar por: Mais útil
  1. Chen Tran 13,695 Pontos de reputação Assistente Independente
    2026-10-27T18:29:39.3533333+00:00

    Olá @Anonymous ,

    Obrigado por postar sua pergunta no Fórum do Microsoft Windows!

    Com base na descrição do problema. Pois é! Quando o BitLocker criptografa com sucesso um disco local, mas não sincroniza suas informações de recuperação com o Active Directory, a quebra normalmente aponta para um bloco de controle de acesso no objeto do computador, uma configuração de política de grupo ausente ou uma barreira de comunicação do controlador de domínio.

    Quanto à permissão de diretório, por padrão, computadores de domínio padrão têm permissão para escrever objetos contêineres msFVE-RecoveryInformation sob seu próprio objeto de computador no Active Directory. No entanto, falhas de sincronização ocorrem se essas permissões foram removidas, herdadas incorretamente ou se o contêiner estiver ausente. Para verificar a estrutura do contêiner, recomendo abrir o Active Directory Users and Computers (ADUC), depois ativar Recursos Avançados no menu Visualizar, navegar até o objeto computador da estação de trabalho alvo e expandi-lo para confirmar se o contêiner msFVE-RecoveryInformation existe abaixo do nó do computador. Também verificar as Listas de Controle de Acesso Discricionárias (DACL) garantindo que o principal de segurança SELF mantenha permissões de Controle Total ou Criar/Deletar Objetos Filhos explícitos sobre a classe msFVE-RecoveryInformation. Se modelos de segurança em todo o domínio ou linhas básicas de reforço bloquearam permissões padrão do computador, certifique-se de que não tenham bloqueado a criação de objetos filhos para contas de computador.

    Para requisitos de Política de Grupo, na verdade, o BitLocker não fará backup automático das informações de recuperação a menos que as políticas corretas estejam ativadas e tenham sido realmente aplicadas à estação de trabalho. As políticas devem ser ativadas incluem "Armazenar informações de recuperação do BitLocker nos Serviços de Domínio do Active Directory". Garantir que as opções para armazenar senhas de recuperação e pacotes de chaves estejam marcadas e "Escolha como o BitLocker protegido [Tipo de acionamento] pode ser recuperado" dentro dessa política, selecione "Salvar informações de recuperação do BitLocker no AD DS" e escolha "Backup de senhas e pacotes de chaves" como opção de backup. Se sua política de segurança exigir que os discos não podem ser criptografados sem um depósito de diretório bem-sucedido, a política "Não habilitar o BitLocker até que informações de recuperação estejam armazenadas no AD DS" deve ser ativada. Você pode encontrar as políticas mencionadas acima neste caminho GPO Configuração de Computadores → Modelos Administrativos → Componentes do Windows → Criptografia de Disco BitLocker.

    Quanto à conectividade do domínio no momento da criptografia, já que o backup da chave de recuperação é uma operação em tempo real. Se a estação de trabalho não conseguir alcançar um controlador de domínio quando o BitLocker estiver habilitado, o backup falha e o BitLocker não tenta automaticamente novamente posteriormente. Portanto, o BitLocker deve ser ativado após o computador entrar no domínio e a GPO de recuperação ter sido aplicada. Se a criptografia ocorreu antes da junção ao domínio, a junção posterior não aciona um depósito retroativo automático das informações de recuperação existentes. Além disso, da estação de trabalho afetada, verifique a conectividade LDAP com um controlador de domínio. Testando as portas TCP 389 (LDAP) e 636 (LDAPS). Ao mesmo tempo, certifique-se de que a máquina está autenticando em um controlador de domínio no domínio correto e que a replicação do objeto do computador foi concluída.

    Para confirmar se a senha de recuperação está realmente presente no AD. Você pode executar o comando manage-bde -protectors -get C: para listar o protetor de senha de recuperação e seu ID. Se um protetor existir localmente, mas estiver ausente no AD, o escrow falhou.

    Você pode consultar o artigo a seguir para mais referência.

    Espero que esta resposta tenha te fornecido informações úteis. Se você achou útil, clique em "Aceitar Resposta" para confirmar que respondeu à sua dúvida.

    Esta resposta foi útil?


Sua resposta

As respostas podem ser marcadas como ‘Aceitas’ pelo autor da pergunta e ‘Recomendadas’ pelos moderadores, o que ajuda os usuários a saber a resposta que resolveu o problema do autor.