[English]Mir ist ein merkwürdiger Fall zu Bitlocker unter die Augen gekommen. Auf einem HP ProBook 430 G5 mit Windows 10 Pro verschlüsselt Bitlocker bei einer Neuinstallation automatisch bestimmte Partitionen. Ich habe dann etwas recherchiert, das ist wohl Standard bei verschiedenen Konstellationen, auch bei Dell. Hier ein paar Informationen und ein Hinweis, wie sich das vermeiden lässt.
Anzeige
Vorab: Anwender, die mit Windows 10 Home unterwegs sind, werden von den nachfolgenden Hinweisen nicht tangiert.
Autoverschlüsselung beim HP ProBook 430 G5
Im HP-Forum bin ich die Tage auf eine Merkwürdigkeit gestoßen, die ich euch nicht vorenthalten wollte. Problem ist, dass auf Windows 10 Pro bei einer Neuinstallation auf einem HP ProBook 430 G5 automatisch Partitionen mit Bitlocker verschlüsselt. In diesem Forenthread beschreibt ein Nutzer das Problem:
Anfang der Woche ist mein neues ProBook 430 G5 (2UB47EA) geliefert worden. Windows 10 Pro x64 habe ich neu mit einem Microsoft ISO-Image (1903) installiert.
Es kam es aber zu einer großen Überraschung. Die Laufwerke C und D waren ohne mein Zutun mit BitLocker verschlüsselt. Zuerst vermutete ich einen Bug in der neuesten Windows 10-Version. Also erneute Neuinstallation mit dem MS-Image 1809. Mit diesem Image habe ich bereits geschätzt 50 PCs und Notebooks neu installiert. Alle Installationen verliefen problemlos und wie erwartet. Aber bei mir waren wieder die Laufwerke C und D mit BitLocker verschlüsselt.
Der Benutzer konnte die Laufwerke zwar per Systemsteuerung wieder entschlüsseln. Allerdings wundert er sich aber über dieses ungewohnte Verhalten, was er sich nicht erklären kann. Es ist allerdings das erste Mal, dass ich ein Notebook mit einem Intel i7-Prozessor gekauft habe. Gibt es etwas in der "Systemarchitektur", das dieses Verhalten auslöst?
Scheint bei Windows 10 der Fall zu sein
Das könnte ja noch eine Spezialität von HP sein. Ich habe dann im Internet nachgeschaut und bin im Technet auf diesen Forenthread BitLocker turns on without a notice von Oktober 2017 gestoßen. Dort bezieht sich der Thread-Ersteller auf Dell Notebooks, wo einem IT-Mitarbeiter ein merkwürdiges Verhalten aufgefallen ist.
Anzeige
Since a while we are experiencing some strange behavior with Windows 10 (I think it only apply to Creators update), Dell Notebooks and Bitlocker. In our company we have a global GPO which, if one wants to encrypt his harddrive with BitLocker, to be prompted to save the recovery key txt file on a certain share, BitLocker key is also saved to computer object in AD… But this is optional, none is forced to do so.
Die Leute verwenden eine Gruppenrichtlinie zur Steuerung der Bitlocker-Verschlüsselung, so dass die Nutzer vor dem Verschlüsseln gefragt werden, ob sie dies so tun wollen. Nun hat der Mitarbeiter eine merkwürdige Beobachtung gemacht:
Now, just a few days ago I realized that on fresh Dell notebook installs, factory image of Dell, the C-drive (it's usually our only drive) is shown with a yellow exclamation mark in file explorer. I have googeledd that and figured out it is a sign that bitlocker is not activated. No idea since when this is like that, did not realize it before in this context. However, I left it as is because I did not have the intention to enable bitlocker.
Schon eine merkwürdige Sache. Der Nutzer beschreibt dann seine weiteren Erfahrung, nachdem er den Dell neu aufgesetzt hatte – unter anderem das Problem, dass der Wiederherstellungschlüssel für Bitlocker nicht an die per Gruppenrichtlinie gesetzte Position im Active Directory-Objekt (AD) gespeichert wird – etwas strange:
Next day I just saw the yellow exclamation mark is gone and indeed, the drive was bitlocked. This happend automatically, without my knowledge. And also the key was saved to this notebooks AD object. But obviously the key saved in a txt file was not saved to that network share defined in the policy, though.
How can it happen that bitlocker turns on on its own? In our case, not sure if for each and any, at least the key is saved to AD. But what if this doesn't happen? Users might lose access to their data? I also have read a few posts online like e.g. Bitlocker auto-enabling itself on a fresh Windows installation on XPS 13?, that a few other users also experience the same issues. I stumbled around computers in our AD and figured out that several PC's suddenly show a bitlocker key, and definitely not all of them have turned this on on purpose. You can easiliy figure it out, just compare computer objects with bitlocker key vs. kex-txt files on our share. The ones with corresponding key txt file have done it on purpose, the others not.
Also in kurz: Auch bei diesem Fall wurde Bitlocker ohne Zutun der Nutzer automatisch auf Festplatten aktiviert. Die Erklärung findet sich auf dieser Dell-Seite. Im Beitrag Automatic Windows Device Encryption/BitLocker on Dell Systems findet sich folgender Hinweis:
Automatic device encryption allows Windows to encrypt the system drive automatically after you completed the setup of your system. This occurs very similar to smartphones and is completely seamless for the user. Automatic device encryption however is only enabled on systems that meet above system requirements and support Connected Standby or Modern Standby specifications, which require solid-state storage (SSD or eMMC) and non-removable (soldered) RAM.
Automatic device encryption only starts after the Out-Of-Box Experience (OOBE) is completed and a Microsoft Account (MSA) is used on the system (e.g. use MSA for Windows logon, add MSA as email, app and work/school account, log into the Microsoft Store app with MSA, redeem/activate Microsoft Office or other Microsoft applications with MSA).
Es ist ein Feature, welches in der Out-of-box-experience (OOBE) Phase des Setup aktiv wird. Dazu muss die Maschine ein TPM-Modul besitzen und die von Dell genannten Hardwarevoraussetzungen aufweisen.
Tipp: Beim Setup ein lokales Konto verwenden
Dieses Verhalten kann man verhindern, indem man beim Setup der Systeme kein Microsoft-Konto sondern ein lokales Benutzerkonto verwendet. Das ist sowohl auf dieser Dell-Seite als auch bei HP im Forum.
Ich gehe mal davon aus, dass Administratoren, die regulär Windows 10-Maschinen mit Pro/Enterprise um diese Problematik wissen. Falls nicht, sind in obigem Beitrag die notwendigen Informationen zu finden. Ist das oben angerissene Problem mit der Speicherung des Wiederherstellungsschlüssels im AD, entgegen der GPO-Vorgaben, ein Thema bei euch?
Artikelreihe:
Windows 10: Wichtiger Secure Boot/Bitlocker Bug-Fix
Windows 10: Bitlocker verschlüsselt automatisch
Ähnliche Artikel:
BitLocker-Verwaltung für Unternehmensumgebungen
Windows: Angriff auf Bitlocker per TPM
SSD-Schwachstelle hebelt (Bitlocker) Verschlüsselung aus
Microsoft Security Advisory Notification ADV180028 zu Bitlocker auf SSDs (6. Nov. 2018)Dell: Neues BIOS verursacht Bitlocker-Probleme
Windows 10 V1803: Fix für Bitlocker-Bug im November 2018?
Neues Surface Book 2 Firmware-Update bringt ggf. Bitlocker-Problem
Windows 10 V1803: Kein Backup für BitLocker-Wiederherstellungsinformationen in AD
Anzeige
Guten Morgen,
Dieses Verhalten ist schon lange Windows Standard (Device Encryption). Sobald ein Client HSTI fähig ist (Hardware und UEFI Anforderungen erfüllt) wird die Systempartition automatisch von Beginn an verschlüsselt. Die MS Surface Geräte machen dies schon immer.
Es wird mit 128Bit AES-XTS nur der beschriebene Bereich der Festplatte verschlüsselt.
Dieses Verhalten kann dadurch verhindert werden, indem man das Installationsmedium anpasst. Es ist ein entsprechender RegKey zu setzen.
Der Reg-Key:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker]
"PreventDeviceEncryption"=dword:00000001
Temporärer Bypass für entfernbare Geräte wie z.B. USB-Sticks oder USB-Platten
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE]
"RDVDenyWriteAccess"=dword:00000000
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE]
"RDVDenyWriteAccess"=dword:00000001
Das Verhalten kenne ich von den Surface und Dell-Laptops mit Windows 10 Pro. Mit einem Microsoft Konto hat das nichts zu tun gehabt. Das gelbe Warnzeichen zeigt zwar an, das ein Laufwerk angeblich nicht verschlüsselt ist, die Datenträgerverwaltung ist da aber anderen Ansicht. Die Partition lässt sich auch nicht mit Partitionierungstools verändern, bis wieder entschlüsselt wurde.
Man muss Bitlocker aktivieren und gleich darauf wieder deaktivieren.
Mal abgesehen davon, dass man hier im März erst über den Angriff auf Bitlocker per TPM (Link siehe oben) lesen konnte, macht diese automatische Verschlüsselung eigentlich auch Sinn. Da hat man ein Notebook mit TPM-Modul und startet per Secure Boot und dann sollen die Festplatten unverschlüsselt sein? Wäre dann doch wohl eher ziemlich unsinnig.
Gehst Du in die verlinkten Artikel aus den Foren, wirst Du möglicherweise bemerken, dass es durchaus Gründe geben kann, warum Administratoren genau diesen Automatismus vermeiden wollen.
Habe ich jahrelang gemacht. Und immer ein eigenes Installationsverfahren und angepasste Installationsmedien genutzt, wo die eigenen Erfordernisse an Installation und Sicherheit umgesetzt wurden. Deshalb ist das jetzt aber kein Bug, sondern eher eine vernünftige Grundinstallation für einzelne (neue) Geräte. Man muss es nur wissen, und dann kann man es ohne Probleme anpassen. So ist aber erst einmal ein neues Gerät als Standard weniger angreifbar und Secure Boot sicherer (nicht unbedingt sicher).
Zur 'Deshalb ist das jetzt aber kein Bug,': Hast Du in meinem Artikel das Wort Bug gefunden? Es kommt nur in einem Zitat vor – im Text sollte das nicht stehen. Das Attribut "vernünftig" würde ich allerdings nicht zu eigen machen – das entscheidet der Betroffene für sich, ob es für ihn vernünftig oder ärgerlich ist.
Na ja, Du hast es merkwürdiger Fall/Merkwürdigkeit genannt. Ist das, was ich mit einem Bug gleichsetze, ein nicht erwartetes und (eventuell) fehlerhaftes Verhalten.
Und warum soll das jetzt ärgerlich sein. Es gibt für mich zwei Fälle:
a) Man kennt sich mit Windows aus. Dann schaut man sich nach einer Installation ohnehin an, wie die Platten/SSDs bei der Installation konfiguriert sind. Stört einen die Bitlocker-Verschlüsselung, kann man sie ohne Probleme wieder aufheben. Setzt man andere Verschlüsselungsprodukte ein, werden die einen ohnehin warnen. Kein Produkt kann seine Verschlüsselung auf eine andere Verschlüsselung aufsetzen. Also weiß man spätestens an der Stelle, dass man Bitlocker wieder loswerden muss.
b) Man kennt sich mit Windows nicht aus. Und lässt das neue Notebook so wie es ist. Dann hatte man bislang immer eine unverschlüsselte Platte. Und wenn einem das Gerät geklaut wurde, konnte jeder die Platte ausbauen und die Daten auslesen. Und Notebooks werden gerne geklaut, auch bei privaten Wohnungseinbrüchen. Oder das Gerät geht nach kurzer Zeit kaputt. Dann geht das Gerät zur Reparatur und die Platte geht ungeschützt mit.
Von daher erscheint mir das weiter sinnvoll. Der Profi wird es schnell wieder los und der normale Käufer hat einen etwas sicheren Notebook (mit Secure Boot und einer erstmal geschützten Platte/SSD). Wie oft wird sich darüber beschwert, dass Anwender/Admins auf Datenbanken keine Admin-Passwörter setzen und diese dann ungeschützt im Internet stehen. Oder auf Smarthome/IOT-Geräte keine Passwörter gesetzt werden bwz. Standardpasswörter nicht geändert werden und die Geräte dann von außen mißbraucht werden können. Ich finde, dann sollte man sich nicht darüber beschweren, dass man bei einem neuen Notebook erstmal eine sichere Grundkonfiguration verpasst bekommt.
Abgehen davon, wenn man heute ein neues Notebook kauft, kann man das ohnehin ohne Nacharbeit nicht vernünftig einsetzen. Geh mal auf die Supportseite von HP und schau, wieviele Software und Treiber zum Beispiel auf ein ProBook bei der Ersteinrichtung installiert werden. Das wieder loszuwerden, dauert deutlich länger.
Zu Variante B ginge das auch trotz Bitlocker. Man läßt die Platte drin und setzt einfach das Windows Passwort neu.Das ließe sich zwar per Preboot-PW verhindern, aber das wäre dann wieder der erfahrene Anwender.
Aus aktuellem Anlass kann ich den Sicherheitsgewinn für wenig erfahrene Anwender nicht nachvollziehen. Im Gegenteil ist der unbekannt aktivierte Bitlocker eine Gefahr für die Daten. Wenn das Mainboard defekt geht komme ich an die Daten nicht mehr ran, wenn klammheimlich Bitlocker aktiv gesetzt wurde.
Ich habe jetzt nicht berücksichtigt, dass man das Windows-PW nicht mehr so einfach per Administratoraktivierung zurücksetzen kann, wenn die Platte verschlüsselt ist.
Blog-Leser Uwe B. hat mir noch per Mail Hinweise zu eigenen Erfahrungen mit Bitlocker und der automatischen Verschlüsselung zukommen lassen.
Kann ich bestätigen, wir hatten gerade diese Woche wieder mehrere solche Laptops (HP & Lenovo). Hier die Originalquellen bei MS zu den aus Foren und OEM-Seiten zusammengetragenen Informationen:
Gemäss Microsoft Doku für OEM Systeme gilt folgendes:
Note: BitLocker automatic device encryption is enabled only after users sign in with a Microsoft Account or an Azure Active Directory account. BitLocker automatic device encryption is not enabled with local accounts, in which case BitLocker can be manually enabled using the BitLocker Control Panel.
https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-bitlocker
Hier die ausführlichere Version aus der generellen Bitlocker Doku:
Unlike a standard BitLocker implementation, BitLocker Device Encryption is enabled automatically so that the device is always protected. The following list outlines how this happens:
– When a clean installation of Windows 10 is completed and the out-of-box experience is finished, the computer is prepared for first use. As part of this preparation, BitLocker Device Encryption is initialized on the operating system drive and fixed data drives on the computer with a clear key (this is the equivalent of standard BitLocker suspended state). In this state, the drive is shown with a warning icon in Windows Explorer. The yellow warning icon is removed after the TPM protector is created and the recovery key is backed up, as explained in the following bullet points.
– If the device is not domain joined, a Microsoft account that has been granted administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to the online Microsoft account, and a TPM protector is created. Should a device require the recovery key, the user will be guided to use an alternate device and navigate to a recovery key access URL to retrieve the recovery key by using his or her Microsoft account credentials.
– If the user uses a domain account to sign in, the clear key is not removed until the user joins the device to a domain and the recovery key is successfully backed up to Active Directory Domain Services (AD DS). You must enable the Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives Group Policy setting, and select the Do not enable BitLocker until recovery information is stored in AD DS for operating system drives option. With this configuration, the recovery password is created automatically when the computer joins the domain, and then the recovery key is backed up to AD DS, the TPM protector is created, and the clear key is removed.
– Similar to signing in with a domain account, the clear key is removed when the user logs on to an Azure AD account on the device. As described in the bullet point above, the recovery password is created automatically when the user authenticates to Azure AD. Then, the recovery key is backed up to Azure AD, the TPM protector is created, and the clear key is removed.
https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-device-encryption-overview-windows-10
Es scheint also, dass auch bei einem lokalen Account zuerst mit einem Clear Key vorverschlüsselt wird.
In unseren Fällen ist aber wahrscheinlich der Schritt fehlgeschlagen, der an Stelle von:
The yellow warning icon is removed after the TPM protector is created
passieren sollte (-> weil wenn ein lokaler Account verwendet wird, deshalb eben kein definitiver Key ins TPM geschrieben wird, sondern einfach die ClearKey Verschlüsselung aufgehoben werden sollte)
Was aber bei lokalen Accounts genau passiert nach der Clear Key Verschlüsselung habe ich nicht herausgefunden.
Ich habe hier ein HP Elitebook G3 auf dem Tisch wo ich nach Erhalt direkt mal das Bios aktualisiert habe und die HDD durch ne 250GB NVME SSD ersetzt wurde. Nach dem Bios update war das TPM Modul per "Default" wieder automatisch aktiviert.
Danach wurde vom USB Stick Win10 Pro 1909 mit LOKALEM KONTO installiert – Absichtlich Offline – Und trotzdem wurde sofort die NVME SSD mit Bitlocker verschlüsselt.
Daher stimmz "BitLocker automatic device encryption is not enabled with local accounts" nicht !
Aufgefallen ist es mir direkt nachdem ich die fertige Installation mit Acronis imagen wollte – der Jammert dann wegen Verschlüsselung.
Ein:
manage-bde -off c:
hat dem ganzen Spuk dann ein Ende bereitet.
Grundsätzlich finde ich die Verschlüsselung gut, gerade bei Geräten die Abhanden kommen könnten – jedoch wäre schon ganz Nett wenn man Gefragt werden würde.
Ich habe auch ein Elitebook G3, das jetzt in der Reparatur war und mit "Geben Sie den BiLocker Recovery Key ein" zurückkam, den ich aber noch nie zuvor gesehen hatte und deshalb selbstverständlich auch nicht eingeben konnte. Serh ärgerlich!
Ich habe das ganze über das Löschen der Festplatte und Reinstallation des Betriebssystems wieder hinbekommen. Jetzt wird die Festplatte aber jedes Mal wieder verschlüsselt, sobald ich eine Installation (Treiber usw) durchführe und das Laptop danach wieder neustarten muss.
Bei der Suche, wie ich das abstellen kann, bin ich jetzt auf deinen Eintrag hier gestoßen.
Ich kenne mich mit Computersprache nicht besonders gut aus und wollte deshalb fragen, ob du deine Lösug noch ein wenig einfacher erklären kannst. Speziell was "manage-bde -off c:" bedeutet.
Kurzer Nachtrag mit einem Dell Precision 3551:
Hatte das Gerät komplett gelöscht, neu partitioniert und mit einem frischen W10 21H1 aufgesetzt, ohne Dellimage oder Tools.
Nach 2 Monaten habe ich das TPM2.0 und Secureboot im UEFI deaktiviert, weil ich noch andere Systeme installieren will. Da fiel mir dann das Ausrufezeichen im Explorer auf. Selbst die nachträglich eingebaute SATA-2,5"-SSD wurde nebst der originalen M2-NVME-SSD verschlüsselt!
Ach ja, das ganze gänzlich ohne Microsoftkonto, also von Anfang an ein lokales Konto unter W10pro.
Hallo zusammen,
hat vielleicht jemand schon eine Lösung wie man das ganze deaktivieren kann?
Wir setzen unsere Systeme per Softwaredeployment-Tool auf und während der OS Installation läuft die Verschlüsselung an, das soll jedoch nicht passieren.
Haben bisher schon die Möglichkeit genutzt per Registry-Key dies zu verbieten und in der unattend.xml dies zu tun. Beides hilft jedoch nicht, zweiteres funktioniert scheinbar nur unter Windows 8.
Auch die Möglichkeit manage-bde -off c: auszuführen wurde schon getestet, das scheint jedoch nur zu funktionieren wenn die Verschlüsselung schon aktiv ist.
Viele Grüße,
Stefan
Auch ich suche Hilfe zu diesem Problem.
habe ein HP ProBook 450 G7, das gerade wegen einer defekten Tastatur in der Garantiereparatur war – wo auch Windows 10 neu installiert wurde. Tastatur geht wieder, aber die Datenfestplatte (auf der sich keine Daten befinden, hatte vor dem Einsenden alles entfernt) ist von Bitlocker gesperrt. Ich wusste bis vor einer halben Stunde nichts von der Existenz von Bitlocker – das muss also in der Reparatur bei HP passiert sein.
Wie kann ich den Spaß denn jetzt lösen, damit ich das Notebook wieder nutzen kann? Auf ein erneutes Einsenden habe ich keine Lust, ich kann nicht noch einmal 10 Tage ohne Notebook sein. "Wiederherstellen" (also Windows 10 neu installieren) habe ich schon gemacht – hilft nix, die Platte ist weiterhin durch Bitlocker gesperrt. In meinem Microsoft-Konto befindet sich kein Schlüssel.
Ich bin Laie, falls also irgendjemand irgendwelche Tipps hat, wäre ich sehr dankbar.