#Modern Workplace

When it comes to capturing BitLocker encryption status, there are multiple options available in the Windows compliance policy in Intune. From  Require BitLocker , Require Secure Boot to be enabled on the device , and Require code integrity under Device Health attestation, to  Require encryption of data storage on device which not only captures the encryption status of the OS drive against BitLocker, but even non-Microsoft encryption solutions. However, it is a known fact that due to delays in getting BitLocker encryption compliance to report in a timely and accurate manner, it can rather be challenging in getting the right compliance settings in place. Especially if the device compliance state is being used in Entra ID conditional access policies. Another issue that I have come across is lack of compliance reporting against BitLocker recovery key escrow. This is especially common in Co-management scenarios when the BitLocker Drive Encryption management has moved to Intune an...

Majority of organizations will allow end users to retrieve the BitLocker recovery key through self service. While this certainly eases the manageability and cuts down on support calls, the question to ask here is whether it is secure or not. To answer that, let me play out a scenario first. Let's say a bad actor has got access to a company device and is able to initiate a reboot into advance startup. Now a device that is encrypted with BitLocker protection, will be presented with the screen to enter the recovery key. At this stage one can retrieve the recovery key either through self service portal like https://account.microsoft.com/devices/recoverykey or reach out to service desk. Now what if the attacker has been successful in stealing the credentials of the owner of the device? In the absence of necessary security policies in place, the attacker can retrieve the recovery key from https://account.microsoft.com/devices/recoverykey, or even Entra admin portals by themselves if allo...

Last year, I had blogged about addressing the DMA requirement for Lenovo devices. This time I am covering the same requirement for Dell models using MDT. I recently did an MDT implementation and as part of the requirements, Dell devices needed to be BitLocker encrypted. Nothing unusual about it, except some models refused to get encrypted. Having dealt with the similar issue in the past with Lenovo devices, I immediately checked the event viewer logs and details in System information. As suspected the issue turned out to be un-trusted DMA buses. Dell has provided the solution  which needs to be put in an automated process. This is how you can go about it. The solution involves 2 steps – 1. Set Permissions to take ownership of the DmaSecurity registry key. 2. Import the Add_AllowedBuses.reg containing the Bus classes provided by Dell. Set Permissions I created an application containing the  SetACL.exe  utility and the .bat file to give ownership and full rights to 'Everyo...

Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){              ...

A while ago, I was working on an endpoint management project and one of the key requirements was to roll out BitLocker policies to the Windows 10 MDM enrolled devices. As much as this may seem routine, what made things interesting was that the customer only had Lenovo devices and apparently it required some additional bits and pieces to be put in place along side the Intune BitLocker encryption settings. I will cover the details and my experience through this blog. Before going into the details, please make a note of the requirements for automatic BitLocker device encryption: 1. Device should be running 1903 with latest CU or newer build. 2. TPM 1.2 or 2.0. 3. UEFI Secure Boot should be enabled. 4. DMA protection should be enabled. As for my project requirements for enabling BitLocker encryption are concerned, they are as follows - 1. Enable BitLocker of OS drive. 2. Configure BitLocker automatically and silently without any kind of user interaction. 3. Disable Startup Pin. 4. Escrow...