When we talk about the Modern Workplace, employee experience is the priority. But there’s another aspect to this: information protection, which is of the utmost importance to any organization.
Every organization tries its best to keep its data protected. Sometimes, protection can be highly restrictive to the point that it hampers workplace experience, causing employee discontent, whereas sometimes, it can be too light, leaving many security loopholes.
As such, IT Admins and security Admins have to make tough decisions to balance the two extremes since this directly impacts an employee’s workplace experience.
Microsoft, being one of the top public cloud service providers, has several products/services in the space of Information Protection, each having its own area or purpose (with some overlaps in a few cases), namely
- O365 Information Protection (DLP) helps identify sensitive information across O365 (EXO, SPO, Teams) and prevents sharing, monitors, and protects sensitive information in desktop versions of Office apps.
- Azure Information Protection (previously Azure RMS) helps to classify and protect data by applying labels. Protection is applied directly to content and roams with it as it moves between locations.
- Windows Information Protection – helps to protect local data at rest on endpoint devices and manages apps to protect local data in use.
- Microsoft Cloud App Security – a Cloud Access Security Broker (CASB) solution that allows you to discover (on-prem or in-cloud) and monitor data in first-party and third-party Software-as-a-Service (SaaS) apps.
To simplify the offerings, Microsoft brought all the above solutions under the unified umbrella of Microsoft Information Protection (MIP)—a complete unified solution to protect sensitive data inside and outside the organization throughout its lifecycle.
Today, however, we will not discuss all the different solutions that make up MIP but instead will focus on one of its components—Windows Information Protection (WIP)—and how it helps to control data in your Windows environment.
Let’s get started.
Windows Information Protection
WIP predominantly helps in data segregation or separation, identifying and marking corporate data from user personal data residing locally on the device. Data marked as corporate is subjected to protection. It also helps to manage apps on the device that work with those data to prevent accidental data leakage.
It’s an evolution of Enterprise Data Protection (EDP – the predecessor to WIP) but is not a complete DLP solution in itself (which it is not meant to be as well by design).
WIP is not impenetrable security, as a user with a fair amount of knowledge about the Windows registry can easily revert the EDP state to stop protection. However, by design, WIP was never meant to be impenetrable. It was always meant to be an accidental data leakage prevention mechanism.
WIP has been available with Windows 10 since v1607 (Business Editions—Pro and Enterprise SKU). It works in the background and does not interfere with the user’s working habits—unless the user tries to mix and match work and personal context.
For example, WIP will allow users to freely copy content between business apps and documents, but it won’t allow the corporate data to be copied to an app working with personal data unless otherwise specified by the policy.
You would require either Intune (any MDM solution) or its on-prem counterpart, SCCM, to manage and deploy WIP policy to the Windows endpoints. WIP can work in both MDM and non-MDM (MAM only) scenarios – the protection is targeted to user identity and not the device.
This is essentially where the Mobility (MDM and MAM) settings of Azure AD come into play.
The same can also be accessed/configured from within Intune by going to Device Enrollment > Windows Enrollment > Configure Automatic Enrollment
It is to be noted that this MDM and MAM scope affects the Windows platform’s auto-enrollment and, as such, should be planned properly.
NOTE: MAM scope takes precedence over MDM scope so for the conflicting users, auto-enrollment into MDM will fail.
The MDM/MAM scope has no effect on Android/iOS management.
WIP with Enrollment is via the MDM endpoint https://enrollment.manage.microsoft.com/
WIP Without Enrollment is via the MAM endpoint https://wip.mam.manage.microsoft.com/
During AAD Join/Registration, the response to the DRS Discovery request contains all the required endpoints that the device will connect to complete the process. This also includes the Device Management endpoint info. Based on the scope configured, either the device will get either of the above two or will not get any – if the scope is set to None for both MDM and MAM. For Hybrid AAD join (via AAD Connect), it is the SPN (AAD Connect setup provides GUI to set up SPN while configuring Hybrid AADJ), which aids the discovery of endpoints.
WIP – Understanding the concepts behind…
I have always stated that configuring a policy is not the real work of an IT Admin, but it is knowing the internals or behind-the-scenes mechanisms—what is the effect of configuring particular settings in a policy, how it gets implemented on an endpoint, and how it is supposed to work.
With the same aim of getting to know the internals, let us understand the primary action points. Windows Information Protection can roughly be related to the following functions
- File and buffer protection,
- Clipboard protection,
- Data protection under lock, and
- Protected access to network resources
With this information, let’s see how the settings in the WIP policy configuration we configure affect the end-user experience on an endpoint.
The most important part of the policy is to set the protection mode and define the identity.
Corporate Identity
WIP-protected data is tagged to the identity as defined here (generally, the default domain). This also helps to identify the context in which an app is running.
You will see a WIP-protected file always tagged to the corporate Identity as defined in the policy. Right-click and open the Properties > Advanced > Details to see the Enterprise Domain and the Protection status in detail.
The tagging happens when
- The creator decides to create data with corporate tagging
- Data downloaded to the device from any policy-defined Cloud Resource
For environments where Known Folder Redirection is configured and SharePoint is defined as a Cloud Resource in the WIP policy, data saved to such locations are automatically WIP protected and tagged to corp identity as essentially those locations are redirected to OneDrive for Business instead of local storage.
This identity is also tagged to applications (Enlightened/Unenlightened) to determine app execution context (if the application is being targeted by EDP) and can be checked from the Task Manager (need to enable the column for Enterprise Context)
Protection mode and the corresponding behavior
This setting decides the response to the event when a user tries to take data from a policy-defined app to an unknown app. This is the EDP enforcement level on an endpoint that decides if actions like
- changing file ownership from work tagged to personal
- copying data from a working app to a personal app
are allowed or not.
WIP EDP mode – Blocked
The actions highlighted above are not allowed and will be blocked.
When EDP is set to Blocked mode, you can change the file ownership of a personal file to work protected, but the reverse is not possible. The above shows that the File ownership options are greyed out for a work file.
WIP will block user actions that involve clipboard actions, such as copying data from a work file or app running in a work context to a personal file or app running in a personal context.
WIP EDP mode – Allow Override
The actions as highlighted are allowed, but the end-user is notified that the action involves work content.
In this mode, you can also change file ownership of work files to personal to remove WIP protection from the content. However, the actions are audited!
WIP EDP mode – Silent
If you are planning to deploy WIP in your modern managed Windows environment for the first time, it is always recommended to deploy the policy with EDP enforcement set to Silent (or Allow Override).
In this mode, no restrictions are implied, as users won’t even notice the presence of WIP on an endpoint. However, it continues to work silently in the background, auditing user activities and habits—applications the user uses to connect to corporate resources—essentially known as WIP Learning.
If your environment has a standard set of applications used in workplace devices, you can prepare a test system and check the EDP events to understand how to target the applications.
WIP Learning generates two report sets
- App Learning tracks apps that attempt to access work data, not in policy.
- Website Learning – shows website URLs that are accessed by WIP-enabled apps so you can decide which ones are corporate location or personal.
Based on the WIP learnings, you can fine-tune your WIP policy before switching the protection mode to Blocked. This will not suddenly affect the end-user experience and disrupt the workflow for BAU activities as you get to know the different applications your end users use to connect to corporate resources.
Application Targeting – Protected vs Exempt Apps
The decision to add an application to either of the categories (or not add the application at all) directly impacts its behavior. This is the time during policy configuration when you choose the applications that will be targeted by the policy.
When we talk about WIP, an application can be either
Enlightened (WIP-aware) Apps
The application can differentiate between personal and corporate data and apply the protection as enforced by the policy only to corporate data. These are mainly Microsoft applications developed by integrating the WIP APIs; the current list of apps is here.
When you create a WIP policy, all the Enlightened Apps are pre-generated as Recommended Apps in the Protected Apps section.
If you know an application is WIP Enlightened, you can add it to your WIP policy as a Protected App as you can be sure that the app will only apply for protection as enforced when the data in context is identified as corporate.
Unenlightened (WIP Unaware) Apps
The application cannot differentiate between personal and corporate data as it is unaware of the WIP APIs (not integrated into the source code). If targeted by WIP policy, the OS will enforce the application to treat all data being used as corporate and apply protection to it. LOB applications and most desktop applications by third-party vendors fall in this category.
For an Unenlightened App (3rd party apps and LOB apps), the decision to add it to Protected Apps or Exempt Apps is a bit tricky!
If you are sure that an Unenlightened app works only with corporate data, you can add it to the Protected Apps section on the policy. This will cause the app to enforce protection to every data that it will access or work with.
Scenario Example # Teams desktop client (Teams.exe) is an Unenlightened App but you can still add it to the Protected Apps section of your WIP policy to enforce protection on the app as a User will be using Teams for corporate communication purposes only and the data involved will also be corporate.
If an Unenlightened app may work with personal and corporate data, in such a scenario, if the app is added to the Protected Apps section of your WIP policy, either the app functionality might get affected or you will hamper the user experience. In such cases, it is advisable to add such apps to the Exempt Apps section instead so that the app can continue working with personal and corporate data. In this scenario, you essentially trade off security for user experience.
Scenario Example # Adobe Acrobat Reader is an Unenlightened application that helps to view PDF files. A user can use it to view personal PDF files as well as corporate PDF files. If you add this Unenlightened application to the Protected Apps section of your WIP policy, the application will enforce protection (encrypt file) even when a user opens a personal PDF file, which is undesirable. As such, you should add this kind of app to the Exempt Apps section instead.
What happens to the application on a WIP-enabled endpoint not in any policy app list (Protected or Exempt)?
The application works fine till it is confined to working with personal data, but if it tries to access a corporate file or a corporate network resource as defined in the WIP policy, it will return an access denied error (or may give other errors based on the error handling of the app)
Let’s consider Python as an example. I have two scripts—one is personal, and the other is WIP-protected and tagged to corporate identity.
Python is not added to either Protected App or Exempt App list of the enforced WIP policy – the context of Python instance when executed is Personal.
As such, when I try to execute the scripts, it will be able to execute script1.py, which is personal, but will get an error when executing script2.py, which is WIP protected, as it cannot open the file.
Whitelist applications from the policy – Publisher Info or AppLocker XML
Whitelisting applications in WIP allows the application to work with requested content (local data or network resource) protected by the enforced WIP policy.
This mostly concerns LOB and Unenlightened applications, which get blocked or give errors when WIP is enforced on an endpoint and the application is not listed in either the Protected or Exempt app list of the policy.
Again as I mentioned earlier, the decision to whitelist an app – add it to either the Protected or Exempt app list of the policy entirely depends on the fact how the application is intended for use. If the app usage is restricted to work purposes only, you can add it to the Protected app list, protection will be enforced on all app data. However, if the app usage is for both personal and workspace, you need to add it to the Exempt app list so as to avoid enforcing protection on personal files.
To add applications to your WIP policy, either under the Protected Apps or Exempt Apps section, you get 3 options to choose from
- Recommended Apps – Enlightened Apps and/or which MS recommends with all the information already available with Intune.
- Store Apps—Apps available from the Microsoft Store. Microsoft has well-documented the procedure for adding store apps here.
- Desktop Apps will mostly be your .EXE or .MSI applications, including the in-house LOB apps.
If the application is signed, you can add a Desktop App to your WIP policy by using the Publisher information. You can get the Publisher info of a signed application using the PS command Get-AppLockerFileInformation
However, in the case of LOB applications and many other third-party applications, you would not get the Publisher information from the app package. Notice in the snap below that the Publisher space is blank.
The recommended way to add such an application would be to create an AppLocker executable rule for the application using the File Hash method.
You can export the created rule as an XML file and import it to your WIP policy in Intune.
When you are creating an AppLocker executable rule for an application based on File Hash, be sure to add all the dependent .exe files that the application depends on for proper app functionality.
The downside to using the AppLocker executable rule based on File Hash is that if the app gets updated, its HASH will change, which will require re-whitelisting. This is not the case with a whitelist based on Publisher Info.
When whitelisting an app for WIP, a good rule is to check the Install location of the application to see if there is a single executable or multiple executables.
For multiple executables, it depends on how you create the app entry in WIP.
If Publisher Info is available, I recommend whitelisting such an app by filling out only the Publisher Information and leaving the rest to the “*” wildcard, which makes all the executables from the same Publisher trusted.
If you have created the entry with the Publisher and Product name, you would need to create individual entries for each individual dependent executable.
Sometimes, you might find that Publisher Info is unavailable for all the dependent executables.
In such case, use a combination of both Publisher Info to whitelist the majority of executables for which it is common, and for those where Publisher Info is not available, create an AppLocker XML File Hash rule.
Points to consider while you create an AppLocker executable rule for an unsigned application
- An AppLocker executable rule based on Path is not recommended as it poses a security concern—any application placed in that path will also be considered.
- Remember not to create default rules while you create an AppLocker executable rule for an unsigned app.
- Delete the created rule after exporting it as an XML before closing the Local Security Policy console. If you forget to delete the created rule and close the secpol console, your system will be good for nothing and will require a re-image.
Advanced Settings section…
This is where you define/configure the following settings
- Creating/Defining the
Cloud Resources - Creating/Defining additional
Protected Domains - Creating/Defining the
Network Boundaries - Uploading a
DRA certificatefor recovery of encrypted data - Configure to
Revoke encryptionon unenrollment - Show the enterprise data protection icon
- Configuring
Azure RMS(for integrating WIP with AIP) - Allow
Windows Searchindexer to index protected files
I will not go and describe all of these, as you can find all the information required for the above in the Microsoft documentation here.
However, it is important to remember to add the /*AppCompat*/ entry when you create any Cloud Resource.
Otherwise, any application not defined in the policy’s application list will be cut off from the internet connection, even though the endpoint has a perfectly working, active internet connection.
To be contd. in #part 2
I hope you now have a good understanding of the functionality of each set in the policy.
In the next post, part 2 of this article, I will give you a deeper insight into the internal workings of WIP—both at the app and Device levels. So stay tuned, as it will be followed by this article very soon.
If you liked reading this, there is a good chance you will like my other articles published here. If the topic matches your interest, give them a read. You will find them listed under my profile here.
Till then, as I say, keep reading and learning!
Resources
- How Windows Information Protection (WIP) protects a file that has a sensitivity label
- Protect your enterprise data using Windows Information Protection (WIP)
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com
having issue with 3rd party apps being blocked when Cloud resources are enabled. THis happens with zoom, putty, x2go, etc.
any idea why these are getting blocked even when i add them to protected app list, or exempt list, or just try to run.
THank you