Короткий ответ

Экран BitLocker Recovery — не приглашение отформатировать диск. Идентификатор ключа на экране сопоставьте с msFVE-RecoveryInformation объекта компьютера в AD, с MBAM/Configuration Manager, с Entra (если hybrid/cloud escrow), с распечаткой в сейфе. Вводите 48-значный ключ, загружайтесь, сразу добавьте актуальный protector и забэкапьте новый ключ. Нет ключа нигде — это потеря данных либо восстановление из проверенного backup диска, не «подбор».

Не публикуйте ключи в заявке открытым текстом шире, чем нужно. Не отключайте Defender на recovery-экране — его там нет; после входа не выключайте защиту, чтобы «больше не спрашивал». Причина повторных recovery — PCR/железо/политика, её надо закрыть.

Симптомы и как отличить

  • Синий/чёрный экран BitLocker, просит recovery key, показывает Key ID / диск.
  • После замены диска/матплаты/включения/выключения Secure Boot.
  • После накопительного обновления на части железа (реже) или стыковки новой док-станции при жёстких PCR.
  • Пользователь «никогда не видел ключ», IT «думали, что в AD».
КартинаИное
Том ещё OffBitLocker не включается, не recovery
Windows грузится, BitLocker просит пароль data-volumeдругой том, тот же поиск ключа
Неверный ключдругой Key ID, несколько объектов recovery
Ransomware-заставка «BitLocker»социальная инженерия; не путать со штатным экраном Windows

Возможные причины

  1. Эскроу в AD не настроили до включения шифрования.
  2. Компьютер переименовали / пересоздали аккаунт, старый объект с ключом в LostAndFound/другой OU.
  3. Права helpdesk не позволяют читать msFVE.
  4. Ключ в MBAM, ищут только в ADUC.
  5. Смена TPM/железа, ключ есть, но его не искали.
  6. Ключ удалили «почистить AD» без регламента.

Диагностика

С экрана: запишите имя ПК, Key ID (первые знаки), том.

С рабочей админ-станции, не с заблокированного хоста:

$dn = (Get-ADComputer 'WS-042').DistinguishedName
Get-ADObject -Filter 'objectClass -eq "msFVE-RecoveryInformation"' -SearchBase $dn -Properties *

В графике: ADUC → View → Advanced Features → компьютер WS-042 → BitLocker Recovery / дочерние объекты.

Права:

dsacls $dn

Группа helpdesk должна уметь читать recovery information на OU — это не то же самое, что LAPS. Не выдавайте Domain Admins всем, см. лишние права.

MBAM / ConfigMgr: консоль recovery, поиск по имени компьютера и Key ID. Entra: портал BitLocker keys для устройства, если escrow туда настроен.

Backup: есть ли образ диска до инцидента (Veeam и т.д.) — план Б, если ключа нет.

Решение

Сценарий A. Ключ найден в AD/MBAM/Entra

  1. Введите ключ на экране (цифры, Windows принимает без дефисов в типичном UI).
  2. Загрузите ОС, войдите.
  3. Проверьте том и протекторы:
Get-BitLockerVolume -MountPoint 'C:' | Format-List VolumeStatus, KeyProtector, ProtectionStatus
  1. Если TPM снова валиден — оставьте. Если железо меняли — добавьте TPM заново по документу, новый recovery password в AD:
Add-BitLockerKeyProtector -MountPoint 'C:' -RecoveryPasswordProtector
Backup-BitLockerKeyProtector -MountPoint 'C:' -KeyProtectorId <id-нового-recovery>
  1. Старые recovery-объекты не копите бесконечно, но не чистите до проверки нового эскроу.

Сценарий B. Ключа нет, есть backup диска

Восстановите том/VM из backup на новое место, проверьте данные. Не форматируйте единственную копию. Ключ BitLocker backup-образа может отличаться — восстановление образа целиком обычно не требует ключа живой машины.

Сценарий C. Ключа нет, backup нет

Это потеря зашифрованных данных. Честно зафиксируйте. Не используйте «утилиты с торрента для BitLocker». Законный путь: только ключ или копия данных до шифрования.

Сценарий D. Повторяется после каждого патча/дока

Снимите причину PCR: политика PCR, док-станция, опции BIOS. Обновите прошивку с сайта вендора. Не выключайте Secure Boot на всём парке как «лечение recovery».

Ключ с DC01 читайте с jump под группой recovery, не под Domain Admins с почты. Если WS-042 переименовывали, ищите старый sAMAccountName в AD и в MBAM. В contoso.example запретите удаление msFVE-RecoveryInformation скриптами «уборки». После успешного ввода ключа перезагрузите хост ещё раз: одно удачное появление рабочего стола не доказывает, что PCR стабильны.

Как проверить, что проблема устранена

Хост грузится без recovery. В AD есть свежий recovery object, Key ID известен IT. Пользовательский вход ок. Повторная перезагрузка (не один раз). Если меняли железо — документирован новый TPM protector.

Проверка чтения ключа с учётки helpdesk (на копии/тесте), не с Domain Admin.

Если не помогло

  • Несколько WS-042 в домене исторически — ищете не тот объект.
  • Ключ от data D: вводят на C: — сверьте том на экране.
  • Hybrid: ключ в Entra, не в AD.
  • Кластер/CSV — не ноутбучный runbook.
  • После ввода ключа сразу снова recovery: TPM/PCR всё ещё не совпадают — чините железо/политику, не «ещё раз format».

Профилактика

  • GPO: не включать BitLocker, пока recovery не в AD.
  • Мониторинг компьютеров без recovery objects при Protection On.
  • Регламент замены матплаты: снять ключ до разбора, или иметь эскроу.
  • Ограничить, кто читает msFVE.
  • Обучение: экран recovery ≠ ransomware, но и не format.

См. также включение BitLocker и базовые риски.

FAQ

Ключ в Microsoft-аккаунте пользователя?

Для личных устройств да. Для WS-042 в contoso.example цель — AD/MBAM/Entra организации, не личный MSA.

Можно ли отключить BitLocker после recovery, чтобы не повторялось?

Можно расшифровать, если решили не шифровать (не рекомендуется для ноутбуков). Причина повторов от этого не лечится, если снова включите. Лучше починить TPM/политику.

Helpdesk должен видеть все ключи леса?

Нет. OU-ограничение. Чтение всех ключей = чтение всех дисков компании.

manage-bde -protectors -get

После входа показывает ID протекторов. Сопоставьте с AD. Без входа смотрите только AD/MBAM.

VM снапшот откатился — другой ключ?

Состояние TPM/ключа может разъехаться со снапшотами. Для зашифрованных VM снапшоты — отдельная дисциплина гипервизора.

Форматировать быстрее?

Только если данные не нужны и это согласовано. Иначе это уничтожение, не восстановление.