Fixing DMA requirement for silent and automatic BitLocker encryption for Dell models

-
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 'Everyone'. Call the .bat file normally in the command line. Here are the contents of the .bat file.

SetACL.exe -on "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses" -ot reg -actn setowner -ownr "n:Everyone" -rec Yes
ping 127.0.0.1 -n 10
SetACL.exe -on "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses" -ot reg -actn ace -ace "n:Everyone;p:full" -rec Yes

Please note that it is not a good idea to give Everyone full access to files, registries. However, in this case, I couldn't make it work against a System account or a particular account so as a last resort had to give ownership to Everyone. Please use the script at your own risk. 

Create the Add_AllowedBuses.reg file

Copy the following text and save as Add_AllowedBuses.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses]
"Intel 300 Series Chipset Family LPC Controller(Q370)"="PCI\\VEN_8086&DEV_A306"
"Intel 300 Series Chipset Family LPC Controller(H370)"="PCI\\VEN_8086&DEV_A304"
"PCI-to-PCI Bridge#1"="PCI\\VEN_8086&DEV_1901"
"PCI-to-PCI Bridge#2"="PCI\\VEN_104C&DEV_8240"
"PCI Express Root Port #1"="PCI\\VEN_8086&DEV_A338"
"PCI Express Root Port #2"="PCI\\VEN_8086&DEV_A339"
"PCI Express Root Port #3"="PCI\\VEN_8086&DEV_A33A"
"PCI Express Root Port #4"="PCI\\VEN_8086&DEV_A33B"
"PCI Express Root Port #5"="PCI\\VEN_8086&DEV_A33C"
"PCI Express Root Port #6"="PCI\\VEN_8086&DEV_A33D"
"PCI Express Root Port #7"="PCI\\VEN_8086&DEV_A33E"
"PCI Express Root Port #8"="PCI\\VEN_8086&DEV_A33F"
"PCI Express Root Port #9"="PCI\\VEN_8086&DEV_A330"
"PCI Express Root Port #10"="PCI\\VEN_8086&DEV_A331"
"PCI Express Root Port #11"="PCI\\VEN_8086&DEV_A332"
"PCI Express Root Port #12"="PCI\\VEN_8086&DEV_A333"
"PCI Express Root Port #13"="PCI\\VEN_8086&DEV_A334"
"PCI Express Root Port #14"="PCI\\VEN_8086&DEV_A335"
"PCI Express Root Port #15"="PCI\\VEN_8086&DEV_A336"
"PCI Express Root Port #16"="PCI\\VEN_8086&DEV_A337"
"PCI Express Root Port #17"="PCI\\VEN_8086&DEV_A340"
"PCI Express Root Port #18"="PCI\\VEN_8086&DEV_A341"
"PCI Express Root Port #19"="PCI\\VEN_8086&DEV_A342"
"PCI Express Root Port #20"="PCI\\VEN_8086&DEV_A343"
"PCI Express Root Port #21"="PCI\\VEN_8086&DEV_A32C"
"PCI Express Root Port #22"="PCI\\VEN_8086&DEV_A32D"
"PCI Express Root Port #23"="PCI\\VEN_8086&DEV_A32E"
"PCI Express Root Port #24"="PCI\\VEN_8086&DEV_A32F"

Place the .reg file under the scripts folder of your MDT deployment share. Example - D:\MDTBuild\Scripts\Add_AllowedBuses.reg

Next step is to add these 2 in the build TS. 

1. Set DMA SetACL Permissions Dell application calling .bat file with the WMI condition against Manufacturer 'Dell'.



2. Install Allowed DMA Buses for Dell with command line to import .reg file from %scriptroot% location and with the WMI condition against Manufacturer 'Dell'.


3. Insure the machine reboots once after the reg import for the change to come into effect. 

Once the permissions were set, the .reg was imported, the device was rebooted followed by receiving BitLocker configuration policies from GPO, the encryption went through as expected. 

Conclusion

There can be other reasons for BitLocker encryption to fail, but in my experience, DMA buses not being whitelisted have usually caused silent and automatic BitLocker encryption to fail. Even though I carried out this implementation using MDT, I see no reason why the same can not be replicated using ConfigMgr or Intune.

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
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"){              ...
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from st...
Read more

Intune: Configure Printers for Non-Administrative Users

-
Image
Configuring printers for end users or giving them the ability to do it themselves is a normal requirement for organizations. Now if your users are Administrators, then the configuration can be straight forward, but in case of Non-Administrators there are additional steps required as Non-Administrators will not be able to add a driver in the driver store despite being able to install a printer. In this blog, I will cover the steps that I took to address this requirement using Intune. The setup involves 2 steps -  1. Setup registries. 2. Install the driver and configure the printer Setting up registries – The registries that need to be configured are actually part of a GPO setting – Allow non-administrators to install drivers for these device setup classes It can be found under: Computer Configuration -> Policies -> Administrative Templates -> System -> Driver Installation I used a Powershell script to set the values and wrapped it in a Win32 application. $P...
Read more