Bitlocker Download
Nichole Wernett
After you type in the recovery key and the laptop boots up be sure to pause then resume bitlocker. This should reestablish the trust and stop the prompt. I would make sure the latest bios is installed and lock down the bios with a password. Also make sure the boot order is only allow the C drive to boot from.
I have a laptop running Windows 7 Ultimate. I have encrypted my drives using BitLocker. Now I have also installed Lubuntu along with Windows. But my encrypted drives are not visible in Linux. How can I fix this?
My problem was that I could not boot Windows, and I needed a way to access my files on a Bitlocked partition. In order to do this, you need a bitlocker recovery password (8 groups of digits) and the ability to boot your system from USB.
CryptSetup has added experimental support for BitLocker as of version 2.3.0 (February 2020), which is available in Ubuntu's repos for 20.10 Groovy onwards, although support will likely improve in later versions.
When setting up BitLocker on a device choose the option that encrypts the whole device (requires more time). The other option uses Encrypt-On-Write conversion model that makes sure that any new disk writes are encrypted as soon as you turn on BitLocker (data that existed on the device before encryption began can still be read and written without encryption) and is not supported by Cryptsetup.
Once the drive is decrypted, you can use TrueCrypt instead; reading a System Encryption volume under Linux isn't supported by default, but someone has figured out a work-around. See How to use TrueCrypt-encrypted Windows system drives on Linux.
I tried @SrjCoder's suggestion of using a VM. But with VirtualBox on the Linux host, I was not able to see the encrypted drive in the guest Windows system. The unmounted block device that had the encrypted drive was not visible in the VM. I didn't try VMware, and I'm not a VirtualBox expert, so maybe I missed something there.
Finally I installed Windows 10 Pro on a separate machine, and connected the encrypted drive, Windows recognized it as a Bitlocker drive, and I was able to unlock it with the recovery key, and the valuable data was saved! The end.
If you're wondering why I didn't just boot the encrypted drive, it is in a bad state and cannot boot. It blue-screened trying to go back to a restore point. Luckily the data partition was still intact.
I don't know since when nemo supports it, but I installed Ubuntu on a second SSD in my school laptop and could just see the BitLocker'd drive in the "Devices" part of nemo's sidebar as "253 GB encrypted drive". When I clicked it it asked for my BitLocker key and for how long to remember it (not at all, until logout, permanent). When I entered the key it was successfully mounted as "Windows" with the path /media//Windows.
@Henke I guess what I was trying to say is that you can still get the VM backed up and restored if needed, however when it comes to the datavolumes, my understanding is that you would not be able to backup that up while the volume is locked.
For VMware or other VSA style backups, you can backup the volume no problem, but file level browse wont work since that would require the decryption key and code to process bitlocker volumes. You could still do a full VM restore or restore/attach the volume back to another VM to decrypt it
Hello,
I've read through all the material I can. I am struggling to understand what is supposed to happen when you have Bitlocker settings enabled for the system drive.
Here is our situation. We are not joining the computers to a domain and users do not have a microsoft account. When they log into windows GCPW gives them a standard user account. On my two test machines despite having the settings enabled nothing happens regarding Bitlocker. Coming from a domain encironment I am already fairly familiar with Bitlocker so I assume this is because there is nowhere to store the recovery key and likely because they are not an administrative user.
Should we just be enabling Bitlocker using the local admin account before distributing the computer?
Will it report in the admin console correctly if it is done this way?
What is everyone else doing in regards to Bitlocker?
If you are not seeing this, can you verify that the device is successfully enrolled with advanced Windows management? You can check if device is enrolled from the settings app. You can also create logs and look at bitlocker value. -us/windows/client-management/mdm-collect-logs
Would it prompt them if they are a standard user? Standard users normally can't enable bitlocker. I have an open ticket with support and am waiting to see what they say. In the meantime I added a second test computer, same behavior. Nothing happens all other policies seem to be working.
Ah that could be the problem. Just looking into Microsoft's documentation, there seems to be new settings enabled in the OS that can make this possible. Can you use Custom settings section of Admin console to enable these settings in addition to the bitlocker settings?
I don't mind turning bitlocker on with the local administrator account. However, on my test machine when I enable bitlocker with the local administrator account, the admin console still reports that the device is unencrypted.
From what I can tell If you enable bitlocker before enrolling the device to a user the admin portal will never correctly report the device as encrypted. This creates a catch 22. You have to enroll the device before the user gets it to enable bitlocker.
The policies you listed state that they are only for Azure Active Directory Joined devices.
the local Admin account, which is censused in the Admin console in the GCPW settings, have to enable Bitlocker manually and save elsewhere the recovery key.
The key can't be stored on the same drive, but a GDrive-enabled folder (Google Drive for Desktop) does the trick.
Hello. My personal usage with bit-locker encryption and Norton "backup" is that Norton doesn't play well with that. As far as running Norton on an encrypted drive OS I have never had issues doing so. Just keep in mind that Bitlocker SHOULD provide you with its own recovery key which you will need in the event of a drive recovery.
a few months ago there was a microsoft update forget the kb # addressing bitlocker , which for many caused some issues with a random blue screen of enter your bitlocker number etc... ( when you turn on device)
Hi mgm71
With regards to Bitlocker, that is just a drive encryption option, which is different functionality to Norton Anti-virus and is another layer or protection, should your PC be stolen, but has nothing to do with protection from malware on your PC . . .
Gen trademarks or registered trademarks are property of Gen Digital Inc. or its affiliates. Firefox is a trademark of Mozilla Foundation. Android, Google Chrome, Google Play and the Google Play logo are trademarks of Google, LLC. Mac, iPhone, iPad, Apple and the Apple logo are trademarks of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc. Alexa and all related logos are trademarks of Amazon.com, Inc. or its affiliates. Microsoft and the Window logo are trademarks of Microsoft Corporation in the U.S. and other countries. The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License. Other names may be trademarks of their respective owners.
But when the client sends the actual Bitlocker boot request the packet isnt being forwarded by the Fortigate. We can see the broadcast but nothing happens to it :( The packet looks OK so not really sure why it isnt forwarded.
I have the exact same issue, I've been struggling with it now for what seems like forever. I was planning on testing your suggestion actually before I found it. I did implement that change, however what I've found is that the traffic does indeed appear on the correct network when I sniff the interface on the fortigate (which it wasn't doing before) but when I take a packet capture on the server it isn't seeing JUST the BOOTP packet (even though it appears to being forwarded from the FGT packet capture dump on the firewall).
Used in conjunction with the dhcp-relay on the interface what appears to happen is that DHCP packets are being rebroadcast in the correct (server) network, but the microsoft DHCP server is completely ignoring them and only responding to the fortigate ip-helper-fixed (via the dhcp-relay agent) packets--those packets are being 'fixed' by the FortiGate with a relay-ip address.
Were you successfully able to get your WDS server to 'see' the incoming bitlocker BOOTP packet with this method? FWIW I checked the windows firewall rules and added an appropriate rule for ports 67-68 on the WDS server...no dice.
It seems like the easiest solution would be for the FGT to 'fix' these packets like it does for the other DHCP packets; I'm on 5.6.7 and I can confirm it still doesn't do so. Did you ever get this to work, either through the broadcast forwarding or through another novel method?
As you can see the original poster never wrote back how they were successful--I did test a multicast broadcast policy as they suggest but it had no effect (yes the packet landed in the right network but it was unusable by the server hosting WDS without being fixed up with a relay-agent-IP by a helper). After testing that, I abandoned multicast forwarding, and here's what I can tell you in general:
Basically after a week and multiple interactions, they said that the DHCP relay daemon will NOT fix-and-forward BOOTP type packets (which is the nature of the BitLocker packet), here is the excerpt from the support ticket--
59fb9ae87f