Under the Hood, Pt. 5: Intune BIOS Configurations

New in Intune 2403, native (Dell) BIOS Management capabilities! How does it work? What happens if you do something wrong?

Preparation

Before we start, we're going to need to get some pre-reqs in order, namely:

• Dell Command | Endpoint Configure for Microsoft Intune

The "secret sauce" that acts as the OEM Agent to apply a BIOS configuration to a device. The documentation is worth a read, but whether you install it manually for testing or wrap it as a Win32 for wider deployment, it's essentially a lightweight version of the Configure command-line and the "Dell.EndpointConfigure.WinServiceAgent" that will run on a device and enact the changes pushed down via Intune:

• The .NET 6.0 Runtime

A pre-req for the Endpoint Configure software to install. For convenience I added this via an Enterprise App Management package and fired it off as a Required app on all my devices:

I'd love to have been able to set this as a Dependency on my Endpoint Configure Win32 app, but sadly that's not an available option right now.

• Dell Command | Configure

Purely to enable creation of a BIOS Configuration profile in CCTK format, though theoretically if trawl the documentation and identify the options and configuration you want to apply, you could create a .CCTK file without the software.

Policy Creation

Step 1: Create your BIOS Configuration Package

Using the Dell Command | Configure software enables you to configure a massive amount of options in your Dell BIOS. As this post isn't about Configure, I suggest reading over the docs to verify what you're trying to do is valid. Also be aware that the defined configuration has to be supported by the device(s) it's being deployed to. Trying to set Intel-only options on an AMD device is probably just going to end up with it failing, but as with everything to do with BIOS config, it's very much at your own risk...

In my example configuration, I want to ensure 3 things are configured:
Virtualisation is Enabled
TPM is Enabled
Secure Boot is Enabled

I then save this configuration as a .CCTK file to be used in the Intune policy.

Step 2: Create your Intune Policy

Available as of Intune 2304, a new option is available in the "Templates" section of the new policy creation flow. Normally I'd advise against going here, but there are still some policies which only exist here and aren't configurable via Settings Catalog, this new "BIOS configurations and other settings" being one.
Don't be confused by the Device firmware configuration interface template. DFCI is a whole different thing.

After giving our policy a name, we're met with three options:

The "Hardware" dropdown only has Dell as an available choice, but it would be great if this feature was expanded to support the likes of Lenovo and HP in the future. You also get an option to disable BIOS password protection (more on how important this is later), and finally, an upload box to select our created CCTK file.

Work out your assignments and that's it!

As this wouldn't be an Under the Hood without looking at an API, below is the Graph call to create the policy:

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#deviceManagement/hardwareConfigurations/$entity",
    "id": "{GUID}",
    "version": 1,
    "displayName": "Win - OIB - BIOS - D - Dell BIOS Configuration - v1.0",
    "description": "",
    "createdDateTime": "2024-04-03T10:25:45.9524821Z",
    "lastModifiedDateTime": "2024-04-03T10:25:45.9524821Z",
    "fileName": "enable_virtualisation-tpm-secureboot.cctk",
    "configurationFileContent": "W2NjdGtdDQpTZWN1cmVCb290TW9kZT1EZXBsb3llZE1vZGUNClRwbVNlY3VyaXR5PUVuYWJsZWQNClZpcnR1YWxpemF0aW9uPUVuYWJsZWQNCg==",
    "hardwareConfigurationFormat": "dell",
    "roleScopeTagIds": [
        "0"
    ],
    "perDevicePasswordDisabled": false
}

Note the "configurationFileContent" value. Immediately throwing this into a Base64 decoder spat out the following:

[cctk]
SecureBootMode=DeployedMode
TpmSecurity=Enabled
Virtualization=Enabled

Which is (somewhat unsurprisingly) exactly the contents of the CCTK file, and why I mentioned earlier that you could theoretically just write your own without installing the Configure software at all.

Step 3: Win?

From an Intune perspective, we're done, it was that simple. If only everything in life was that easy, eh?

So we've deployed the pre-requisite apps, created our configuration and the Intune policy to deploy said configuration on a device. What now?

Let's take a look at what actually happens on the device, and places where you can check if you experience issues...

Delivery and Troubleshooting

So this is where it got interesting real fast (if you find that sort of thing interesting).

Once you've created your policy, you'd be forgiven in thinking this may come down like any other policy, but that's not the case. This is a service-driven policy just like if you enable the App Control Managed Installer functionality within Intune, and as such comes with a delay in both deploying the policy, but also in subsequent reporting. Reporting which I will add, that is very important to listen to and wait for the results of.

Key Locations:

• C:\ProgramData\Dell\EndpointConfigure

This is your primary logging location and contains logs for the Endpoint Configure agent runs.

• C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

As always, the IME Logs prove helpful, but specifically the AgentExecutor and HealthScripts logs.

• C:\Windows\IMECache\HardwareConfiguration

What's this? A brand new directory? If you dig into this folder, you'll find it's empty most of the time, but contains a copy of your .cctk file when the policy is being processed and run by the remediation script below.

• C:\Windows\IMECache\HealthScripts\{BIOSPolicyID}

The most interesting folder. In here are a detect and remediate script pair, and a file called metadata.json. All this json file contains is a Base64 string which, when decoded, gives us a certificate with the following subject:

[Subject]
CN=HardwareConfigSigning.manage.microsoft.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US

So we've got an intermediate service signing our BIOS configuration as well as version tracking. We've essentially got BIOS Desired State Configuration happening!

One thing I did notice that (as of time of writing), the Detect and Remediate scripts are checking the following reg path of:

HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension\HardwareConfig

However, due to IME being a 32-bit process, it actually ends up dumping the corresponding reg keys into WOW6432Node on a 64-bit OS, which was a bit confusing when I was trying to decode everything that's going on.

This reg location keeps the local policy version info, status, and any agent error messages which eventually then get passed back up to the service and reported on via Intune.

Another curious thing about metadata.json is if we decode this as text rather than as a certificate, we can also see some additional information:

Not only can we see policy information, serial number, a hash of the configuration file service-side, we get the existing (if set) and new password to apply to the device!

This is the ONLY way that you could possibly retrieve a device password for a device outside of the published Graph API endpoint of beta/deviceManagement/hardwarePasswordInfo

If there is one thing you need must take away from this blog, it's:

READ. THE. DOCS!

MS Learn Docs: https://learn.microsoft.com/en-us/mem/intune/configuration/bios-configuration

Dell Docs: https://www.dell.com/support/home/en-us/product-support/product/command-endpoint-configure/docs

And the reason I say this is...

Uh Oh. I broke it.

So in testing this, I assumed I knew best, and I broke my test laptop. Not entirely, but if I ever want to change BIOS settings again, I'm out of luck without submitting a repair request to Dell. So here's an explanation of where I went wrong in the hope you don't do the same thing:

Mistake Number 1:

If you do not set the "Disable per-device password protection" setting in the policy to "Yes", Intune will set a completely random BIOS password. BIOS LAPS is a theoretically neat concept, but if you're not expecting that to happen, you might be in for a bit of a shock. The first time I configured the policy, I assumed (incorrectly) that because the device didn't have a password set already, it wouldn't do anything. I was wrong, and had a BIOS password set on my device:

Mistake Number 2:

The first CCTK policy I used included a policy setting that was reliant on another setting I hadn't configured so the policy failed. I verified this in the logs, but I adjusted the deployed policy while it was still in a "Pending" state as far as the service was concerned I not only changed the CCTK, but I also switched the per-device password protection to "Yes". I haven't quite been able to identify what cadence the script runs and the results are passed back up to the service, but it's a while. Here's the bit of the Dell docs I didn't pay attention to:

Mistake Number 3:

I started to piece bits of this puzzle together, but remained impatient, and deleted and created a new policy.
Needless to say, the above warning about modifying a profile that's in a pending state goes out the window if you go and delete that policy.

End Result:

The policy and service did what it was told initially and set a random password on my device. I subsequently modified, and deleted the policy before waiting for the device to actually escrow the BIOS password. I realised what I'd done too late and couldn't sneakily retrieve the password from the metadata.json on the device, and that information isn't shown in any of the IME logs, leaving me without the password that had been set.

Summary

DFCI was a great concept that was under-supported by OEMs but even then had lackluster control over what you might want to be configuring. This functionality gives you immense capability, but somewhat unsurprisingly, comes with a lot of caveats and even more potential risk.

BIOS passwords have been a topic since I can remember, and while I'd argue that having an individual password per-device significantly reduces the attack vector on devices vs. having the same password set across everything, having a simplified, DFCI-like policy that interacts with the device in a vendor-agnostic fashion would be the ultimate dream here, but what's been implemented between Dell and the Intune team is no mean feat to accomplish, so credit where credit is due.

Just... Please read the docs, mkay?