TPM нужно было повторно инициализировать: нужно ли загружать новый пароль восстановления в AD?

Каким-то образом, каким-то образом, пользовательский компьютер не смог прочитать пароль битлокера с микросхемы TPM, и мне пришлось ввести ключ восстановления (хранящийся в AD), чтобы войти. Ничего страшного, но однажды в машине я попытался приостановить работу BitLocker в соответствии с документацией по восстановлению и получил сообщение об ошибке, что TPM не инициализируется. Я знал, что TPM был включен и активирован в BIOS, но Windows все еще заставляла меня повторно инициализировать чип TPM, и в процессе он создал новый пароль владельца TPM.

Я нашел это странным, потому что это побудило меня сохранить этот пароль или распечатать его (не было возможности не делать этого), но в нем не было ссылки на пароль восстановления, и при этом он не поддерживал этот пароль до AD.

После того, как пользователь взял ее ноутбук и ушел, я начал думать, что, если пароль TPM изменится, пароль восстановления также изменится? Если это так, то этот новый пароль восстановления необходимо будет загрузить в AD, но документация MS не проясняет это и не создает резервную копию нового ключа восстановления (если он существует) в AD автоматически, когда групповая политика сообщает это. должен и с точки зрения сети AD доступен.

Когда BitLocker шифрует диск, он сохраняет главный ключ шифрования на самом диске, хотя и не в текстовом формате. Главный пароль хранится в зашифрованном виде с помощью «Защитников». Каждый из них хранит отдельную копию мастер-ключа, так как только защитник, зашифровавший его, может расшифровать эту копию мастер-ключа.

Если у вас есть Windows, шифрующая том через графический интерфейс, она обычно создает два защитника: пароль восстановления (RP) и ключ TPM. Как отмечено выше, они хранятся совершенно отдельно. Если у вас настроен объект групповой политики каждый раз при создании RP, он сохраняется в AD. Это полностью автоматический режим, и если у вас настроен объект групповой политики, RP нельзя сохранить на диск без загрузки в AD (т. Е. Создание автономного RP, поскольку AD не будет доступно).

Я настоятельно рекомендую отказаться от GUI. Он слишком затушевывает функцию BitLocker для системного администратора, и фактическая работа BitLocker на самом деле не так уж и сложна. Утилита CLI manage-bdeпоставляется с каждой версией Windows, которая поддерживает BitLocker. Это довольно просто, хотя синтаксис немного многословен.

Чтобы увидеть, что сейчас делает ноутбук, просто запустите manage-bde -status C:. Что касается вопросов , ТРМ, после разблокировки компьютера и загрузку Windows , я всегда запускать manage-bde -protectors -get C:, копировать идентификатор для защитника ТРМ (включая скобки), а затем запустить manage-bde -protectors -delete C: -id {the_id_you_copied}и , наконец manage-bde -protectors -add C: -tpm. Это на 30 секунд больше работы, но вы точно знаете, что он делает, и где именно вы стоите после.

Я знаю, что это старое, попал сюда в поисках чего-то другого, но по моему опыту автоматическая загрузка в AD после такого изменения не всегда успешна. Я был укушен на работе несколько раз из-за этого. После второго приема я решил написать сценарий процесса загрузки, чтобы он не зависел от процесса автоматической загрузки, который должен был произойти. Вот что я написал (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