O TPM teve que ser reintializado: Uma nova senha de recuperação precisa ser carregada no AD?

De alguma forma, a máquina de um usuário não conseguiu ler a senha do bitlocker do chip TPM, e eu tive que inserir a chave de recuperação (armazenada no AD) para entrar. Não é grande coisa, mas uma vez na máquina, eu tentou suspender o bitlocker por documentação de recuperação e recebeu uma mensagem de erro sobre o TPM não estar sendo inicializado. Eu sabia que o TPM estava ativado e ativado no BIOS, mas o Windows ainda me fez reinicializar o chip TPM e, no processo, criou uma nova senha de proprietário do TPM.

Achei isso estranho, porque me levou a salvar essa senha ou imprimi-la (não havia uma opção para não fazê-lo), mas não fez referência a uma senha de recuperação, nem fez o backup dessa senha no AD.

Depois que o usuário pegou o laptop e saiu, comecei a pensar que, se a senha do TPM for alterada, a senha de recuperação também será alterada? Nesse caso, essa nova senha de recuperação precisará ser carregada no AD, mas a documentação da MS não esclarece isso e não faz backup da nova chave de recuperação (se houver) no AD automaticamente quando a política de grupo diz isso. deve, e do ponto de vista da rede, o AD está acessível.

Quando o BitLocker criptografa uma unidade, mantém a chave de criptografia principal na própria unidade, embora não em texto sem formatação. A senha mestra é mantida em si criptografada por "Protetores". Cada um deles mantém uma cópia separada da chave mestra, pois apenas o protetor que a criptografou pode descriptografar essa cópia da chave mestra.

Quando o Windows criptografa um volume por meio da GUI, ele geralmente cria dois protetores: uma Senha de Recuperação (RP) e uma chave TPM. Como observado acima, eles são armazenados completamente separadamente. Se você tiver o GPO configurado sempre que um RP for criado, ele será armazenado no AD. Isso é totalmente automático e se você tiver o GPO configurado, um RP não poderá ser salvo no disco sem fazer o upload para o AD (ou seja, nenhuma criação de RP offline, pois o AD não estaria disponível).

Eu sugiro fortemente abandonar a GUI. Ele encobre demais a função do BitLocker para um administrador de sistema, e a operação real do BitLocker realmente não é tão complicada. O utilitário CLI manage-bdevem com todas as versões do Windows que oferecem suporte ao BitLocker. É bem simples, embora a sintaxe seja um pouco detalhada.

Para ver o que a unidade do laptop está fazendo agora, basta executar manage-bde -status C:. Quanto aos problemas do TPM, depois de desbloquear o PC e inicializar o Windows, eu sempre corro manage-bde -protectors -get C:, copie o ID do protetor do TPM (incluindo colchetes), depois execute manage-bde -protectors -delete C: -id {the_id_you_copied}e finalmente manage-bde -protectors -add C: -tpm. São 30 segundos a mais de trabalho, mas você sabe exatamente o que está fazendo e exatamente onde está depois.

Sei que isso é antigo, cheguei aqui à procura de outra coisa, mas, na minha experiência, o upload automático para o AD após uma alteração como essa nem sempre é bem-sucedido. Fui mordido no trabalho várias vezes por causa disso. Após a 2ª vez, decidi criar um script para o processo de upload para garantir que isso aconteça, em vez de depender do processo de upload automagic que deveria acontecer. Aqui está o que eu escrevi (BitLocker_UploadToAD.cmd):

@Echo Off
cls
SETLOCAL
for /F "tokens=*" %%a in ('c:\windows\system32\manage-bde -protectors -get c: -type recoverypassword ^| findstr "ID: " ') DO SET ID=%%a
ECHO ID FOR DRIVE C IS: %ID%
ECHO.
ECHO REMOVING COLON AND ADDING HYPHEN TO BEGINNING...
ECHO.
set ID=-%ID::=%
ECHO NEW VALUE:
ECHO %ID%
ECHO.
ECHO BACKING UP TO AD...
c:\windows\system32\manage-bde -protectors -adbackup c: %ID%
ECHO.
ECHO DONE  (PLEASE CHECK AD TO VERIFY IT WORKED)
PAUSE