TPM нужно было повторно инициализировать: новый пароль восстановления должен быть загружен в AD?
Каким-то образом каким-то образом машина пользователя не смогла прочитать пароль битлокера с микросхемы TPM, и мне пришлось ввести ключ восстановления (хранящийся в AD), чтобы войти. Ничего страшного, но однажды в машине я попытался приостановить работу BitLocker в соответствии с документацией по восстановлению и получил сообщение об ошибке, что TPM не инициализируется. Я знал, что TPM был включен и активирован в BIOS, но Windows все еще заставляла меня повторно инициализировать чип TPM, и в процессе он создал новый пароль владельца TPM.
Я обнаружил, что это странно, потому что это побудило меня сохранить этот пароль или распечатать его (не было возможности не делать этого), но в нем не было ссылки на пароль восстановления, и при этом он не поддерживал этот пароль до AD.
После того, как пользователь взял ее ноутбук и ушел, я начал думать, что если пароль TPM изменится, пароль восстановления также изменится? Если это так, то этот новый пароль восстановления необходимо будет загрузить в AD, но документация MS не проясняет это и не создает резервную копию нового ключа восстановления (если он существует) в AD автоматически, когда групповая политика сообщает это. должен и с точки зрения сети AD доступен.
2 ответа
Когда BitLocker шифрует диск, он сохраняет главный ключ шифрования на самом диске, хотя и не в текстовом формате. Главный пароль хранится в зашифрованном виде с помощью "Защитников". Каждый из них хранит отдельную копию мастер-ключа, так как только защитник, зашифровавший его, может расшифровать эту копию мастер-ключа.
Если у вас есть Windows, шифрующая том через графический интерфейс, она обычно создает два защитника: пароль восстановления (RP) и ключ TPM. Как отмечено выше, они хранятся совершенно отдельно. Если у вас настроен объект групповой политики каждый раз при создании RP, он сохраняется в AD. Это полностью автоматический режим, и если у вас настроен объект групповой политики, RP нельзя сохранить на диск без загрузки в AD (т. Е. Создание автономного RP, поскольку AD не будет доступно).
Я настоятельно рекомендую отказаться от GUI. Он слишком затушевывает функцию BitLocker для системного администратора, и фактическая работа BitLocker на самом деле не так уж и сложна. Утилита CLI manage-bde поставляется с каждой версией Windows, которая поддерживает BitLocker. Это довольно просто, хотя синтаксис немного многословен.
Чтобы увидеть, что сейчас делает ноутбук, просто запустите manage-bde -status C:, Что касается проблем TPM, после разблокировки ПК и загрузки Windows я всегда запускаю manage-bde -protectors -get C: скопируйте идентификатор для защитника TPM (включая скобки), затем запустите 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