TPM tuvo que volver a escribirse: ¿se debe cargar una nueva contraseña de recuperación en AD?

De alguna manera, la máquina de un usuario no pudo leer la contraseña del bitlocker del chip TPM, y tuve que ingresar la clave de recuperación (almacenada en AD) para entrar. No es gran cosa, pero una vez en la máquina, intenté suspender bitlocker por documentación de recuperación y recibí un mensaje de error acerca de que el TPM no se inicializaba. Sabía que el TPM estaba activado y activado en el BIOS, pero Windows todavía me hizo reiniciar el chip TPM, y en el proceso creó una nueva contraseña de propietario de TPM.

Me pareció extraño porque me pidió que guardara esta contraseña o la imprimiera (no había una opción para no hacerlo), pero no hizo referencia a una contraseña de recuperación, ni devolvió esta contraseña a AD.

Después de que el usuario tomó su computadora portátil y se fue, comencé a pensar que si la contraseña de TPM cambia, ¿también cambia la contraseña de recuperación? Si es así, esa nueva contraseña de recuperación deberá cargarse en AD, pero la documentación de MS no lo aclara y no hace una copia de seguridad de la nueva clave de recuperación (si existe) en AD automáticamente cuando la política del grupo lo dice must, y desde el punto de vista de la red, AD es accesible.

Cuando BitLocker cifra una unidad, mantiene la clave de cifrado maestra en la unidad, aunque no en texto plano. La contraseña maestra se mantiene encriptada por "Protectores". Cada uno de estos conserva una copia separada de la clave maestra, ya que solo el protector que lo cifró puede descifrar esa copia de la clave maestra.

Cuando Windows encripta un volumen a través de la GUI, generalmente crea dos protectores: una contraseña de recuperación (RP) y una clave TPM. Como se señaló anteriormente, estos se almacenan completamente por separado. Si tiene el GPO configurado cada vez que se crea un RP, se almacena en AD. Esto es completamente automático y si tiene el GPO configurado, un RP no se puede guardar en el disco sin cargarlo en AD (es decir, no se puede crear RP fuera de línea ya que AD no estaría disponible).

Le sugiero que abandone la GUI. Descuida demasiado la función de BitLocker para un administrador del sistema, y ​​la operación real de BitLocker realmente no es tan complicada. La utilidad CLI manage-bdeviene con cada versión de Windows que admite BitLocker. Es bastante sencillo, aunque la sintaxis es un poco detallada.

Para ver qué está haciendo la unidad portátil ahora mismo, simplemente ejecute manage-bde -status C:. En cuanto a los problemas de TPM, después de desbloquear la PC y arrancar Windows siempre ejecuto manage-bde -protectors -get C:, copie la ID para el protector de TPM (incluidos los corchetes), luego ejecute manage-bde -protectors -delete C: -id {the_id_you_copied}y finalmente manage-bde -protectors -add C: -tpm. Es 30 segundos más de trabajo, pero sabes exactamente lo que está haciendo y exactamente dónde estás parado después.

Sé que esto es viejo, llegué aquí buscando algo más, pero en mi experiencia, la carga automática a AD después de un cambio como ese no siempre es exitosa. Me han mordido en el trabajo varias veces debido a esto. Después de que la segunda vez se mordiera, decidí hacer un script del proceso de carga para asegurarme de que ocurriera en lugar de depender del proceso de carga automático que se supone que sucederá. Esto es lo que escribí (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