[English]Ich ziehe mal einen Sachverhalt separat heraus, den ich bereits im Blog mit einem Hinweis bedacht hatte. Das zum 9. August 2022 von Microsoft freigegebene Update KB5012170 verursacht bei einigen Systemen Probleme. Das Sicherheitsupdate für das Secure Boot Modul, welches eine Ausnutzung von Schwachstellen verhindern soll, bewirkt bei einigen Nutzern, dass dort der Bitlocker-Schlüssel beim Booten angefordert wird. Andere haben Installationsfehler, und bei manchen Nutzern bleibt der Bildschirm dunkel.
Anzeige
Sicherheitsupdate KB5012170
Das Sicherheitsupdate KB5012170 (Security update for Secure Boot DBX: August 9, 2022) bringt Verbesserungen am Secure Boot DBX für die unterstützten Windows-Versionen, indem es neue Module zur DBX hinzufügt. Hintergrund waren Schwachstellen in dieser Umgebung. Ich hatte auf das betreffende Update im Blog-Beitrag Windows Sicherheitsupdate KB5012170 für Secure Boot DBX (9. August 2022) hingewiesen.
Update verursacht Bitlocker-Probleme
Ich war bereits frühzeitig auf diesen Nutzerpost im heise-Forum gestoßen, wo jemand beklagte, dass das System unter Windows 11 nach Installation des Updates den Bitlockerschlüssel abgefragt.
Bitlocker benötigt den Schlüssel nach dem das Update Fix KB5012170 fehlschlägt
Hallo Zusammen,
nach dem ich ein paar Rechner von Usern mit Windows 11 upgedatet habe, wird nach dem Neustart des Rechners der Bitlockerschlüssel abgefragt.
Das scheint mit dem FIX KB5012170 zusammen zu hängen, welches beim Installieren bei den betroffenen Rechnern fehlgeschlagen ist, und ein Rollback macht.
In meinem oben verlinkten Blog-Beitrag gab es von mir folgenden Hinweis:
Aufpassen sollte man auch, wenn die BitLocker-Gruppenrichtlinie "TPM-Plattformvalidierungsprofil für native UEFI-Firmwarekonfigurationen konfigurieren" aktiviert und PCR7 per Richtlinie ausgewählt ist. Dies kann dies dazu führen, dass der BitLocker-Wiederherstellungsschlüssel auf einigen Geräten erforderlich ist, auf denen eine PCR7-Bindung nicht möglich ist.
und in obigem Forenpost kam später der Nachtrag: "Schaut euch mal die "Known Issues" dazu an. Es muss wohl erst eine "aktuelle BIOS Firmware" installiert sein, bevor das Fix installiert werden kann."
Anzeige
Eine weitere Meldung
Cornelia hat mich heute früh per E-Mail kontaktiert (danke dafür), weil sie durch Kunden auf diesen Sachverhalt aufmerksam wurde und schrieb:
Guten Morgen
Das könnte was für den Blog sein.
Die Installation eines Windows 11 Updates kann dazu führen, dass beim Neustart der Bitlocker Recovery Key eingegeben werden muss.
Bei uns hatte sich gestern verzweifelt eine Kundin gemeldet, weil sie nur noch einen blauen Bildschirm – ohne Text – sah, nachdem sie wohl auf Esc gedrückt hatte. Im Laufe der späteren Analyse in unserem Büro kam irgendwann die bekannte Bitlocker Ansicht. Glücklicherweise konnten wir den Key dank ihrem Microsoft Konto finden.
Heute hatten wir bereits einen weiteren Laptop, bei dem der Key verlangt wurde.
Meine Anmerkung im Blog-Beitrag Windows Sicherheitsupdate KB5012170 für Secure Boot DBX (9. August 2022) hatte sie sogar gelesen, aber nicht gleich verortet. Sie schrieb mir, "Ja, ich hatte den Hinweis wegen TPM und PCR7 im Beitrag gelesen, ging aber davon aus, dass das nur bei Domänencomputer relevant ist, bei welchen eine serverseitige Gruppenrichtlinien angewendet wird. Darum hatte ich das mehr oder weniger ignoriert."
Ein Problem-Update
Die Kollegen von Bleeping Computer haben es heute (nach einem Bericht von TheRegister) in diesem Beitrag nochmals explizit aufgegriffen. Auch bei Microsoft Answers gibt es diesen Forenbeitrag und auf reddit.com wird das Ganze hier diskutiert. Doof sind die Fälle, wo die Maschine nur noch mit einem schwarzen Bildschirm startet. Zudem gibt es eine Reihe Leute, wo die Update-Installation mit einem Fehler abbricht. Hier hilft nur, die OEMs für das BIOS/UEFI zu kontaktieren, um zu klären, ob es ein Update für diese Komponente gibt.
Ähnliche Artikel:
Windows Sicherheitsupdate KB5012170 für Secure Boot DBX (9. August 2022)
Update KB5012170 für Secure Boot DBX verursacht Bitlocker-Probleme
Windows Update KB5012170 (Secure Boot DBX) mit neuer Revision im WSUS (Okt. 2022)
Windows 11 22H2: Secure Boot DBX Update KB5012170 (Dez. 2022)
Bestätigt: Secure Boot DBX Update KB5012170 sorgt für Installationsärger (Error 0x800F0922)
Anzeige
Ich finde es prinzipiell sehr problematisch, dass Microsoft über ein UEFI-Update Bootloader von anderen Herstellern einfach so sperren kann.
Potentielle oder angebliche Sicherheitslücken hin oder her.
Wenn Microsoft es will, dann kann es dadurch einfach so andere Betriebssysteme oder sonstige Konkurrenzprodukte wie Bitlocker-Alternativen ausknipsen (was ja der von Microsoft gesperrte Bootloader von"CryptoPro Secure Disk" ist).
So eine Macht geht mir zu weit.
Wer auf meiner Hardware bootet, sollte nur ich selber bestimmen können und nicht ein Konzern wie Microsoft.
Das wäre vergleichbar mit der Situation, wo Microsoft bestimmen wollte, wer ein Auto fahren darf und wer nicht. Sitzt die falsche Person im Auto, etwa ein Mitarbeiter von Apple oder Google, dann springt es nicht an?
www[.]heise[.]de/news/UEFI-Secure-Boot-Microsoft-sperrt-unsichere-Bootloader-per-Windows-Update-7220634.html
2.
Welchen Sinn macht Bitlocker überhaupt, wenn der Schlüssel im Microsoft-Konto hinterlegt ist, also Microsoft oder eine staatliche Behörde, die an Microsoft eine Anfrage stellt, die Verschlüsselung locker knacken kann, weil die Schlüssel ja auf Microsoft-Servern herumliegen?
Verschlüsselung macht nur dann Sinn, wenn sie auch gegenüber einem Konzern oder einem Staat sicher ist.
Daher VeraCrypt statt Bitlocker.
Der Schlüssel ist mit deinem Passwort verschlüsselt und nicht "im Klartext".
Davon abgesehen betrifft das hinterlegen der Bitlocker-Keys im MS-Account (zu meist unbedarfte) Privatanwender die Windows über "weiter, weiter fertig" mit einem MS-Konto verwenden.
Sollte hier einmal etwas mit den Daten sein (wie hier) ist das schon gut und Sinnvoll einen Fallback zu haben.
Alle anderen Bitlocker-User müssen den Key dort nicht hinterlegen.
Zitat:
"Der Schlüssel ist mit deinem Passwort verschlüsselt und nicht "im Klartext"."
—
Woher weißt du das denn so genau mit Sicherheit?
Theoretisches Soll-Optimum aus dem Informatik-Studium muss nicht dem praktischen IST-Zustand im Microsoft-Konzern entsprechen.
Woher weißt du, dass Microsoft das Passwort nicht auch über andere Wege kennt, zum Beispiel über den "Windows 10 Keylogger", der seine Erkenntnisse in den Dateien TextHarvester.dat und WaitList.dat speichert und eventuell per Telemetrie verschickt?
Fallbacks sind durchaus keine schlechte Sache, aber der Benutzer sollte doch auch ein Mitspracherecht haben und darüber informiert werden (nicht nur ggf. irgendwo auf Seite 134 von 350 der Nutzungsbedingungen / Datenschutzerklärung / etc.).
Im Falle von Passwörtern sicherlich auch eine Vertrauensfrage bei welchem Dienst man online (oder eben auch nicht) so etwas speichern möchte. Neben Misstrauen gegenüber Anbieter und staatlichen Stellen sind Passwörter und CO online (und für alle mit Fremdzugriff) auch nicht für alle so eine tolle Sache.
So, wie es hilfreich sein kann, wenn man ein Backup des BL-Keys in der Cloud hat, so kann es genauso auch anders herum sehr ärgerlich sein, wenn man das System nicht mehr startet / die Hardware ausfällt und der Zugriff auf die Daten plötzlich nicht mehr möglich ist (etwa weil das MS Konto eine einmalige (Zwangs)Sache bei der Einrichtung war und danach nie groß verwendet wurde. Aber auch mit Kontensperrungen hält sich MS nicht gerade zurück, wie man an diversen Stellen immer wieder lesen kann.
Hast du dich mal mit PGP-Verschlüsselung beschäftigt?
Da kann man auch mit mehr als nur einem Schlüssel verschlüsseln.
Wenn also irgend ein jemand eine Verschlüsselung zusätzlich mit einem weiteren Schlüssel codiert, dann kann derjenige auch jede Ende-zu-Ende-Verschlüsselung zwischen zwei anderen mitlesen.
Das gilt auch für WhatsApp mit seiner "sicheren" End-to-End-Verschlüsselung". Zwischendrin sitzt aber noch jemand mit einem zusätzlichen und eigentlichen überflüssigem Schlüssel, der alles sehen kann.
Es gibt eben nicht nur einen einzigen privaten Key, sondern mehrere sind möglich und wenn ein Konzern oder ein Staat alles zusätzlich mit seinem eigenen Key verschlüsselt, dann kann er alles mitlesen, auch wenn andere Personen das ihrerseits mit ihrem eigenen Key verschlüsselt haben.
Ende-zu-Ende-Verschlüsselung?
Ja schon, aber das bedeutet eben nicht, das es nicht trotzdem problemlos im Klartext lesbar wäre, wenn das dritte Auge alles mit dem third-Eye-Key-zusätzlich verschlüsselt.
Vor ca 20 Jahren hatte ein PGP-Entwickler (v6.58 ckt "Cyber Knight Templar Edition") mal behauptet, seine Sourcen für seine angepassten PGP-Varianten seien zerstört worden.
War damals vermutlich gelogen, um die Hintertüren verschleiern zu können, aber obendrein sind solche versteckten Hintertüren unnötig, da multiple Verschlüsselungen ja systemimmanent sind, also gewollt.
Die CIA-Hintertüren muss man nicht verstecken, indem man den Sourcecode als verschollen deklariert
Sondern man sollte das Verschlüsselungskonzept als solches kapieren, dass also multiple Schlüssel auch zwischen nur zwei Usern möglich sind, also mehr Schlüssel als User, also immer mindestens einer zu viel als nötig, also gerade hinreichend zum mitlesen einer dritten Person.
Die Diskussion über die Macht die sich MS über UEFI ergattert hat, war von Anfang an ein Problem.( So vor 15 Jahren)
MS hätte leicht verhindern können, dass ein Rechner jemals wieder ein nicht-kommerzielles Linux hätte booten können.
Das Problem hat MS umgehen können.
Dennoch sind viele Menschen bei MS geblieben.
Verständlich: Wenn ich zig tausende Euro in Kurse für meine Admins investiert habe, oder noch schlimmer, der Anbieter andeutet, das Kenntnis im Maus schubsen ausreichend sind, eine Windows Landschaft zu administrieren … Dann gehe ich doch nicht auf etwas, wo man in ein schwarzes Fenster etwas tippen und schlimmer, wissen muss was, was man da zu muß…
Es ist doch wohl den meisten klar, was MS will.
Absolute Herrschaft, Root auf allen Servern, ein Microsoft-Steuer, also was Google bei Android ja fast geschaft hat(Sie haben root Rechte? Tut uns Leid, aber die Bankingapp können Sie nicht installieren, weil wir ja auf einem Gerät zu Ihrer Bequemlichkeit 2 Faktoren-Autorisierung implementiert haben…)…
Ubd alle machen mit.
Und wenn MS die Preise in de lr Cloud verdoppelt, dann zahlt man man das halt. Was soll man denn machen?
Man ist abhängig, hat sich selbst aus Bequemlichkeit abhängig gemacht…
Nur stelle man sich mal vor, das Microsoft das schonmal gehabt hätte, und Updates daraufhin schonmal testen würde.
Upps. Februar 2021 (genau! das selbe)
https://www.makeuseof.com/windows-10-secure-boot-bug-triggers-bitlocker-key-recovery-issue/
Betrifft dieses Fehlverhalten ausschließlich Windows 11-Systeme?
Bisher habe ich nur Win11 Systeme in Meldungen gesehen.
Win10 ist auch betroffen, da Win11 und Win10-21H2 die selbe Basis haben und man das Update auch auf Win10 installieren kann.
Aus welchem Grund sollte Win10 denn nicht betroffen sein, trotz selber Basis und selbem Patch?
Zitat:
August 2022 patch KB5012170 is causing Bitlocker recovery key screen prompt issues Error 0x800f0922. Many admins reported this issue after installing security update KB5012170. This is impacting all Windows 10, 11, and Server Operating Systems.
www[.]anoopcnair[.]com/bitlocker-recovery-key-screen-prompt-issues/
Ich habe hier auch einen Server 2019 mit diesem Problem.
Es handelt sich einen Domaincontroller, der ursprünglich unter HyperV virtualisiert wurde.
Im Zuge der Diversifizierung der Serverlandschaft ist er jetzt auf KVM unter Linux gewandert, wo es keine UEFI-Partition mehr gibt.
Leider scheint der Installer das nicht zu begreifen und versucht beharrlich dieses Update KB5012170 zu installieren.Der Versuch scheitert – wie in der KB unter "known issues" angegeben mit Error 0x800f0922. Nur kann ich halt unter KVM kein UEFI-Bios updaten – zumal dieser resolution auch mehr als schwammig formuliert ist ("Ein BIOS-update könnte helfen").
Ich mußte dieses Update ausblenden.
Es gibt noch ein Problem mit diesem Update:
Im UEFI wird RAID auf AHCI umgestellt:
"Another annoying bug users report after installing KB5012170 is disk configurations changing from RAID to AHCI."
www[.]neowin[.]net/news/users-report-kb5012170-is-causing-their-pcs-to-boot-into-bitlocker-recovery/
Falls man also vorher ein RAID hatte, dann kann man nach dem Update nicht mehr auf die Daten der Festplatten zugreifen, ohne manuell im UEFI wieder auf RAID umzustellen.
Wer zwickt mich mal?
Ich muß in einem Alptraum sein.
Ein Update dreht im BIOS herum, ohne das es die Treibersuche reaktiviert und der User erstmal vor einem BSOD steht, weil Windows nicht mehr auf die Boot Platte zugreifen kann?
Testen die wirklich gar nicht mehr?
Windows as a Service? P
Bro, wenn im Bios RAID steht, lädt Windows andere Treiber, aber es heißt nicht, das die Platten als RAID konfiguriert wären/sein müssten. Diese anderen Treiber sollen effizienter sein, sagt.. Intel, die diese Treiber gebaut haben.
Man kann von RAID auf AHCI und umgekehrt stellen.
Leider hat MS entschieden, die 0,25 sekunden zu sparen, den richtigen Treiber zusuchen, sobald das booten einmal geklappt hat. Dirse Suche kann man aber reaktivieren…
Das hat nichts damit zu tun ob man unter Windows RAID eingerichtet hat. Das geht auch mit AHCI..
Aber natürlich ist es ein absoluter Unsinn, das Windows an diesem Parameter dreht.
Es gibt eine Theorie, das Unternehmen nur bis zu einer gewissen Größe wachsen können. Die Verwaltung übernimmt dann das Regiment…
Ja, vor vielen Jahren musste man im BIOS noch auf RAID umschalten, wenn man AHCI (ohne RAID) wollte.
"RAID" im BIOS bzw UEFI bedeutet nicht unbedingt auch eine RAID-Funktion, sondern kann auch nur "AHCI" Treiber bedeuten.
Der PC wird wahrscheinlich vorher ein UEFI Update (Firmwareupdate) Installiert haben. Nach dem Neustart lädt das System dann die Optimal default Einstellungen. Die Standardeinstellung ist meistens AHCI.
Bei uns tritt der Fehler bislang ausschließlich bei Lenovo Notebooks auf, die nicht über ein aktuelles UEFI verfügen. Heißt: zuerst UEFI aktualisieren und dann Patch installieren, sonst kommt der Bitlocker Wiederherstellungsbildschirm
Für mich ist das "Problem" mit Bicklocker in diesem Zusammenhang ganz selbstverständlich. Wenn der Schlüssel für die Systempartition im TPM gespeichert ist, gibt das TPM (auch Software TPM im Prozessor) den Schlüssel nicht frei, wenn bestimmte Systemeigenschaften verändert wurden. Dazu zählen (meist ?!) auch BIOS-Updates, und was Microsoft hier gemacht hat, ist so etwas wie ein BIOS-Update.
Deshalb würde man vor einem geplanten BIOS-Update normalerweise Bitlocker pausieren, Windows nach dem Update neu starten und Bitlocker fortsetzen. Das sollte dann normalerweise keine Probleme geben.
Natürlich sind das Zusammenhänge, die Microsoft völlig unbekannt sind.
Aber mal grundsätzlich: Ich finde es nicht nur bedenklich, daß Microsoft hier so einfach Änderungen am BIOS vornimmt. Ich habe absolut kein Verständnis dafür, daß ein Betriebssystem das überhaupt so einfach kann!
Zitat:
"Windows nach dem Update neu starten"
—
Wer nach so einer Microsoft-Aktion nochmals Windows 10 oder 11 außerhalb einer VM (bevorzugt "proxmox" KVM) neu startet, hat den Schuss immer noch nicht gehört.
Wieso soll denn gerade Microsoft den Vollzugriff auf die Hardware haben?
Besser ein freies stabiles Debian (oder sonstiges Linux) als VM-Host (KVM, Kernel-Virtual-Machine) laufen lassen und Windows und Co nur noch in einer Linux-Kernel gesteuerten VM abstrahiert und sicherer (und schnell noch dazu) laufen lassen (eben "proxmox").
Mit den Treibern "VirtIO" (siehe fedora, max 0.1.173-4,) funktioniert auch Windows (7) wie auf echter Hardware, mit Netzwerk, PCI, Grafik nahezu verzögerungsfrei und besser als in einer VirtualBox oder einer VmWare oder einer Hyper-V, proxmoxVM is the Best).
Wenn Windows ab inklusive Version 10 nur noch innerhalb von VMs laufen gelassen wird, dann hat man diese UEFI- und Bitlocker-Probleme gar nicht mehr.
Drucker-Probleme hat man auch nicht mehr, denn das macht man dann treiberlos mit CUPS unter Linux.
Das funktioniert mit fast jeder Hardware, fast jeder Software, auch über Netzwerk, denn "driverless printing" ist seit vielen Jahren ein Standard (auch auf Apple-Hardware), auf den Microsoft nur mal wieder einen dicken Haufen scheißen möchte und so tut, als ob es sowas gar nicht gäbe, weil das nicht in deren Kundenbindungskonzept rein passt.
Was ist wohl besser?
Drucken nur mit Treibern, über die Microsoft die Kontrolle hat
ODER
Drucken einfach so ganz ohne Treiber?
Treiber zum drucken? Wozu denn? Die Drucker haben doch einen eigenen Prozessor, der bezüglich "Drucken" voll oberfit ist.
Windows auf echtem Blech? Damit es die anderen Bootloader zerschießt, Partitionen anderer Betriebssysteme löscht und Verschlüsselungen korrumpiert und simuliert, es könne sowas wie Drucken überhaupt gar nicht?
KVM Virtual Machine ist besser und schneller als jede andere VM, inklusive vmWare, VirtualBox, Hyper-V.
Obendrein kostenlos, frei, open-source, was will man denn noch mehr?
Warum also diese beste Variante nicht nutzen und dadurch sehr viele Probleme umgehen?
1. ProxMox als KVM-Host-Betriebssystem installieren
2. Innerhalb von ProxMox dann die anderen Betriebssysteme in den KVMs installieren.
ProxMox also als zusätzliches ZwischenLayer zwischen Hardware und den eigentlich genutzten Betriebsystemen ansehen.
So kann Windows nichts mehr kaputt machen im UEFI, im Bitlocker, bei den Druckern etc, und es ist trotzdem schnell und kompatibel, da Kernel-VMs (KVM) schnellstmöglichst und ziemlich transparent arbeiten.
Statt dem einfacheren und kompatibleren ProxMox könnte man auch Qubes OS (XEN statt KVM) als VM-Host benutzen, das hat aber mehr den Charakter einer unflexiblen ignoranten Festung (Fort Knox), während ProxMox ein erweiterbares flexibles Debian als Host ist.
Hauptsache das wild um sich schießende Windoof ist mal eingehegt in einer VM und der User lernt mal, wie mächtig und toll Linux inzwischen geworden ist.
Die Spiele laufen dann im Bestfall auch nicht mehr unter Windows nativ, nichtmal unter Windows innerhalb einer der KVMs, sondern in einem Linux innerhalb einer der KVMs auf dem Proxmox-Host und es funzt trotzdem und sogar flott.
###
Zitat:
"und Bitlocker fortsetzen"
—
Daten aus Bitlocker in einen VeraCrypt-Container kopieren, Bitlocker löschen und mit VeraCrypt weiter machen.
Bro, man verschlüsselt den symmetrischen Schlüssel mit mehreren Schlüsseln. Das eigentliche Material wird nur einmal für alle verschlüsselt. Es wäre ansonsten nötig mehrere Kopien des Materials zu halten.
Was wenn einer ändert, wie kommen seine Anforderungen in die verschlüsselten Versionen der anderen?
Zitat:
"Das eigentliche Material wird nur einmal für alle verschlüsselt."
Ja, aber mit wie vielen Schlüsseln?
Wie viele sind denn diese "alle"?
Mit dem öffentlichen Schlüssel des gewünschten Empfängers ist soweit klar.
Zusätzlich aber auch noch heimlich mit dem Schlüssel des nicht bekannten Mitlesers.
Wie soll man das ausschließen können ohne Zugriff auf den Sourcecode?
Bei uns tritt nach Installation des Security-Updates vermehrt die Boot-Meldung "Secure Boot Violation" (roter Dialog – beobachtet auf Fujitsu Esprimo P757 und P758 mit 21H2) auf. Nach bestätigen der Meldung mit OK bootet der Rechner normal.
Derzeit besteht die Vermutung, das dies im Zusammenhang mit der (gleichzeitigen ?) Installation des kumulativen Windows-Updates 2022-08 steht.
Die Meldung kann beseitigt werden, indem im BIOS-Setup Secure Boot von "Standard" auf "Custom" und beim Zurückschalten die Signaturen auf "Default" zurückgesetzt werden.
Ich habe das Problem bisher nur auf einem Thinkpad T460s beobachten können.
Hallo,
ich habe einen Kunden bei dem das Fujitsu Notebook nun auch nach dem Bitlocker Recovery Key fragt. (Bios von 2018)
Laut Kunde wurde Bitlocker nicht von ihm aktiviert und im MS Konto ist entsprechend auch nichts hinterlegt.
Gibt es die Konstellation, dass die komplett per TPM abläuft?
Wenn ich nun ein BIOS Update mache, wird der TPM Cache dann geleert und ich komme ganz sicher gar nicht mehr ran?
Der Hersteller empfiehlt auf jeden Fall bitlocker beim biosupdate zu pausieren, was in diesem Fall ja nun nicht geht.
Danke für jeden Tipp
es gibt aktuell bei Lenovo Geräten noch ein weiteres Problem mit dem Lenovo System Update Tool, über das UEFI / BIOS aktualisiert werden kann. Ein Update fürs Batterie Management macht dort Probleme, wenn dieses eingespielt wird und im UEFI unter Security -> Password -> Passwort @ Unattended Boot gesetzt ist. Die Option ist im Standard immer aktiv.
Wenn man nun das Batterie-Firmwareupdate durchführt, bleibt das jeweilige Notebook im Bootbildschirm hängen. Problematisch kann es nun für Firmen werden, so das System Update Tool automatisch die Endgeräte patcht und die o.g. Funktion aktiviert ist.
Habe den Fehler auf einem Fujitsu-PC, der so alt ist, das er gar kein UEFI -BIOS hat. Das Problem ist, das der Installationsfehler nachfolgende Updates blockiert. Es geht also gar nix mehr, bis MS den Kram zurück zieht. (Win 10/22H1).
Freundliche Grüße
doch
https://www.tenforums.com/tutorials/8280-hide-show-windows-updates-windows-10-a.html
Hat funktioniert. DANKE!
wss soll den "(Win 10/22H1)" sein? 21H1? 21H2? 22H2?
> was soll denn "(Win 10/22H1)" sein? 21H1? 21H2? 22H2?
21H2 – mein Fehler
Wir haben seit dieser Woche bei unseren Lenovo Notebooks X13 Yoga Gen1 auch ein Problem, ob dies allerdings mit dem Bitlocker zusammenhängt ist noch fraglich, zumindestens sind die betroffenen Geräte Bitlocker verschlüsselt, seit Montag haben wir jetzt 9 Geräte welch beim Start das Supervisor Passwort zum Starten verlangen, obwohl dieses nur für den UEFI/Bios Zugriff gesetzt ist. Nach der Eingabe des PW erscheint in weißer Schrift die Meldung "Boot Configuration has been recovered by restoring backup. Please confirm BIOS setup, and change setting if necessary. Press Esc key to hide this massage." Das laden der Default Einstellungen bringt nichts. Bei einem System war nach dem laden aller Windowsupdates die Abfrage weg, bei einem anderen durch das entfernen des Bitlocker Keys aus dem TPM und dann wieder hinzufügen. Hat jemand dieses Verhalten beobachtet, dazu finde ich nämlich noch nichts im Netz? Gruß Kay
Siehe Kommentar:
Anonymous sagt:
18. August 2022 um 12:42
Wenn das Batterie FW Update gemacht wird, und im BIOS die Einstellung Passwort @ Unattended Boot gesetzt ist, kommt die Passwortabfrage.
Das FW Update wird wohl nicht für jedes Yoga benötigt.
Über Windows Update kommt es als Lenovo Ltd. – Firmware – 257.0.0.37571
https://www.deskmodder.de/blog/2022/08/20/nach-der-installation-der-kb5012170-kann-die-bitlocker-wiederherstellung-gestartet-werden-loesungen-von-microsoft/
Hallo zusammen,
ich habe ein Asus Expertbook Notebook (Mitte 2020 gekauft) auf dem ich nie Bitlocker aktiviert hatte und auch nie ein Bitlocker-Kennwort eingeben musste.
Nach dem Update wird plötzlich auch nach dem Widerherstellungsschlüssel gefragt.
Im verwendeten Microsoft Konto eingeloggt, dort wird mir unter account.microsft.com/devices nur angezeigt:
Unter diesem Link haben wir keine Inhalte für Sie.
Mir wird also kein Bitlocker-Key angezeigt.
Hat noch jemand eine Idee, wie ich wieder in mein System komme?
Vielen Dank!
Grüße,
Alex
Hallo Alex,
gleiches Problem bei mir. Nach dem Windows-Update ist BitLocker aktiv, ohne das ich jemals selber aktiviert und eingerichtet habe. Im Microsoft Kundenkonto ist ebenfalls kein Wiederherstellungsschlüssel hinterlegt.
Microsoft beharrt darauf dass der Laptophersteller mittels generischen Schlüssel oder BIOS Rollback helfen kann. Der Hersteller wiegelt ab und sieht als einzige Lösung eine Neuinstallation (inkl. Datenverlust).
Falls jemand eine Lösung zur Rettung der Daten hat, bin ich für jeden Vorschlag sehr dankbar.
Mit freundlichen Grüßen
Ich habe auf Facebook einen Dienstleister, der zwei Notebooks (Lenovo, Dell) in den Fingern hat, wo der Schlüssel abgefragt wird, es diesen aber weder im Micrsosoft-Konto noch sonstwo gibt. Mal schauen, ob der Dienstleister das Problem lösen kann.
Hier zur Ergänzung alle Rückmeldungen in anonymisierter Form:
User A: Beim Surface Pro7 zB.
User B: Wir haben bei mehreren Kunden das Problem gehabt und kamen dann nur nach langer Recherche zu dem Hinweis mit dem Code im Microsoft Konto. Bei 2 PCs ging ea aber nicht – da gab es keinen Wiederherstellungsschlüssel und KEINER der Nutzer kennt BitLocker oder hat es aktiviert – das war das OS selbst als die Verbindung mit Microsoft über das Konto hergestellt wurde. Übrig bleiben also aktuell 2 Clients die wir platt und neu machen müssen.
User C: Ich habe das Problem gerade hier auf dem Tisch – Lenovo Thinkpad 480 Wenn ich es richtig sehe, könnte es sich auflösen, wenn ich ein Firmware-Update hinbekomme? Im M$-Konto ist kein Schlüssel. Wiederherstellungspunkte gibt es auch nicht.
Das nächste Gerät mit dem gleichen Problem! diesmal DELL Inspiron 5000er-Serie – ob ein M$-Konto existiert und evtl. der Schlüssel dort liegt, weiß ich noch nicht. Der DELL-Support […] teilt nach einem Anranzer meinerseits (wegen dauerndem ins Wortfallen), das schulterzuckende Ergebnis mit "Wir haben dafür keine Lösung – wenden sie sich an Microsoft".
Ich meine, mich dunkel zu erinnern, dass Bitlocker unter bestimmten Umständen automatisch bei der Windows-Installation das Systemlaufwerk verschlüsselt. Die Umstände fallen mir nicht mehr ein, aber irgendwas war da. Secure Boot im UEFI aktiviert, TPM vorhanden, sowas in der Art.
Na dann herzlichen Glückwunsch an alle Betroffenen. Das wird sich wohl nicht lösen lassen, wenn der Wiederherstellungsschlüssel nicht bekannt ist. Und tatsächlich hoffe ich auch, dass sich das nicht lösen lässt. Nicht, weil ich jemandem was schlechtes wünsche, aber eine Hintertür für Bitlocker gibt es ja wohl hoffentlich nicht.
Hallo!
Dasselbe Problem hier. HP ProBook, keinen Bitlocker Key, kein Key im MS Account. Der Kunde weiß nichts von BitLocker.
Falls jemand noch eine Idee hat, bitte her damit :) :)
Heute hat sich bei mir eine Bekannte gemeldet, die möglicherweise dieses Problem hat, allerdings fährt der Rechner dort auch nach Eingabe des RecoveryKey nicht hoch. Sie schreibt:
"Als ich ihn hochfahren wollte, wollte er meine BitLocker- Wiederherstellungsnr.
Die habe ich inzwischen herausgefunden, sie ist auch korrekt, bestätigt der PC mir, startet neu, aber er dreht sich dann im Kreis. Ich soll die Nr. wieder eingeben and so on…., ich vermute, er hat sich irgendwo aufgehängt?"
Und davon abgesehen: Die Meldung ist jetzt einen Monat alt, aber immer noch wird der Bug nur beschrieben. Gibt es immer noch keine Lösung?
Wenn der Key immer wieder angefordert wird, dann sollte man den Bitlocker mal pausieren und den Rechner neustarten.
Oder fährt er gar nicht hoch, sondern startet gleich neu? Dann könnten vermutlich nur die üblichen Reparaturversuche helfen, wenn der Rechner nicht startet.
Gibt es hier eigentlich etwas Neues seitens Microsoft Günter?
Bisher ist es weder zurückgezogen noch ersetzt worden…
Wundert mich eigentlich, da KB5012170 doch potenziell nicht-mehr-bootende Rechner verursachen kann.
Aus dem Grund habe ich es im WSUS bisher weder zugelassen noch abgelehnt…
Mir ist nichts bekannt – ich sehe nur, dass im deutschen und englischen Blog die Betroffenen immer noch mit Kommentaren einschlagen.
Dann behalten wir das mal weiter im Auge. Besten Dank und schönes Wochenende. ;-)