My very first challenge – which was in my modest opinion the hardest part – with Enterprise Data Protection (EDP) was defining protected applications in a correct way. Many of you including myself were struggling how to define restricted applications.
In a serie blog posts I will provide some guidance how EDP works and how to configure protected apps, Configuration Manager and Microsoft Intune.
- Part 1 – Introduction: Enterprise Data Protection – Under the hood
- Part 2 – Retrieve Desktop & Universal Application Information with PowerShell
- Part 3 – Create & Deploy Enterprise Data Protection with System Center Configuration Manager Current Branch (1511)
- Part 4 – Create & Deploy Enterprise Data Protection with Microsoft Intune
- Part 5 – Enterprise Data Protection & Azure RMS better together
In this blog I’ll explain how you can retrieve the mandatory information required in order to define protected applications for your Enterprise Data Protection policies.
Restricted apps also known as privileged apps, are allowed to access your enterprise data and will react differently with other non-privileged or personal apps. For example, if your EDP protection mode is set to block, your privileged apps will let the user copy and paste information between other privileged apps, but not with personal apps. With EDP you can both define desktop and universal applications as protected application to access your enterprise data.
As mentioned in my first blog post EDP is using Encrypted File System (EFS) and AppLocker as foundation to protect documents and restrict applications to modify enterprise data. Here is where AppLocker Cmdlets comes around the corner. Although you can configure and retrieve AppLocker information through the GUI (gpmc.msc or gpedit.msc) we rather prefer AppLocker PowerShell Cmdlets.
This is the most basic cmdlet in the AppLocker family. It provides the very simple (yet powerful) functionality of looking through a list of files, folders or event log entries and extracting the information relevant to AppLocker e.g. for each executable(s) in a folder, it can retrieve the corresponding publisher, path and hash information etc. which.
In order to define privileged applications in both Configuration Manager Current Branch (1511) and Microsoft Intune we require the following information:
- Publisher (Desktop & Universal)
- Product Name (Desktop & Universal)
- File Name (Desktop)
- Version (Desktop)
Get-AppLockerFileInformation -Directory “<path>” -FileType “<APPX, DLL, EXE, Script, WindowsInstaller>” -Recurse
The “Recurse” flag tells the cmdlet to dive in to each sub-folder of Office16 while the FileType enum indicates that only Executable (as opposed to scripts, MSIs etc.) should be looked at. In the example, we piped the output to out-gridview to provide an easier visualization of the Office 2016 file information retrieved.
Using the following PowerShell one-liner will provide us all exe file extensions of Office 2016 installed on your machine. In this example we’ll use Excel 2016 to define as privileged desktop application.
Get-AppLockerFileInformation -Directory “C:\Program Files (x86)\Microsoft Office\root\Office16\” -Recurse -FileType exe | fl
Get-AppLockerFileInformation -Directory “C:\Program Files (x86)\Microsoft Office\root\Office16\” -Recurse -FileType exe | Out-GridView
In order to retrieve universal application information we can use the same AppLocker PowerShell cmdlet however some folder cannot be searched. To overcome this we’ll use Get-AppxPackage PowerShell cmdlet.
Using the following PowerShell one-liner will provide us all universal applications installed on your machine. In this example we’ll use Microsoft Edge to define as privileged universal application.
Get-AppxPackage | Out-GridView
Using PowerShell Cmdlets you’re able to retrieve file information for both desktop (traditional) and universal applications in order to define EDP policies. In my next blog post I’ll cover the ‘easy’ part how to set up and deploy Enterprise Data Protection policies with both Microsoft Intune and Configuration Manager Current Branch (1511).