Working with WDAC Policies in Azure Stack HCI 23H2

Working with WDAC Policies in Azure Stack HCI 23H2

One of the great steps forward for Azure Stack HCI 23H2 is its secure by design approach, and (optional) enforcement of a whole host of security baseline defaults out of the box.

These include a bunch of best practice security settings, including HVCI, Boot DMA protection, and a bunch more noted in the screenshot below.

There are also over 300 additional baseline settings deployed and enforced by default, which are documented in GitHub here .

Over and above this security baseline comes the enforcement of Windows Defender Application Control, or WDAC. WDAC is a feature which uses policies to control what drivers and applications are allowed to execute on the system, using a whitelisting approach, and blocking all other applications and drivers by default. Microsoft currently provides two WDAC policies for Azure Stack HCI Systems - a base policy to cover core applications and drivers needed to run the system, and an Azure CLI supplemental policy, which allows Azure CLI to run on Azure Stack HCI systems.

Through the Solution Builder Extension (SBE), OEMs are then able to provide their own supplemental policies to enable drivers and applications required by their specific implementation of Azure Stack HCI.

On Dell APEX Cloud Platform for Microsoft Azure MC nodes we can see there is a supplemental policy applied.

On Dell AX nodes we can also see that there is a supplemental policy applied.

This provides a great out of the box security posture, but what happens if you want to install a third party application? Maybe you need to install a backup agent? Or a monitoring agent of some description, what happens then?

You’ll find that when you try to run any application which isn’t explicitly whitelisted in a WDAC policy will be blocked with the message ‘An Application Control Policy has blocked this file’.

The good news is that you’re still admin of your system, and still master of your own destiny here. You can define your own custom supplemental policies, and apply them to your cluster to enable additional applications to run, without compromising the secure by default posture by having to disable WDAC.

The documented format for doing this is below - specify the path to create a new policy in XML format, and a path which contains the application you want to whitelist to run.

New-CIPolicy -MultiplePolicyFormat -Level Publisher -FilePath c:\wdac\AX-policy.xml -UserPEs -Fallback Hash -ScanPath c:\DSU

Having created your new supplemental policy, there are a few ways to apply it - you can do it with New-ASWDACSupplementalPolicy, or you can apply it via GUI in Windows Admin Center.

Once the policy is applied and enforced, you will find that the application in your specified directory can now execute on the system. Note that this doesn’t mean that anything now added to that folder can execute, only applications which were present in the folder at the point of the policy creation will be executable.