[German]I’ve got a weird case with Bitlocker under my eyes. On an HP ProBook 430 G5 with Windows 10 Pro, Bitlocker automatically encrypts certain partitions during a new installation. Then I did some research, which is probably standard for different constellations, also for Dell. Here some information and a hint how to avoid this.
First of all: Users who are using Windows 10 Home will not be affected by the following hints.
Auto encryption on HP ProBook 430 G5
I came across a curiosit in the German HP forum. The problem is that on Windows 10 Pro, when reinstalling on an HP ProBook 430 G5, partitions are automatically encrypted with Bitlocker. In this forum thread a user describes the problem:
Earlier this week my new ProBook 430 G5 (2UB47EA) has been delivered. I reinstalled Windows 10 Pro x64 with a Microsoft ISO image (1903).
But there was a big surprise. The drives C and D were encrypted with BitLocker without my intervention. At first I suspected a bug in the latest version of Windows 10. So I reinstalled it with the MS-Image 1809. With this image I have already installed about 50 PCs and Notebooks. All installations went smoothly and as expected. But my drives C and D were encrypted with BitLocker again.
The user was able to decrypt the drives using the Control Panel. However, he is surprised about this unusual behavior, which he cannot explain. It’s the first time I’ve bought a notebook with an Intel i7 processor. Is there anything in the “system architecture” that triggers this behavior?
Seems to be the case with Windows 10
That could be another HP specialty. I then looked in the Internet and found this thread BitLocker turns on without a notice in Technet from October 2017. There, the thread creator refers to Dell notebooks, where an IT employee noticed a strange behavior.
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.
People use a group policy to control bitlocker encryption so that users are asked if they want to do so before encrypting. Now the employee has made a strange observation:
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.
It’s a strange thing. The user then describes his further experience after rebuilding Dell – including the problem that the recovery key for bitlockers is not stored at the group policy position in the Active Directory object (AD) – something 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.
In short: In this case, Bitlocker was also automatically activated on hard disks without any user intervention. The explanation can be found on this Dell page. The article Automatic Windows Device Encryption/BitLocker on Dell Systems contains the following note:
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).
It is a feature that becomes active in the Out-of-box-experience (OOBE) phase of the setup. The machine must have a TPM module and the hardware requirements specified by Dell. Other vendors are using a similar behavior.
Tip: Use a local account during setup
I assume that administrators who regularly use Windows 10 machines with Pro/Enterprise are aware of this problem. If not, you can find the necessary information in the above article. Is the above mentioned problem with the storage of the recovery key in the AD, contrary to the GPO specifications, an issue for you?
BitLocker management in enterprise environments
Dell: New BIOS is causing Bitlocker issues
Bitlocker on SSDs: Microsoft Security Advisory Notification (Nov. 6, 2018)
SSD vulnerability breaks (Bitlocker) encryption
Windows 10 V1803: Fix for Bitlocker bug in Nov. 2018?