This post covers how to deliver a WDAC policy with Intune. It is part of a series about WDAC policies. To perform this step, we need to have previously created a policy and tested it manually. The Microsoft documentation on delivering a WDAC policy with Intune is confusing and incorrect. This is how to do it.
Background
Windows Defender Application Control (WDAC) is the native Windows 10 security feature to control what files can be executed by the system. A WDAC policy is created in XML format using PowerShell, then converted to binary. A binary policy file saved with the name SIPolicy.p7b in the C:\Windows\System32\CodeIntegrity folder will be implemented by Windows as an Application Control policy. We just need a way to deliver the file. This is how to do that with Intune.
Short version
- Create a custom device configuration profile.
- Add an OMA-URI setting with ./Vendor/MSFT/ApplicationControl/Policies/[Policy GUID]/Policy. The Policy GUID is the GUID of the policy.
- As the data type, select Base64 (file)
- Upload the binary file created previously
- Assign the policy to a computer or user group.
Long version
We have already seen that we can copy a policy binary to the Code Integrity folder manually, and it will take effect (in Test a WDAC Policy). We just need a way for Intune to deliver the file. There are no additional settings to configure.
Intune has an Endpoint Protection profile to configure WDAC, but this is a pre-defined policy with only two options. The policy allows Windows components and Microsoft store apps to run. You can choose to use Audit or Enforced mode. And, optionally, you can use Intelligent Security Graph (ISG) to allow apps based on reputation derived from Microsoft cloud analytics. This policy is too restrictive to be used in a normal desktop environment, with third party applications. If it blocks even one application you can’t use it. To implement a custom policy with Intune, we need to use a custom profile type.
Until Windows 1903, WDAC policies were delivered (rather confusingly) by the Code Integrity part of the AppLocker CSP. This reflects the history of WDAC as Device Guard Code Integrity. With Windows 1903, WDAC policies are delivered by the new ApplicationControl CSP. This supports new features including Multiple Policy Format, which enables separate policies to be merged at runtime. Currently, standard WDAC policies (non-multiple) can be delivered by either the AppLocker or the ApplicationControl CSP. This post uses the latter, because the series is about using File Path Rules in a WDAC policy, which are also only supported from Windows 1903 onwards.
The steps to create a custom Intune profile are well documented. For WDAC we need the following OMA-URI setting:
./Vendor/MSFT/ApplicationControl/Policies/[Policy GUID]/PolicyThe Policy GUID is the actual GUID contained in the XML file. This is unlike, say, a custom ADMX profile where the GUID is an arbitrary reference. Here the GUID refers specifically to the internal GUID of the policy. Enter the GUID without the curly braces. If you use the curly braces you will get a syntax error: “Syncml(400): The requested command could not be performed because of malformed syntax in the command.”
For single policy format, you need to enter the PolicyTypeID, For multiple policy format, you need to enter the PolicyID.
Select Base64 (file) as the data type. Then select, as a file to upload, the binary version of the policy obtained from ConvertFrom-CIPolicy.
The Microsoft documentation repeatedly and incorrectly refers to encoding the binary as Base64. I can only guess the reason for this. Someone in the development or documentation process has misunderstood. The SyncML protocol does not have a binary file data type. So Intune is just using the Base64 data type to deliver the binary file. To make matters worse, if you use the AppLocker CSP, Intune will appear to deliver the file successfully. It just won’t work. If you use the ApplicationControl CSP, Intune will also accept and deliver the file, but the policy will give an error status. In the MDM device management log it will show: “Arithmetic result exceeded 32 bits”.
This is what the custom OMA-URI setting will look like.
When the policy is delivered successfully, you will see two things on the device:
- Events in the Code Integrity log, at Event Viewer/Applications and Services Log/Microsoft/Windows/CodeIntegrity/Operational
- The policy file in the C:\Windows\System32\CodeIntegrity folder.
Windows will handle the policy format (single or multiple) automatically. If the policy is in single policy format, the binary will be copied to the CodeIntegrity folder and called SIPolicy.p7b.
If it is in multiple policy format, the binary will be copied to the C:\Windows\System32\CodeIntegrity\CiPolicies\Active folder. It will be named with the GUID of the policy, with a CIP file extension.
Next: WDAC and File Path Rules. How to create a File Path Rule.