[English]Mit dem zum Juli 2024-Patchday ausgerollten Sicherheitsupdate (z.B. KB5040442 für Windows 11, aber auch beim Windows 10-Pendant) gibt es massiv Probleme auf Systemen, auf denen Bitlocker aktiviert ist. Zahlreiche Nutzer haben sich gemeldet, dass die Systeme plötzlich eine Bitlocker-Abfrage zeigen.
Anzeige
Update KB5040442 für Windows 11 23H2-22H2
Das kumulative Update KB5040442 steht seit dem 9. Juli 2024 für Windows 11 22H2 und 23H2 zur Verfügung und wird auf nicht verwalteten Systemen automatisch per Windows Update installiert. Das Update beinhaltet Qualitätsverbesserungen sowie Sicherheitspatches. Details zu den Verbesserungen finden sich im Supportbeitrag. Hinweise auf die Sicherheitsfixes gibt es im Blog-Beitrag Microsoft Security Update Summary (9. Juli 2024).
Update KB5040427 für Windows 10 Version 21H1 – 22H2
Das kumulative Update KB5040427 steht seit dem 9. Juli 2024 für Windows 10 21H2-22H2 bereit. Bei 21H2 bekommt nur noch die Enterprise LTSC- und IoT-Variante (letztmalig) das Update. Das Update enthält nur Sicherheitsfixes, aber keine neuen Betriebssystemfunktionen (siehe auch Patchday: Windows 10/Server-Updates (9. Juli 2024)).
Windows 10/11 zeigen plötzlich Bitlocker-Abfragen
Durch dieses Update muss in Windows 10 und Windows 11 etwas mit Bitlocker kaputt gegangen sein, denn zahlreiche Nutzer haben sich im Blog gemeldet und berichten davon, dass es plötzlich Bitlocker-Abfragen gibt.
Als erstes hat sich Blog-Leser Sven1403 mit diesem Kommentar gemeldet, und schrieb zum 11. Juli 2024, dass es in seinem Umfeld einige Fälle gab, wo der Bitlocker-Schlüssel nach dem Neustart nach der Update-Installation abgefragt wurde. Betroffen waren hauptsächlich Windows 11-Systeme. Es sei aber auch ein Windows 10-Rechner dabei gewesen. Der Nutzer fragte dann, ob noch jemand das festgestellt habe.
Anzeige
In diesem Kommentar schreibt Martin Brede ebenfalls, dass in seiner Umgebung auf mehreren Systemen nach dem Neustart, im Rahmen der Installation des Windows 11-Update KB5040442 die Abfrage des Bitlocker-Schlüssel erscheint. Bislang seien das alles HP Z2 Workstations gewesen, gibt er an. In einem Folgekommentar bestätigt Nutzer DERZEIT diese Bitlocker-Abfragen, schreibt aber, dass es sich um Lenovo-Geräte handele.
Meiner Ansicht nach spielt aber der Rechnerhersteller keine Rolle. Blog-Leser Sven1403 bestätigt in diesem Kommentar, dass die Bitlocker-Abfrage beim Neustart nach Deinstallation des Update KB5040442 nicht mehr erscheint.
Ergänzung: Auf Mastodon hat sich ein Leser auf Grund des Artikels gemeldet und schrieb, dass er gestern an einem System die Grafikkarte gewechselt habe. Danach sei die Frage nach dem Bitlocker-Recovery-Key gekommen.
Hängt es am WinRE-Update KB5034441?
Bei dieser gesamten Geschichte kommt mir ein Verdacht. Microsoft versucht seit Januar 2024 eine Bitlocker-Schwachstelle (CVE-2024-20666) mit dem Update KB5034441 zu patchen. Bei vielen Systemen scheitert die Update-Installation aber mit dem Installationsfehler 0x80070643. Ich hatte hier im Blog in mehreren Beiträgen berichtet (siehe Artikellinks am Beitragsende).
Zum 9. Juli 2024 hat Microsoft dann die Beschreibung zu Update KB5034441 angepasst und beschreibt, in welchen Szenarien das Update nicht (mehr) angeboten wird (z.B. wenn eine Recovery-Partition fehlt). neowin.net hat hier darüber berichtet. Gleichzeitig habe ich gesehen, dass im Blog-Beitrag Microsoft Security Update Summary (9. Juli 2024) auch Bitlocker in der Liste der korrigierten Funktionen erwähnt ist. Irgend etwas hat Microsoft in diesem Bereich von Bitlocker gepatcht, was das Verhalten hervorruft.
In diesem Kommentar weist Bolko darauf hin, wie man BitLocker auf Systemen per Registry-Eingriff deaktivieren kann. Ich hatte ja im Blog-Beitrag Windows 10/11 Home-Edition und die OEM Bitlocker-Falle darauf hingewiesen, dass BitLocker bei Windows-Systemen mit Home-Editionen automatisch aktiviert wird. Die meisten Nutzer kennen aber den Bitlocker-Wiederherstellungsschlüssel nicht.
Ergänzung: Microsoft hat den Bug zum 23. Juli 2024 bestätigt, siehe Microsoft bestätigt Bitlocker-Abfragen durch Windows Juli 2024-Updates.
Ergänzung 2: Das Problem wurde im August 2024 gefixt – siehe Windows-Bitlocker-Abfrage-Bug durch August 2024-Updates korrigiert.
Ähnliche Artikel:
Microsoft Security Update Summary (9. Juli 2024)
Patchday: Windows 10/Server-Updates (9. Juli 2024)
Patchday: Windows 11/Server 2022-Updates (9. Juli 2024)
Windows Server 2012 / R2 und Windows 7 (9. Juli 2024)
Microsoft Office Updates (9. Juli 2024)
Windows WinRE-Update gegen CVE-2024-20666 scheitert mit Installationsfehler 0x80070643 (Jan. 2024, KB5034441)
Microsoft PowerShell-Script gegen Installationsfehler 0x80070643 bei KB5034441 (Jan. 2024)
Microsoft arbeitet an einem Fix für den Installationsfehler 0x80070643 beim WinRE-Update KB5034441
Windows 10: "Schlagloch" Win RE-Patch zum Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099
Windows 10: Neues zum WinRE-Patch (Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099)
Windows 10/11: Microsoft veröffentlicht Script für den WinRE BitLocker Bypass-Fix
Windows 10: Update KB5034441 scheitert erneut mit Error 0x80070643 im Februar 2024
Anzeige
Verstehe ich den Artikel richtig und es wird der Bitlocker-Recovery Key abgefragt anstelle des normalen PIN ?
Das geht aus den im Artikel verlinkten Kommentaren nicht hervor (aber Bitlocker-Schlüssel ist für mich kein Pin, sondern der Recovery-Key). Vielleicht meldet sich einer der Betroffenen und ergänzt die Information.
Aber noch Mal: Wer betroffen ist, wird wissen, ob es die PIN oder der Recovery-Key ist. Wer nicht betroffen ist, für den ist das Thema imho nicht relevant.
Ja.
Passierte uns auch mal bei einigen Laptops. Sehr nervig, da der Enduser meist den Schlüssel entweder gar nicht hat, oder nicht dabei hat und ihm dann per Telefon die Kombination ansagen… suboptimal angenehm ;-) .
Danke für die schnelle Antwort.
Den Recovery hat bei uns natürlich ebenfalls kein User (auch wenn das MS Standard ist), aber ich empfinde das als Sicherheitsproblem. Mit dem Recovery Key könnte der User seine HDD ausbauen und so leicht Daten abziehen.
Das ist ja der Grund für Bitlocker. Wir haben damals sehr mit uns gerungen, aber auch im 1. Corona-Frühling ist kein Laptop oder NUC ins Homeoffice gegangen, der nicht vollverschlüsselt war. Ich ziehe heute noch meinen Hut vor den Kollegen, die das damals binnen einer Woche hingekriegt haben.
dann passt es ja hervorrangend in das "Securitykonzept" von M$ :-)
Aber der Aufwand ist am Ende, wiedereinmal, nicht unerheblich durch eine verkacktes Update seitens MS.
Mittlerweile ist M$ einfach in allen Punkten nur eine Enttäuschung, ich plädiere immer noch für eine Produkthaftung bei Software, die genauso greift wir im normalen Maschinenbau
Ja, es müsste wirklich eine Produkthaftung geben. Warum es sowas bei Software noch nicht gibt ist mir ein Rätsel.
Bei einem CRM-Programm welches ein Kunde einsetzt, steht "für die Richtigkeit der Berechnungen wird keine Haftung übernommen". Ich meine wtf? In welchem andern Sektor würde das geduldet werden?
Das sehe ich genau so. Obwohl ich zuhause super unterwegs bin mit Win 11 und alles reibungslos klappt, finde ich inzwischen, sie machen einfach irgendwas. "Es interessiert sowieso keiner." Es müssen( (oder "wollen") ja alle Windows nutzen, also können sie fast machen was sie wollen. Beeindruckend finde ich aber die Geschichte mit Recall welche zurückgezogen worden ist….. Wäre ich wegen des MS Flusi nicht auf ein Windows angewiesen, wäre ich vermutlich auf Linux umgestiegen. Auch in der Firma ist der Support aufwand inzwischen relativ hoch. Man weiss nicht was kommt….
Bitlocker soll bei uns nicht das Gerät vor dem User schützen, nur gegen Diebstahl. Wenn das System läuft, kann er ja ohnehin auf alle Daten zugreifen ;-) . Somit sehe ich da kein Problem wenn er den Recoverykey hat. Er sollte ihn halt nicht ausgedruckt in der Notebooktasche mittragen.
Im wesentlichen gebe ich dir recht. Allerdings könnte er auf Daten anderen Benutzer zugreifen oder das System auch modifizieren.
Bei uns hat jeder seinen eigenen Laptop und ja, wenn er ihn zerbröselt hat er aber ganz andere Probleme seitens der GF ;-) .
Hast aber natürlich recht, bei Multiusersystemen stimmt das schon aber dafür wurde Bitlocker eigentlich auch nicht entworfen, dafür wäre dann eher EFS das Richtige.
Bei uns wird nach dem Update der Recoverycode abgefragt
Der Artikel ist hier in der Tat ungenau, etwas was ich hier nicht so erwarten würde. Eine Bitlocker-Abfrage ist recht allgemein formuliert, es kann das Bitlockerpasswort oder der Recoverykey sein. Den Recoverykey einfach so mal anzufordern wäre allerdings in der Tat ungewöhnlich. Kommt auch darauf an, wie Bitlocker eingestellt ist. Ob das wirklich was mit KB5034441 zu tun hat, ist auch nur Spekulation, denn das Recoverysystem wird bei einem normalen Systemstart ja nicht gestartet.
Also in 3 Systemen, die ich mit BL testete, genügte es, dass die Bootreihenfolge geändert wurde (z.B. HDD an 2 statt 1) um statt PIN zwingend den recovery key zu verlangen.
BL scheint da schon recht sensibel zu sein.
Bei uns auch bei einem Fall mit Win10 22H2 passiert. Aber nach erneutem Restart erschien die Bitlocker-Meldung nicht mehr und das Update lief (DANN) fehlerfrei durch.
Nur als Info, vielleicht lässt sich dann der eine oder andere Fall vom Endnutzer schnell mit einem Neustart lösen.
——-
Meldung sah aus wie diese:
https://de.minitool.com/images/uploads/2022/06/bitlocker-wiederherstellungsschluessel-thumbnail.jpg
"MS-Sprech":
Geben Sie den "Wiederherstellungsschlüssel" (= je nach MS-Tool: RecoveryPassword / Wiederherstellungsschlüssel / Kennwort) an…
Wiederherstellungsschlüssel-ID (zur Identifizierung) (= je nach MS-Tool: KeyProtectorId / Bezeichner / ID ) ist: xxxxxx–xxxx-xxxx-xxxx-xxxxxxxxxxx
Könnte auch hiermit zusammenhängen?
https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
"July 9, 2024 or later – Deployment Phase
This phase is when we encourage customers to begin deploying the mitigations and managing any media updates. The updates includes the following change:
Added support for Secure Version Number (SVN) and setting the updated SVN in the firmware.
The following is an outline of the steps to deploy in an Enterprise.
Note Additional guidance to come with later updates to this article.
Deploy the first mitigation to all devices in the Enterprise or a managed group of devices in the Enterprise. This includes:
Opting in to the first mitigation that adds the "Windows UEFI CA 2023" signing certificate to the device firmware.
Monitoring that devices have successfully added the "Windows UEFI CA 2023" signing certificate.
Deploy the second mitigation that applies the updated boot manager to the device.
Update any recovery or external bootable media used with these devices.
Deploy the third mitigation that enables the revocation of the "Windows Production CA 2011" certificate by adding it to the DBX in the firmware.
Deploy the fourth mitigation that updates the Secure Version Number (SVN) to the firmware."
Unglaublich wie wenig Reaktion von MS in solchen Threads vorkommt:
https://answers.microsoft.com/en-us/windows/forum/all/bitlocker-enabled-itself-on-windows-10-home/9aea3b1b-72db-4b10-8214-8b8b94da7d41?page=1
unglaublich auch, dass MS scheinbar Bitlocker im Hintergrund einschaltet, obwohl früher behauptet worden ist, dass es auf der Home Edition nicht läuft. Wie kann man einfach so davon kommen? Wenn eine Gruppe eine Ransomeware schreibt und installiert, dann werden diese richtigerweise von Strafverfolgungsbehörden verfolgt und falls gefunden – auch bestraft. Finde den Unterschied wenn MS ungefragt Bitlocker aktiviert und der Schlüssel vom User nicht gefunden wird?
Die Home Edition wurde aufgewertet und beinhaltet mittlerweile die automatische Geräteverschlüsselung. Diese erschwert es massiv, von einem gestohlenen, verloren gegangenen oder unbeaufsichtigt zugänglichen Gerät Daten abzuziehen und ist daher sehr sinnvoll. Da sich die wenigsten Benutzer die Mühe machen würden, das manuell selbst einzurichten (oder eine entsprechende Frage verstehen würden), ist es ebenso sinnvoll, dass sie zur Standardkonfiguration gehört.
Die Geräteverschlüsselung wird nur scharf geschaltet, wenn das Gerät die Hardwareanforderungen erfüllt (TPM, Secure Boot, Modern Standby, keine externen DMA-fähigen Busse, …) und erst, nachdem ein Wiederherstellungsschlüssel im Microsoft Account gespeichert werden konnte (oder im Active Directory oder in Entra ID bei Firmengeräten).
"nur [… wenn] ein Wiederherstellungsschlüssel im Microsoft Account gespeichert werden konnte"
Einmal mehr schützt das begründete Misstrauen gegen MS und das Umgehen ihrer Gängelung und Spionage also vor übergriffigem Verhalten Microsofts. Also ein weiterer Grund, unbedingt den MS-Account zu umgehen.
Keine Ahnung, was du damit genau ausdrücken willst.
Dass eine Festplattenverschlüsselung sinnvoll ist, bezweifelt glaube ich niemand. Wenn du keinen MSA hast, musst du diese von Hand einschalten und den Wiederherstellungsschlüssel z. B. ausdrucken und sicher verwahren.
Für Otto Normaluser ist das zu kompliziert. Damit er nicht ungeschützt da steht, wird ihm beides abgenommen, d. H. sowohl das Backup des Schlüssels als auch das Aktivieren der Verschlüsselung.
Es ist nicht der Job der Anbieter, so etwas zu entscheiden – er kennt weder mein Einsatz- noch mein Bedrohungsszenario.
Noch frecher ist es, den User darüber nicht einmal zu informieren*.
Ausserdem ist es bestenfalls halbgare "Sicherheit" (nur 128bit etc), die Bitlockers Standardkonfig bietet.
Ich habe es nicht getestet, könnte mir aber zudem vorstellen, dass es (insb. bei der PBA) mit anderer FDE wie Veracrypt kollidiert und der (immer noch unwissende) User nun eine Konfiguration troubleshooten darf, die er ('Dank' MS) falsch/unvollständig wahrnimmt.
* Schadensbeispiel: Plattenproblem, User schickt Platte für viel Geld zu einer Datenrettungsfirma die natürlich nur Datenmüll retten kann
War auch davon betroffen heute Morgen. Bei mir war Bitlocker gar nicht aktiviert gewesen. Heute Morgen hatte ich den blauen Bitlocker Bildschirm mit der Abfrage des Recovery Keys. Nach etwas Suche habe ich den dann in meinem Microsoft Account gefunden. Nach Eingabe startete das Notebook normal. Ich konnte bei den Updates lediglich ein UEFI Firmware Update von Lenovo sehen. Windows Updates wurden schon einen Tag vorher installiert.
Wenn du nach einem Recovery Key gefragt wirst und du diesen im MSA gefunden hast, war Bitlocker eben doch aktiviert.
Und dass ein Firmware-Update die Abfrage triggert, soll vorkommen. Ist dann aber ein Problem von Lenovo. Es geht auch ohne.
UEFI Firmware Updates triggern öfters mal Bitlocker, das ist leider nicht ungewöhnlich.
Und Bitlocker wird mittlerweile von MS automatisch aktiviert.
daher sollte bei FirmwareUpdates auch meist lt. Installationsanweisung der Hersteller für die Installation der Bitlocker "angehalten werden, um diesen Fall zu vermeiden.
Bitlocker anhalten hält nur den Neustart durch und nach dem.nächsten Windows Start ist er wieder aktiv.
Kann es sein, dass es durch das Update von den secure boot Zertifikaten kommt?
Hallo zusammen,
Leider tritt dieses Problem auch in unserem Unternehmen auf; einzelne Notebooks (HP) sind betroffen. Bei diesen Notebooks wird täglich der Bitlocker-Schlüssel verlangt. Gibt es bereits eine Lösung dafür?
Danke
Beste Grüße
Bei uns könnte man das Problem umgehen, wenn man die Bootreihfolge anpasst. Booten von Festplatte an 1. Stelle (nicht Windows Boot Manager).
Hilft uns aber nicht wirklich weiter….
Sind mit HP ProBooks und Lenovo Notebooks auch betroffen. Tritt bei uns aber nicht grundsätzlich auf, sondern in Kombination mit USB-C Dockingstations und einem Wechsel der Nutzung (mit Dock / ohne Dock). Geräte haben zudem das Booten per Netzwerk laut Bootreihenfolge erster Stelle.
Bisherige (manuelle) Lösung -> Änderung der Bootreihenfolge, so dass WinBoot Manager / HDD an Pos. 1 ist. Info von MS gibt es noch keine zum Support-Case.
Danke Helmut, 1000 Dank
Falls es ein Rückmeldung vom Support-Case gibt dann gerne bescheid geben. Danke
Info ist den Patch nicht zu verteilen und bei Bedarf / Problemen den Patch zu deinstallieren. Und: Warten auf ein neueres Update / einen Fix.
Empfehlung ist auch, dass PXE / Booten von LAN nicht an erster Stelle sein sollte.
Ich schließe mich an. Wir haben das Thema mit unseren Lenovo Geräten (PCs wie Notebooks). Bei Netzwerkänderung des PCs (es reicht das Abziehen des Netzwerkkabels) oder nach dem Abstecken des Docks erscheint die Bitlocker Abfrage für den Wiederherstellungsschlüssel. Betroffen sind alle unsere Geräte.
Danke für den Hinweis mit dem Ändern der Bootreihenfolge. Ich werde das gleich mal testen.
LG, Sonja
Hab die Nacht die gleiche Rückmeldung auf Facebook erhalten.
Ich kann das nur bestätigen. Seit dem Update KB5040427 gibt es bei unseren Lenovo Notebooks Probleme im Zusammenhang mit den USB-C Docks. Hier tritt die Bitlockermeldung mal mit oder ohne Verbindung zur Usb-c Dockingstation auf. Es ist bei uns nach erster Einschätzung so, daß es darauf ankommt in welchem Zustand das Update abgeschlossen wird.(Verbindung zur Dock, keine Verbindung zur Dock).
Leute die bei uns nur mit Dockingstation im Homeoffice und im Büro arbeiten würden den Fehler nie bemerken.
Kann ich bestätigen. Das Problem tritt bei uns nur unter Windows 10 mit Fujitsu-Notebooks und USB-C Dock auf. Windows 11 ist nicht betroffen.
Je nachdem, wie das Update eingespielt wurde (am Dock oder nicht am Dock), tritt die Bit-Locker Meldung im anderen Zustand dann auf. Wenn der Zustand zum einspielen des Updates hergestellt ist, fährt er ohne Meldung hoch.
Eine Änderung der Boot-Reihenfolge bewirkt nichts. Leider habe ich noch keinen richtigen Lösungsansatz.
Trifft heute die Leute, die das Update am Freitag im Homeoffice bekommen habe und heute im Büro am USB-C Dock sind. Insgesamt haben wir knapp 800 Geräte in dieser Konstellation. Habe noch keinen richtigen Lösungsansatz.
Bei uns sind Win10 (22H2) und Win11 (23H2) gleichermaßen betroffen, in Kombination mit USB-C Dock.
Wie ich oben schon schrieb, genügt manchmal nach solch einem "Bitlocker nach Update" auch ein einfacher Neustart um Windows wieder ohne Bitlockermeldung zu starten.
Hallo, bei uns tritt das Problem auch auf. Wir nutzen komplett Lenovo mit PXE Boot.
Wenn das Update im HO installiert wurde (ohne Dock) funktioniert alles super im HO. Wurde das Update im Büro (mit Dock) installiert, funktioniert alles super im Büro. Fahren die User nun an den jeweiligen anderen Arbeitsplatz, dann wird der BitLocker Recovery Key verlangt. Glücklicherweise stelle ich zeitlich in Stufen bereit. So hat es nur die 40 "weißen Mäuse" betroffen und nicht alle 1200 Notebooks. Das war Glück im Unglück!!! Ich habe das Update bei den betroffenen Kollegen rückgängig gemacht bzw. deinstalliert und aus dem SCCM Rollout ausgesperrt.
Leider habe ich bisher keine Möglichkeit gefunden, das Update automatisiert via SCCM zu deinstallieren. DISM /online bricht mit Errorcode weg.
Mir ist folgendes aufgefallen: nach dem Juli-CU Update wird sowohl bei Windows 10 als auch bei Windows 11 zusätzlich ein Bitlocker PCR-Validierungsprofil (PCR 4) abgefragt. Zu sehen ist dies per "manage-bde -protectors -get c:". Ohne das Juli-Update werden nur die PCR-Validierungsprofile 7 und 11 gelistet.
Laut Gruppenrichtline "TPM-Plattformvalidierungsprofil für systemeigene UEFI-Firmwarekonfigurationen konfigurieren" nennt sich der PCR-4 Eintrag "Start-Manager". Das würde vielleicht auch die Thematik mit der Bootreihenfolge bzw. mit den Docks erklären.
Die nachträgliche Änderung der Bootreihenfolge hat bei uns nicht dauerhaft funktioniert.
Unsere mögliche aber ungetestete Lösung:
Wir versuchen nun testweise die o.g. Gruppenrichtlinie an ein paar betroffenen Geräten auf die PCR-Profile 7 und 11 festzunageln. Danach ist vermutlich ein Bitlocker-Suspend & Bitlocker-Resume oder gar eine Enschlüsselung/Verschlüsselung mit Neustart notwendig, damit die Einstellung greift.
Wir konnten bisher noch keine Tests durchführen, aber vielleicht hilft es jemanden oder bringt ihn auf die richtige Lösung :-)
Wir konnten nun das Problem erstmal wie folgt lösen:
Gruppenrichtline "TPM-Plattformvalidierungsprofil für systemeigene UEFI-Firmwarekonfigurationen konfigurieren" setzen: PCR 7 und 11
Damit die Änderung wirksam wird ist ein bitlocker-suspend und bitlocker-resume notwendig. Ein Neustart des Geräts ist nicht notwendig.
Dieser Artikel verschafft vielleicht noch etwas mehr Klarheit:
https://www.windowspro.de/wolfgang-sommergut/bitlocker-recovery-mode-anpassen-platform-configuration-register-pcr-vermeiden
Könntest Du das bitte noch etwas näher ausführen, wie ihr das löst bzw. in die breite Masse verteilt?
Per (SCCM-)Tasksequenz (Bitlocker anhalten, Gpupdate erzwingen, Bitlocker wieder starten) oder per Script bzw. auf welchem Wege bringt ihr das in die Fläche heraus?
Wir haben kein SCCM, rollen die Änderung aber auch über unsere Softwareverteilung aus:
gpupdate, dann wird geprüft ob die GPO-Einstellung wirklich übernommen wurde (HKLM\SOFTWARE\Policies\Microsoft\FVE\OSPlatformValidation_UEFI "4" = 0) anschließend suspend-bitlocker und resume-bitlocker.
Vielen Dank Bernd für die Erklärung. Es hat mich auf die richtige Lösung gebracht. Das geschilderte ergibt Sinn, warum es mit dem USB-C Dock auftritt. Ein angestecktes Dock bietet zusätzliche Boot Optionen wie PXE, bzw. diese Fehlen wenn es abgesteckt ist. Dann ist klar, dass bei aktiven PCR4 der BitLocker eine Veränderung an der Boot Reihenfolge feststellt und es nur geht, wie zum Zustand als das Update eingespielt wurde. Ich konnte durch ent- und neu verschlüsseln das Verhalten sogar drehen.
Wir haben die GPO jetzt ausgerollt und das bitlocker-suspend über ein PS-Script (Bitlocker anhalten, Gpupdate erzwingen, Bitlocker wieder starten) in die Softwareverteilung (Ivanti) raus gebrügelt. Das hat geholfen.
"Ich konnte durch ent- und neu verschlüsseln das Verhalten sogar drehen."
bitlocker anhalten und neu starten reicht schon um das Verhalten zu drehen.
Weiss jemand ob das Problem noch besteht?
Das Ganze steht zumindest auch im KB5040437 Update ReadMe mit drin:
Improvements:
[BitLocker] This update adds PCR 4 to PCR 7 and 11 for the default Secure Boot validation profile. See CVE-2024-38058 for more information.
Warum das Problem z.B. mit dem Docking-Station Verhalten da von MS komplett missachtet wurde/wird , k.A. ?
Es gibt jetzt ein aus meiner Sicht wenig hilfreiches offizielles Statement von Microsoft.
Devices might boot into BitLocker recovery with the July 2024 security update
Aber zumindest arbeiten sie daran
—
GB: War im Nachtrag am Artikelende mit Verweis auf den Folgepost thematisiert.
Problem wurde gemäss MS mit dem August update vom 13.8.2024 behoben.
If you install an update released August 13, 2024 (KB5041585) or later, you do not need to use a workaround for this issue. If you are using an update released before August 13, 2024, and have this issue, your device should proceed to start up normally from the BitLocker recovery screen once the recovery key has been entered.
Source:
https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-23H2#devices-might-boot-into-bitlocker-recovery-with-the-july-2024-security-update