BitLocker błędnie żądał klucza odzyskiwania. Microsoft w końcu naprawił błąd na Windows Server 2025
Microsoft potwierdził i naprawił usterkę, która powodowała, że część serwerów Windows Server 2025 po aktualizacji z kwietnia 2026 wymagała ręcznego podania klucza BitLockera. Problem dotyczył głównie firmowych konfiguracji z nierekomendowanymi ustawieniami zasad grupy.
Administratorzy systemów Windows Server 2025 mogą odetchnąć z ulgą. Microsoft potwierdził i w czerwcowej aktualizacji Patch Tuesday rozwiązał błąd, który zmuszał część serwerów do podania klucza odzyskiwania BitLockera po zainstalowaniu kwietniowej aktualizacji zabezpieczeń. Usterka dotyczyła specyficznych, nierekomendowanych konfiguracji zasad grupy i nie powinna była wystąpić na prawidłowo skonfigurowanych maszynach, ale jej skutki bywały uciążliwe. Dziś wiemy, jak ją trwale załatać i jak zabezpieczyć się przed podobnymi problemami w przyszłości.
nn
Czego dotyczył problem z odzyskiwaniem BitLockera?
nn
BitLocker to wbudowane w system Windows narzędzie do szyfrowania całych dysków, chroniące dane przed kradzieżą w przypadku fizycznego dostępu do nośnika. Standardowo po zmianach w sprzęcie lub aktualizacji modułu TPM (Trusted Platform Module) system może zażądać 48-cyfrowego klucza odzyskiwania, zanim uruchomi system. Taka sytuacja ma miejsce, gdy nie można odblokować dysku domyślnym mechanizmem.
nn
W kwietniu 2026 roku, po wydaniu aktualizacji KB5082063, część systemów Windows Server 2025 zaczęła wyświetlać ekran odzyskiwania BitLockera przy pierwszym restarcie po instalacji. Microsoft początkowo potwierdził problem w komunikacie dotyczącym kwietniowego Patch Tuesday, informując, że przyczyna leży w niezalecanej konfiguracji zasad grupy. Jak wyjaśniono wtedy: „Niektóre urządzenia z nierekomendowaną konfiguracją zasad grupy BitLockera mogą być zmuszone do wprowadzenia klucza odzyskiwania przy pierwszym restarcie po instalacji tej aktualizacji” – podał Microsoft.
nn
Co istotne, jeśli klucz został podany raz, kolejne restarty nie wymagały ponownego uwierzytelnienia – o ile administrator nie zmienił konfiguracji zasad. Problem nie dotyczył maszyn z domyślnymi ustawieniami BitLockera, ale takich, w których ręcznie zmodyfikowano sposób weryfikacji TPM. Mimo że usterka mogła wystąpić także na Windows 11, Microsoft zaznaczył, że jest mało prawdopodobna na urządzeniach osobistych – typowo dotykała środowisk zarządzanych przez działy IT w firmach.
nn
Jakie systemy były podatne? Warunki wywołania błędu
nn
Według szczegółowej analizy Microsoftu, błędne żądanie klucza pojawiało się przy jednoczesnym spełnieniu wszystkich poniższych warunków:
nn
- BitLocker jest włączony na dysku systemowym.
- Zasada grupy „Configure TPM platform validation profile for native UEFI firmware configurations” jest skonfigurowana, a rejestr PCR7 (Platform Configuration Register 7) jest uwzględniony w profilu walidacji (lub równoważny klucz rejestru ustawiono ręcznie).
- Narzędzie System Information (msinfo32.exe) raportuje, że Secure Boot State PCR7 Binding jest „Not Possible”.
- Certyfikat Windows UEFI CA 2023 jest obecny w bazie podpisów Secure Boot (DB), co czyni urządzenie kwalifikującym się do ustawienia menedżera rozruchu Windows podpisanego w 2023 roku jako domyślnego.
- Urządzenie nie korzysta jeszcze z menedżera rozruchu podpisanego w 2023 roku.
nn
Jak widać, nie były to przypadkowe zdarzenia – usterka dotyczyła wąskiego grona serwerów z niestandardową polityką bezpieczeństwa. Niemniej, w praktyce oznaczało to ryzyko blokady dostępu do danych w newralgicznym momencie, zwłaszcza w środowiskach, gdzie administratorzy nie mogli natychmiast interweniować.
nn
Czerwcowa łatka: jak Microsoft rozwiązał problem
nn
Podczas czerwcowego Patch Tuesday Microsoft opublikował aktualizacje KB5094125 (Windows Server 2025) oraz KB5093998 (Windows 11 23H2), które w końcu eliminują usterkę. W zaktualizowanych biuletynach firma poinformowała: „Ta aktualizacja rozwiązuje problem, w którym niektóre urządzenia mogły wchodzić w tryb odzyskiwania BitLockera po zaktualizowaniu plików rozruchowych w systemach z pewnymi ustawieniami walidacji TPM, w tym nieprawidłowymi konfiguracjami PCR7”.
nn
Mechanizm naprawy jest prosty, ale skuteczny: system zapobiega instalacji menedżera rozruchu podpisanego w 2023 roku na urządzeniach z niezgodną konfiguracją zasad grupy. Administratorzy, którzy już doświadczyli problemu, mogą sprawdzić identyfikator zdarzenia 1032 w dzienniku systemowym, który pojawiał się podczas instalacji aktualizacji na podatnych maszynach.
nn
Dla tych, którzy nie mogą na razie wdrożyć czerwcowych aktualizacji, Microsoft udostępnił dwa rozwiązania tymczasowe. Pierwsze to usunięcie konfiguracji zasad grupy przed instalacją kwietniowej aktualizacji i zapewnienie, że powiązania BitLockera używają profilu PCR7. Drugie to zastosowanie mechanizmu Known Issue Rollback (KIR) na dotkniętych urządzeniach, co zapobiega automatycznemu przejściu na menedżer rozruchu z 2023 roku, który wywołuje żądanie klucza.
nn
Wnioski dla administratorów: jak zapobiegać podobnym usterkom
nn
Opisywany incydent to kolejne przypomnienie, że nawet sprawdzone mechanizmy bezpieczeństwa, takie jak BitLocker, mogą generować problemy w specyficznych konfiguracjach. Dla zespołów IT zarządzających serwerami Windows oto kilka praktycznych zaleceń:
nn
- Regularnie weryfikuj konfigurację zasad grupy związanych z BitLockerem, zwłaszcza gdy modyfikujesz profile walidacji TPM. Używaj wyłącznie zaleceń producenta – odstępstwa mogą prowadzić do nieprzewidzianego zachowania po aktualizacjach.
- Przed wdrożeniem większych aktualizacji zabezpieczeń (zwłaszcza Patch Tuesday) testuj je na maszynach w środowisku laboratoryjnym, szczególnie jeśli Twoja konfiguracja BitLockera odbiega od domyślnej.
- Monitoruj dziennik zdarzeń systemowych pod kątem identyfikatora 1032, który może sygnalizować ryzyko żądania klucza odzyskiwania.
- W przypadku braku możliwości szybkiej aktualizacji rozważ użycie mechanizmu KIR jako tymczasowego zabezpieczenia.
- Pamiętaj o bezpiecznym przechowywaniu kluczy odzyskiwania BitLockera – w przypadku awarii lub błędu to one są ostatnią deską ratunku.
nn
Microsoft w ostatnich latach kilkakrotnie mierzył się z podobnymi incydentami – w lipcu 2024 roku inna aktualizacja wywołała żądania klucza na wszystkich wspieranych wersjach Windows, a w maju 2025 roku wydano awaryjne łatki dla Windows 10. Każdy taki przypadek pokazuje, jak ważne jest zachowanie kopii zapasowych kluczy odzyskiwania oraz zdolność do szybkiego reagowania przez zespoły IT. Aktualna sytuacja na Windows Server 2025 jest już opanowana, ale warto wyciągnąć z niej lekcję na przyszłość.
