In this latest addition to the Keep it Simple with Intune series, I will implement Microsoft Defender Application Control policies to lock down the application estate to trusted apps.
What is Application Control
Microsoft Defender Application Control (MDAC) started off as Device Guard, then became Windows Defender Application Control and is now Microsoft Defender Application Control – try and keep up!
I wrote about MDAC back in the WDAC days for Adaptiva here’s the quote from that article at Simplifying Windows Defender Application Control with ConfigMgr & Intune
‘WDAC, allows you to control your Windows 10 devices by creating policies that define whether a specific driver or application can be executed on a device. Applications or drivers need to be specified as trustworthy, which reduces the threat of executable based malware significantly.
WDAC restricts application usage via a feature called configurable code integrity (CI). CI guarantees that only the trusted code runs from the boot loader onwards. It also hardens the operating system against kernel memory attacks using virtualization-based protection of code integrity (HVCI). WDAC works in-conjunction with Secure Boot, to ensure that boot binaries and the UEFI firmware are signed and have not been tampered with.
A common misconception is that WDAC is an AppLocker replacement. AppLocker also enables you to control which applications and files can run on your system. A key difference is that AppLocker does not offer the chain of trust, from the hardware to the kernel, that WDAC offers.
However, AppLocker can be used effectively to compliment WDAC, to allow the usage of different policies per user on the same device. As a best practice, Microsoft recommends that admins:
- Enforce WDAC at the most restrictive, least privilege level.
- Use AppLocker to granularly fine-tune the restrictions.’
The Intelligent Security Graph
When implementing MDAC, it will tap into the Intelligent Security Graph (ISG), which is Microsoft’s threat analytics data which helps to classify if an application has a good reputation. If there is no deny rule set for the application in the deployed configuration, then the classification data will be used to determine if the application has a good reputation or not.
It is recommended that MDAC is implemented in Audit mode initially to discover information about what will be impacted by turning on the feature. In this demo, I will not be running MDAC in Audit mode.
Here’s how we implement.
In the MEM Admin Center
In the MEM admin center, select Devices\Configuration profiles. Click the Create Profile link.
Enter a Name for the profile, select Windows 10 and later for the Platform and Endpoint Protection as the Profile type. Click Settings. Select Microsoft Defender Application Control from the categories
Turn on the policies, here’s where I can choose Audit Only or Enforce. I’ve selected the latter. Click OK.
By selecting to Enable for Trust apps with good reputation, I’m tapping into the ISG
If I select Not Configured then Only Windows components and Microsoft store apps will be allowed to run.
Once you have your desired settings in place, click OK a couple of times and then click Create to create the profile.
Your new configuration will appear in your list of profiles.
Next, choose Assignments and assign the profile out accordingly.
On the endpoints
Once the targeted devices have synced in, and the MDAC profile is applied, the devices will need to restart to enforce the MDAC configuration. Users will be given a 10 minute warning before their device is restarted and this cannot be stopped.
When attempting to install an application which is not deemed trustworthy by the ISG you’ll get a notification from Windows Installer to let you know that The system administrator has set policies to prevent this installation.
By implementing MDAC you can start to reduce the attack surface by allowing only reputable applications on your Windows devices.
This is a fairly simplistic approach to MDAC, however, and it recommended to read up on the feature as it requires a fair amount of planning and the ability to trust applications, particularly if they aren’t in the ISG. The Adaptiva document is a good starting point, but, as always, refer to the Microsoft documentation on the subject.
Be sure to take a look at the other blog posts in the series:
- #1 Enable password reset for users
- #2 Push out your customised Start Menu
- #3 Disk Encryption
- #4 Deploying a Win32 app
- #5 Intune session from Charlotte Systems Management User Group
- #6 Configure OneDrive and KFR
- #7 Deploying the Edge Browser
- #8 Introduction to Device Restrictions
- #9 Manually enrolling a Windows 10 device into Intune
- #10 Applying App Protection
- #11 Deploying a PowerShell script
- #12 Deploying Microsoft Edge Stable via the MEM Admin Center
- #13 Uninstalling Microsoft Edge Beta
- #14 Enabling Credential Guard on your endpoints
- #15 Managing Windows Updates
- #16 Intune session from West Michigan Systems Management User Group
- #17 Uninstalling Default Apps using the Store for Business
SCCMentor - Paul Winstanley 
Hi Paul, we are trying to implement this in our environment, we dont use sccm and from what I’ve found we can deploy without it – hence your kis implementing mdac article.
I am having errors deploying to a test laptop that’s hybrid azure ad joined and intune compliant, after some research it seems that only Win10 Enterprise and Education are compatible with MDAC, can you tell me what version of Win10 you tested with?
Thanks!
I can’t remember which edition I used but according to the docs – WDAC policies can be applied to devices running any edition of Windows 10 or Windows Server 2016 and above via a Mobile Device Management (MDM) solution like Intune, a management interface like Configuration Manager, or a script host like PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 Enterprise edition or Windows Server 2016 and above, but cannot deploy policies to devices running non-Enterprise SKUs of Windows 10 https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview. Cheers Paul
Hi Paul. I’m currently implementing MDAC using the oma-uri deployment approach in Intune (to prevent the 10 minute reboot during autopilot that the endpoint protection profile sets). I’m using an unsigned policy however it’s restricting MSI and PowerShell scripts from running, even when I add file path allow rules into the XML file. Any tips?
Seems after deploying MDAC policies my apps deployed from Intune are also not getting installed nor I am able to perform a remote wipe on my machine.
Could you please guide why MDAC policies impacting the intune deployments
I would recommend logging that with Microsoft, Ravi.