BitLocker i klucz odzyskiwania po aktualizacji Windows: Intune, escrow w Entra ID i realna procedura helpdesku (TPM, PCR)

TL;DR: Masowy ticket „niebieski ekran, 48 cyfr” po cumulative update to zwykle nie „zepsuty BitLocker”, tylko zmiana stanu TPM/Secure Boot albo polityki PCR, czasem połączona z brakiem świeżego backupu klucza do Entra ID. Ten tekst rozkłada to na: weryfikację protectorów na dysku (Get-BitLockerVolume), odczyt klucza z Entra (Graph / portal) z uwzględnieniem ról i Autopilot reuse, oraz rotację po incydencie. Na końcu masz też odniesienie do Nexmy jako sposobu na spięcie zgłoszenia, identyfikacji urządzenia i audytu — bez zastępowania Microsoftowego modelu uprawnień.

Problem

Helpdesk budzi się z komunikatem z Teams: użytkownik stoi na niebieskim ekranie BitLockera, widzi Recovery Key ID (np. pierwsze znaki identyfikatora) i prosi o „hasło z firmy”. Równolegle na kanale MSP ktoś wrzuca link do wątku na r/Intune o hotpatchu i niespodziewanym recovery — i nagle masz pięćdziesiąt takich samych ticketów w ciągu jednego dnia po patch Tuesday.

Drugi wariant jest jeszcze gorszy do debugowania: laptop bootuje normalnie, ale co drugi restart Intune raportuje „BitLocker compliance: non-compliant”, a w logach widzisz, że polityka escrow do Entra ID nie wykonała backupu od tygodnia, mimo że użytkownik twierdzi, że „nic nie zmieniał”. W obu przypadkach biznes oczekuje dwóch rzeczy jednocześnie: szybkiego odblokowania oraz wyjaśnienia, czemu to się powtórzy — bez przerzucania winy między „Windows team” a „Intune team”.

Dlaczego tak się dzieje

BitLocker na dysku systemowym z TPM nie trzyma jednego magicznego hasła użytkownika. Masz protectory: TPM (z profilem platformy PCR), ewentualnie PIN, startup key na USB, numer odzyskiwania 48 cyfr. Gdy któryś pomiar PCR się nie zgadza po aktualizacji UEFI/TPM albo po zmianie boot chain (secure boot policy, firmware, niektóre CU w 2025–2026 raportowały masowe wejścia w recovery przy specyficznej kombinacji PCR7 i raportu Secure Boot), TPM odmawia unseal i jedyną ścieżką zostaje recovery password.

Równolegle backup klucza do Microsoft Entra ID nie jest filozofią „włączyłem BitLockera i sam poleci”. Microsoft wprost ostrzega w dokumentacji recovery: kopia do Entra lub AD może nie nastąpić automatycznie, jeśli nie wymusiłeś tego polityką MDM/GPO. W praktyce widzę to najczęściej po ręcznym włączeniu BL na starym image albo po imporcie polityki z laboratorium, gdzie sekcja escrow była „Not configured”.

Trzeci tor to tożsamość urządzenia w Entra: klucz jest przypięty do obiektu device. Przy Autopilot reuse i zmianie primary usera dokumentacja Entra mówi wprost o sytuacji, w której nowy właściciel musi iść po klucz do administratora — a administrator z rolami ograniczonymi do Administrative Unit nie zobaczy klucza, jeśli urządzenie wypadło z jego zakresu po zmianie własności. To nie jest bug — to model delegacji, który ratuje przed „globalnym adminem czytającym wszystko”, ale zabija SLA helpdesku, jeśli nie macie runbooka.

Rozwiązanie krok po kroku

Krok 1 — potwierdź, co użytkownik naprawdę widzi

Na telefonie nie zgaduj: poproś o zdjęcie ekranu recovery albo o Recovery Key ID (identyfikator klucza, nie pełne 48 cyfr). Recovery Key ID to filtr w Entra / Graph — bez tego możesz pobrać „jakiś” klucz z urządzenia o tej samej nazwie, który nie pasuje do bieżącego protector chain po rotacji.

Krok 2 — lokalna diagnostyka (jeśli masz zdalny dostęp lub SafeOS)

Na zablokowanym wolumenie OS nie odpalisz PowerShell; ten blok jest dla scenariusza „już odblokowaliśmy recovery i chcemy wiedzieć dlaczego”. Na działającym Windows:

Get-BitLockerVolume -MountPoint 'C:' | Select-Object MountPoint,VolumeStatus,ProtectionStatus,EncryptionPercentage
(Get-BitLockerVolume -MountPoint 'C:').KeyProtector | Format-Table KeyProtectorType, KeyProtectorId, AutoUnlockProtector

KeyProtectorType interesuje Cię w pierwszej kolejności jako Tpm vs RecoveryPassword. Jeśli VolumeStatus jest FullyEncrypted, a ProtectionStatus On, ale Intune dalej krzyczy o escrow, problem jest po stronie MDM policy pipeline, nie TPM.

Krok 3 — escrow: sprawdź, czy backup faktycznie istnieje w Entra

W centrum administracyjnym Entra: Identity → Devices → All devices → [device] → BitLocker keys (nazewnictwo UI bywa aktualizowane — szukaj sekcji z kluczami recovery). Jeśli pusto mimo włączonego BitLockera, wróć do Intune: profil Endpoint protection / BitLocker musi wymuszać backup recovery password do Azure AD (dla AADJ/Hybrid). W przeciwnym razie helpdesk będzie zbierał dane jak na szkoleniu Microsoft: „Verify identity → record device name → record recovery key ID → locate password”.

Krok 4 — odczyt klucza z Graph (skryptowalnie, z audytem)

Microsoft dokumentuje ścieżkę przez Graph. Przykładowy szkielet (moduł Graph, uprawnienia aplikacji lub delegated — zgodnie z waszym modelem):

# Wymaga połączenia MgGraph z odpowiednimi scope: BitLockerKey.Read.All lub roli admina z microsoft.directory/bitlockerKeys/key/read
$dev = Get-MgDevice -Filter "displayName eq 'LAPTOP-12345'"
Get-MgInformationProtectionBitlockerRecoveryKey -Filter "deviceId eq '$($dev.DeviceId)'" |
  ForEach-Object {
    $full = Get-MgInformationProtectionBitlockerRecoveryKey -BitlockerRecoveryKeyId $_.Id -Property key
    [pscustomobject]@{ Id = $_.Id; Created = $_.CreatedDateTime; Vol = $_.VolumeType }
  }

W produkcji nie wklejaj klucza do czatu z użytkownikiem — przekaż go przez kanał out-of-band zarejestrowany w polityce bezpieczeństwa (telefon zwrotny, osobisty portal, zaszyfrowany ticket z jednorazowym linkiem). 48 cyfr łatwo przekręcić; konsola recovery ma checksum per blok 6 cyfr, ale nadal lepiej unikać dyktowania przez Slacka.

Krok 5 — po wejściu w recovery: TPM „uspij” na czas aktualizacji firmware / CU

Gdy root cause to zmiana PCR (UEFI, TPM firmware, cumulative update), klasyczna procedura serwisowa to suspend na jeden restart:

Suspend-BitLocker -MountPoint 'C:' -RebootCount 1
# reboot + instalacja aktualizacji
# po starcie Resume-BitLocker -MountPoint 'C:' (albo zrób to skryptem post-update)

Jeśli robicie to masowo przez Intune, rozważcie skrypt remediacji albo maintenance window zamiast ręcznego dzwonienia do każdego użytkownika — suspend na RebootCount 3 bywa bezpieczniejszy na leniwe restarty, ale wydłuża okno, w którym dysk jest technicznie mniej chroniony na offline atak — balansujcie z SecOps.

Krok 6 — rotacja klucza po incydencie

Po ujawnieniu recovery password do użytkownika powinien powstać nowy materiał sekretny. W Entra dla urządzeń hybrydowych / cloud joined Microsoft opisuje automatyczną rotację, jeśli jest włączona; ręcznie możesz użyć akcji zdalnej w Intune Rotate BitLocker recovery keys (dokładna nazwa w UI bywa „Rotate…”, API woła rotateBitLockerKeys). Po rotacji stary klucz przestaje działać — zaktualizuj dokumentację helpdesku, żeby nikt nie trzymał „PDF z kluczem z zeszłego tygodnia”.

Krok 7 — self-service zamiast kolejki Level 1

Microsoft udostępnia użytkownikom podgląd kluczy pod https://myaccount.microsoft.com w zakładce Devices → View BitLocker keys, o ile tenant nie ma restrykcji „Restrict users from recovering BitLocker keys” w default user permissions Entra. To jest realny sposób na zdjęcie 30% ticketów — pod warunkiem MFA na koncie i świadomości phishingu (klucz to praktycznie pełny dostęp do dysku).

Krok 8 — manage-bde tam, gdzie nie ma modułu BitLocker w starszym PS

Na serwerach i niektórych obrazach SAC nadal spotkasz środowisko bez rozszerzonego cmdlet surface; klasyczne narzędzie CLI jest wiarygodnym źródłem prawdy o PCR i ID protectorów:

manage-bde -status C:
manage-bde -protectors -get C:

Wyjście Numerical Password zawiera dokładny KeyProtectorId w GUID — ten sam identyfikator, którego szukasz w Entra przy wielu kluczach na jednym urządzeniu (OS vs fixed data). Jeśli widzisz kilka Recovery Password i różne daty utworzenia, użytkownik przechodził przez rotację albo przez ręczne Add-BitLockerKeyProtector podczas migracji dysku.

Krok 9 — Intune: compliance ≠ „klucz jest w chmurze”

Profil BitLocker w Intune ma kilka niezależnych sygnałów: czy szyfrowanie jest włączone, czy algorytm spełnia politykę, czy recovery password został zbackupowany do Entra. W konsoli MEM w raporcie urządzenia sekcja BitLocker bywa opóźniona o godziny — nie traktuj „brak wpisu” jako dowodu braku klucza, dopóki nie sprawdzisz bezpośrednio w Entra ID. Opóźnienie wynika z pipeline synchronizacji MDM → Windows → agenta raportującego; w incydencie masowym po CU lepiej oprzeć decyzję o eskalacji na Entra device blade, nie na ostatnim refreshu Intune z popołudnia.

Krok 10 — logi Windows po odblokowaniu (root cause, nie magia)

Po udanym recovery warto zebrać Microsoft-Windows-BitLocker/BitLocker Management z Podglądu zdarzeń: zdarzenia okolic 770 (backup do AD) i 775 (backup do Azure AD) mówią wprost, czy escrow się wykonał i czy był błąd sieciowy / certyfikatu do chmury. Jeśli widzisz powtarzający się błąd TLS do enterpriseregistration.windows.net, CA z SSL inspection na egress może tłuc backup klucza bez objawów w zwykłej przeglądarce — użytkownik i tak „ma internet”, bo port 443 działa, tylko konkretny chain nie przechodzi dla agenta MDM.

Krok 11 — role wbudowane vs custom role (żeby nie dawać Global Admin)

Microsoft wymienia m.in. Cloud Device Administrator i Helpdesk Administrator jako typowe role z dostępem do odczytu recovery password w Entra; dla MSP sensowniejszy jest custom role z minimalnym zestawem microsoft.directory/bitlockerKeys/key/read przypięty do AU według spółki czy kraju. Pamiętaj: każde nadanie roli z odczytem kluczy powinno iść przez ten sam ticket co numer zgłoszenia — inaczej audyt ISO 27001 pokaże „admin czytał klucze w piątek wieczorem bez powiązania z change”.

Krok 12 — Graph REST (gdy PowerShell modułu nie chcesz na stacji)

Endpoint GET https://graph.microsoft.com/v1.0/informationProtection/bitlocker/recoveryKeys?$filter=deviceId eq '{id}' zwraca metadane; pełny materiał klucza wymaga GET .../bitlocker/recoveryKeys/{key-id}?$select=key — dokładna składnia jest w dokumentacji bitlockerRecoveryKey resource. Automatyzacje typu „bot w Teams podaje klucz na komendę” są złe z punktu widzenia least privilege — jeśli już budujesz integrację, loguj client-request-id i koreluj z ticketem w narzędziu ITSM.

Typowe pułapki i edge cases

1. Urządzenie w Entra ma inną nazwę niż „naklejka na laptopie” — displayName po rename w Windows aktualizuje się opóźniony; filtruj po recovery key ID, nie po nazwie z Excela inwentaryzacji sprzed roku.

2. Scoped admin + Autopilot reuse — zgodnie z dokumentacją Microsoftu, po zmianie właściciela urządzenia klucze mogą być niewidoczne dla administratora z custom role przypiętej do AU; wtedy potrzebujesz operatora z pełniejszym zakresem albo procedury break-glass (nie chodzi o to, by obchodzić RBAC, tylko by mieć z góry wskazaną rolę „BitLocker escalation”).

3. Policy mismatch Hybrid AD Join — komputer jest hybrid joined, ale BitLocker backup idzie do AD DS zamiast Entra, bo MDM nie jest „authority”; helpdesk szuka w Entra i widzi pustkę. Rozwiązanie: albo popraw konfigurację backup target, albo ujednolicenie narzędzia odczytu (AD + narzędzie recovery password viewer).

4. KB z 2026 i PCR7 — publicznie opisywano fale fałszywych recovery po aktualizacjach, gdy Secure Boot / PCR binding raportowały się inaczej po CU (np. KB5083769 w ekosystemie Windows 11 w kwietniu 2026 — śledź komunikaty Microsoftu i release health). Jeśli macie GPO „Configure TPM platform validation profile for native UEFI firmware configurations” ustawione nietypowo, po CU może się zmienić zachowanie bez „grzechu” Intune.

5. „Klucz działał wczoraj” po rotacji Intune — technik wkleił stary klucz z maila; rotacja w Entra unieważnia poprzedni materiał. Zawsze pobieraj świeży rekord po rotateBitLockerKeys.

6. BitLocker Network Unlock — jeśli go używasz, recovery UI bywa mylące dla użytkownika; diagnostyka sieci (VLAN, PXE, availability KDS) to osobna gałąź, ale ticket wygląda identycznie jak „zły TPM”.

7. Double encryption / nested protectors po migracji Clonezilla — klon dysku z włączonym BL na innym sprzęcie często zostawia „martwe” protectory; recovery key ID na ekranie nie pokrywa się z żadnym rekordem w Entra, bo backup dotyczył poprzedniego TPM. Lekarstwo to świadoma reinicjalizacja z pełnym re-escrow po stronie MDM, nie wklejanie losowego klucza z innego laptopa.

Jak my to rozwiązujemy w Evolit

W Evolit spięcie ticketa helpdesku, inwentarza i tożsamości urządzenia w Entra robimy w Nexmie (nexma.app): użytkownik zgłasza problem w jednym flow, a technik widzi powiązane urządzenie i historię zgłoszeń zamiast szukać nazwy maszyny w trzech arkuszach. Nexma nie zastępuje Entra — nadal potrzebujesz roli z microsoft.directory/bitlockerKeys/key/read albo Helpdesk Administrator / Cloud Device Administrator zgodnie z modelem — ale eliminuje chaos „który to laptop Ani z księgowości” i zostawia ślad audytowy kto kiedy prosił o klucz. Alternatywnie całość da się prowadzić czysto w Entra + Service Desk + osobny CMDB, tylko kosztem czasu reakcji i większej liczby pomyłek przy identyfikacji urządzenia.

Drugim obszarem jest Nexma Agent przy problemach po odblokowaniu: zdalna diagnostyka protectorów i stanu MDM bez proszenia użytkownika o techniczne rzeczy, których nie rozumie — zamiast tego krótki consent i sesja z audytem zgodnym z polityką firmy.

Podsumowanie

• Recovery to proces procesowy + kryptograficzny: najpierw Recovery Key ID i weryfikacja tożsamości, potem dopiero klucz z Entra/AD.
• Get-BitLockerVolume i lista KeyProtector mówią prawdę o stanie na dysku; Intune compliance tylko to odzwierciedla.
• Escrow do Entra musisz mieć wymuszony polityką — inaczej helpdesk jest ślepy.
• Po incydencie rotuj klucz (rotateBitLockerKeys / automatyczna rotacja) i aktualizuj dokumentację.
• Rozważ kontrolowany self-service przez myaccount.microsoft.com, jeśli ryzyko akceptuje SecOps.
• Publiczne regresje CU/TPM śledź w Windows release health — reaguje szybciej niż „wyłącz BitLockera i włącz z powrotem”.