If you have evaluated WDAC as binary control based on signer rules, you know you have to adjust the policy every time a new application should be allowed. To make this process easier and more reliable, I wanted a fully automated process based on Azure DevOPs to create the policy and deploy it to a group of test devices.
Azure DevOps project
Let’s start with creating the DevOps project, if you already have one from part 1 or 2, you can use this as well. I’m assuming you already have a DevOps organization, if not check out the official docs to create one, as it’s pretty simple: Create an organization – Azure DevOps | Microsoft Learn. Once we have the Organization, we can create the new project and give it a speaking name:
Once we have the project set up, we can set up a new Repo, that we will use for our WDAC Policy deployment.
DevOps Service Connection
Next thing, that we need to create is a Service Connection to get the needed permissions to use Graph API to get our configs from Intune. We are going to use “Azure Resource Manager”:
And then select “Workload Identity federation (automatic):
Finally, we can select a Resource group in an Azure Subscription of our choice.
For now, we are not actually using resources in this subscription, but we are using this connection to grant it API permissions directly, that we are going to use.
Once we found the App registration for our newly created Service Connection, we can assign the needed API permissions.
We need read/write permissions for device configurations to update the WDAC Policy in Intune. Also make sure to grant admin consent for your org.
Intune
Before we can build our Azure DevOps Pipeline, we need to create the base configurations profile in Intune. We will need to use a Custom OMA-URI Template.
Next, we need to give it a name, I will use “Pilot WDAC Ruleset” since I would not recommend to directly use it as a productive policy.
No need to set any settings, since they will be published automatically via the DevOps Pipeline later. I just assigned the now still empty policy to a group of test devices that should receive the WDAC Policy directly.
Now we just have to copy the Policy ID from the URL, since we will need it later in out script:
DevOps Pipeline
For our Pipeline to work, we have to allow the Build Service to contribute to our repo. We can do this in the project settings, under repositories:
Now that the prerequisites are all done, we can upload the content from my GitHub Repo: https://github.com/mmeierm/Scripts/tree/main/ConfigAsACode/WDAC into our WDAC Repo:
Next thing we need to do, is to add our previously noted Intune Policy ID to the “Intune_WDAC_Upload.ps1” Script in line 3:
Once this is done, we can create the new Pipeline itself:
We will select existing Pipeline and select the “WDAC Build Pipeline.yml” file.
Once the Pipeline is created, you can review the code and modify the git config to match you needs (Name / mail address)
When you run the pipeline for the first time, you may need to grant it permission to the Agent Pool and the Service Configuration:
If everything went well, you should see the first successful run of the Pipeline:
And see that our Intune Policy has been updated to now contain our freshly created WDAC Policy:
How to use?
Basically, you can initially modify the BasePolicy.xml File to match your requirements. I used the “Allow Microsoft” Template from WDAC Wizard and use the following options for the demo:
You obviously can change everything to your needs. Once you are happy with the base policy, we can now simply upload signer certificates in a sperate folder per Application, here as example for Notepad++:
First get the signer certificated of the file that you want to allow to run:
Export the certificate:
And upload it to Folder for the App in the Active section:
After the Pipeline ran and updated the Policy in Intune, we can now see on our test device, that Notepad++ is now allowed to run, while all other Apps are still blocked:
Conclusion
In my opinion automating the creation of WDAC Policies make the whole process so much easier and also allow you to see what changed between two versions of policies easier, especially when working in bigger teams, where multiple people make changes on the policy.
Leave a Reply