Microsoft Intune Windows Information Protection (WIP) for Windows 10 - Part I

In Part 1 of this series, we will look at data protection on Windows 10 BYOD devices (Without Enrollment - MAM Only)

We will work on Windows Information protection (WIP) that shipped with Microsoft Intune. This technology was previously known as Enterprise Data Protection (EDP) and available since the Intune classic portal and evolved over time. The technology helps us to secure data on Windows 10 machines with WIP policies. 

In this part will look at protecting Windows 10 workgroup device data by simply registering them with Azure AD. Registering a device with Azure AD is different from joining a device with Azure AD

If you are aware of WIP data encryption and interested in application blocking / whitelisting policies for Windows 10 through Intune, you can directly jump to Part II of this series.

Windows Information protection

Windows Information Protection (WIP) is an enhanced version of Microsoft EFS Technology to protect the unauthorized sharing of corporate data on Windows 10 machines. WIP is developed for BYOD scenarios to protect corporate data on workgroup computers. 

For WIP to work, we need to define a WIP Policy. The WIP Policy contains protected applications and protected location boundaries. WIP’s responsibility is to keep data encrypted within the boundary and warn / block users when they are trying to copy / share data to unprotected application / network location or unauthorized destinations. WIP also can put restrictions on application installation / execution through the Applocker OMA URI configuration.

For WIP policies to be made effective, Windows 10 machines must be either registered or joined to Azure active directory. The majority of Microsoft cloud-based applications do support WIP in addition to native Microsoft applications such as IE11, notepad etc.

The applications also have two types:

Enlighted Applications

Enlighted apps can differentiate between corporate and personal data and can determine if data need to be protected based on WIP policy configuration. They can restrict / warn any attempt to copy / paste / share encrypted data with non-corporate / non-protected apps or people. Ex: Office 365 App Suite

Unenlightened Applications

These apps are 3^rd party or custom applications and cannot differentiate between corporate and personal data and consider all data to be corporate, so they encrypt it by default. We may need to add an application compatibility switch in WIP policy, otherwise, they may not access corporate data. Ex: Google Chrome or Adobe Acrobat Reader.

WIP policy has two variants: With Enrollment and Without Enrollment - The term enrolment is nothing more than joining a Windows 10 device with Azure AD. The device can either join or register with Azure AD.

Policy with Enrollment (MDM with Enrollment)

This policy applies to Windows 10 machines which are Azure AD joined machines. This is just like AD domain join process. During the joining process, the Azure account used to join the machine to Azure AD gets added to machine local administrators group and one can log on to the machine with an Azure AD Account. 

Device joining allows us to get administrative control over a device and manage various device aspects such as factory reset, wipe out company data, restart, clean start, application installation and so on. Protected data becomes unused once a device is unenrolled from Azure AD. The WIP policy can block applications from executing / opening through the Applocker policy extension or can block unauthorized data sharing outside a defined policy boundary. 

Policy without Enrollment (MAM only – Without Enrollment)

MAM stands for "Mobile Application Management". This policy applies to Windows 10 machines which are Azure AD Registered. Users cannot log on to Azure AD registered machines with an Azure AD identity, but data encryption with protected applications do work on these machines. This policy cannot block application execution / installation on devices, but the policy can ensure that any user action sharing corporate data outside defined boundaries will be either blocked, logged or warned. Protected data becomes unused once a device is unenrolled from Azure AD. 

In this article our focus is on MAM enforcement on Windows 10 devices without enrollment (Without Device Management)

Prerequisites

• Windows 10 1703 and above (Pro / Enterprise / Education) editions
• Windows 10 machine with an open Internet is requested to avoid issues
• Custom domain verified and registered with Azure AD – We have already registered custom domain exchangelabs.in
• EMS licenses (At least Azure AD premium and Intune licenses)
• Intune must be enabled as MDM authority at the Azure tenant level
• Cloud only users or users synced to Azure AD from an on-premise active directory and licensed with EMS

Once the above prerequisites are satisfied, we can configure WIP policy to define protected apps and data encryption options. 

We have also created a group in Azure AD named WithoutEnrollment in advance and added Azure AD user accounts to that group.

This group will be mapped with WIP Policy so that policy will be applied to all group members.

Policy Configuration - MAM only – without device enrollment

The 1st step is to enable MAM URLs and finalize user scope.

In Azure portal, navigate to Azure active directory \ Mobility (MDM and MAM) and click on Microsoft Intune as shown above.

Click on Restore default MAM URLs, select All as the user scope and click Save

Once that's done, it's now time to configure a MAM only policy.

In Azure Portal, navigate to Microsoft Intune \ Client Apps \ App protection Policies and click Add a Policy

Give the Policy a suitable Name, select Windows 10 as the platform, select Without Enrollment as the enrollment state, click on Protected Apps, then click Add apps

Select Recommended Apps from the drop-down and select all apps and click OK. These applications are called protected apps and can create / access protected / encrypted data. This includes the majority of cloud apps from O365 family and Microsoft store.

You also can add Store Apps OR Desktop Apps from the drop-down list. 

To add example store app, add below details

Name: Microsoft Power BI
Publisher: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Product Name: Microsoft.MicrosoftPowerBIForWindows

The action should be allowed; it means this app is allowed to create / access protected data. Microsoft has provided online documentation on how to find required store app details

To add desktop apps, select Desktop Apps from the drop-down list and enter details as shown below.

File publisher and other details can be found with PowerShell cmdlets on Windows 10 machine.

Addition of custom apps through applocker Policy

We also can Import Apps by adding custom applications / locations if required. Open gpedit.msc on the Windows 10 machine and locate the applocker section as shown below.

Right-click Executable Rules and click Create New Rule

Click Next

Accept the default Allow for everyone and click Next

Select Path as the condition and click Next

Click Browse folders and select Program Files and click Next

Accept the defaults and click Next

Give an appropriate Name and click Create

We don't need a default rule to define protected locations, hence click No

In the same way, add the Windows folder as shown below. 

Also, we can add any other folder where custom applications are stored, native / custom applications under these folders may be enlighted or unenlightened. Apps will behave accordingly.

Now we need to export the policy in XML format so that it can be imported with WIP policy. Right-Click Applocker and click Export Policy

Export policy on Desktop as Pathrules.xml

If we open and view the XML file, it will look like below.

The resulting file is exported as is shown above. We need to remove any unwanted lines (RuleCollection Type NotConfigured) from the file, else Intune gives an error while importing. The resulting file should look as shown below.

<AppLockerPolicy Version="1">
    <RuleCollection Type="Exe" EnforcementMode="Enabled">
        <FilePathRule Id="ae3dc5c6-a929-4a3d-acaf-ca3629e3bfce" Name="Protected Folder - Program Files" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
            <Conditions>
                <FilePathCondition Path="%PROGRAMFILES%\*" />
            </Conditions>
       </FilePathRule>
       <FilePathRule Id="931fe08a-8b5c-4c6f-b991-e47303ac88d8" Name="Protected folder - Windows" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
            <Conditions>
                <FilePathCondition Path="%WINDIR%\*" />
            </Conditions>
       </FilePathRule>
    </RuleCollection>
</AppLockerPolicy>

Now, under Protected apps, click on Import Apps

Select the previously exported file "pathrules.xml" and click OK

The file has been added.

Now add any apps under Exempted Apps which are incompatible with WIP but necessary to access enterprise data. Exempt those apps from WIP protection. This means that your apps won't include auto-encryption or tagging and won't honor WIP restrictions, can access protected data and won’t protect enterprise data.

Configure the Required Settings and select WIP mode (Block \ Allow Override \ Silent \ Off  -  Block in our case)

The Block setting allows you to encrypt data by defining it as work data, but then encryption cannot be turned off for that data.

Add a custom domain or Azure native domain here as a corporate identity and click OK. Normally, a verified custom domain is automatically added here and no change is required.

Under advanced settings, add the various network boundaries such as Cloud resources, protected domains, network domains, IPv4 and IPv6 ranges, Internet proxy servers etc. The purpose of network boundaries is to keep enterprise data protected within boundaries.

By default, Azure defines SharePoint and OneDrive URLs as one boundary so that enterprise / corporate data access through one drive sync client SharePoint portal, remains protected.

We can add as many cloud URLs as we want as shown above. Also, we need to add /*AppCompat*/ in the above list, otherwise apps such as google chrome will not be able to access protected URLs.

Further, we may upload an EFS certificate to recover data in case required. The certificate needs to be uploaded initially. Details are provided in this Microsoft Article.

There are few other options such as revoking encryption keys when the device is unenrolled OR when the device is upgraded from MAM to MDM, using RMS templates, showing data protection icon on encrypted files etc.

WIP can integrate with Microsoft Azure Rights Management to enable secure sharing of files by using removable drives such as USB drives. 

To integrate Azure Rights Management with WIP, you must already have Azure Rights Management set up.

Now save the policy

Click on the Policy just created and navigate to assignments

Here, click on Select group to include and select WithoutEnrollment, the group which we created earlier.

If we look at group properties from Azure AD groups, there are a few users assigned as a member of this group.

These users will receive this MAM policy

Now its time to register the Windows 10 device with Azure active directory. Registering a device is different from joining a device to Azure AD.

*Register* Windows 10 version 1703 and above Professional / Enterprise / Education machine with Azure AD using the process below

On the Windows 10 workgroup machine, right-click start \ settings \ Access work or school and click Connect

Enter the username and click Next

Enter the password and click Sign in

Since Windows Hello for business is enabled in the same policy, the account will be subject to MFA verification. It will ask your location ISD code followed by Cell phone number if already not registered with Azure AD portal and then make a call / text on that number, please wait

Once MFA is successful, the wizard allows you to create a PIN

Set the PIN to comply with whatever policy has been set in Hello Business and click OK. This will allow currently logged on local users to log on to the machine with a PIN, in addition to using a password.

Click Done

Account now is visible under Access Work or school, click on account. 

Note - You can register to Azure AD with another method as well. If you have the latest Microsoft Office Suite software (Office 2016 / O365 / or any other product in O365 family), you can sign in from there and it also registers your machine to the Azure AD with the same effect.

Click Info

Scroll page a bit and then click on Sync. The sync completes successfully.

In the Azure portal, navigate to Intune \ Devices \ Azure AD devices and we should see the recently registered device.

The device hostname is PRO and the join type is Azure AD registered. MDM type is None (MAM Only) and the status is Enabled. The device compliance policy is not applicable for *registered* only devices.

If we click on Device, we can only enable / disable this device from the Azure portal and no other aspects can be managed. In fact, any change in WIP policy will be fetched by the client itself during startup logon or if synced manually.

Now its time to test how this policy will act on the machine

Now a locally logged on user would get a prompt for the PIN by default during log on. There is an option available to use a password as well.

Now with Enlighted applications (notepad in this case), you would get an option to save the file as a Work or Personal file, as soon as you save it as a work file, the file will get encrypted.

The document is encrypted now. You can see the briefcase icon along with a description at the top of the document and text file as well.

Now, if you tried to change file ownership from work to personal, it's not possible because we have set policy mode to Block. Block mode prevents decryption of data and also prevent data sharing to unauthorized \ non-protected destinations.

If you try to save it as personal, WIP will prevent it from saving as a personal document.

We can see that we don't have the option to set the document as Personal, hence it cannot be decrypted.

You also can right-click the file and click on File ownership and select Work (exchangelabs.in). The file becomes protected as shown below.

Go to file properties \ General \ Advanced and we can see the file is encrypted, click details

The file is encrypted by the protected Enterprise Domain

In the same way that you can protect files with enlighted applications such as WinWord, these applications are added as protected apps and can differentiate between personal and work data.

Further, any files uploaded / downloaded to / from protected apps will be automatically encrypted, for example, files uploaded / downloaded with one drive sync client or if we use Outlook thick client / webmail

In case of the Outlook web app, Select the attachment drop-down and click on Download.

Click Save

File Saved. Click Open folder

The file is encrypted automatically as it has been downloaded from a protected app

Further, we can download an attachment in OneDrive which is also a protected app and work with enterprise data only.

You can notice the briefcase icon on files stored in OneDrive.

You also can notice the Briefcase icon and managed by exchangelabs.in on the web page address bar since webmail URL is added under network boundary as a protected URL in WIP policy.

Likewise, if you try to share protected data with an unauthorized source, WIP will either block / warn / log the action depending upon the set policy setting. For example:

If you try to send an encrypted document through the Gmail web client, WIP will block / warn/ log this action depending upon set policy. Our policy is set to block such action, hence it is blocked.

The behaviour remains the same for all public email clients or any other 3rd party web email clients.

However, note that this data encryption is machine specific, meaning if you have success in copying / sharing encrypted data on another computer, encryption will be void and the recipient can access data. For example, if WIP policy is set to Allow Overrides, then WIP will warn you instead of blocking and you are allowed to share data to the external world if wanted to.

To demonstrate this functionality, 1st we need to change the WIP policy action from Block to Allow Overrides as shown below and save the changes.

Now we have set WIP policy from Block to Allow override, hence we can enable / disable file encryption from the right-click context menu (File Ownership). For example:

Setting file ownership to Personal will remove encryption. This is because of Allow Override mode set in policy.

Also, here in Gmail, I am attaching confidential data.

WIP warns me about work data. If I selected yes, an encrypted document will get attached and I can send it.

Now at the recipient end, the document will be received as unencrypted and I can download and open the document without any issue, this is by design.

What happens if we manually changed the file ownership to work? If the associated app is not supported for WIP or if it is not added as a protected app in WIP policy, documents become unusable. For example, Adobe Acrobat viewer is not added as a protected app.

Further, since Acrobat Reader or Google Chrome are unenlightened apps, if we define them as protected apps in WIP policy, the apps always open in protected / encrypted mode only because they cannot differentiate between personal and work data. For example:

Whenever you open the Acrobat Reader application, it will open in protected / encrypted mode by default and encrypts all data saved by it.

Even if you opened a non-protected pdf file with the application, it will automatically open in protected mode. If you save as a file, it will get encrypted.

If you Save as a file, it will get encrypted by force automatically as being an unenlightened application.

However, if the application is enlighted such as notepad, it can differentiate protected and non-protected data.

For example, if there is encrypted notepad document, notepad will show briefcase icon on that document.

However, if the document is not encrypted, the notepad application won't show a briefcase icon. For example:

Also while you save as a document, it will present you with both options (Work and Personal)

If we unenrolled the device from Azure, we have set a WIP policy to revoke encryption keys on the device upon unenrollment. This action will make all encrypted data on the device inaccessible regardless of where you move your data to. For example:

Recovery - WIP Protected files

If WIP protected data is inaccessible due to some reason such as unenrollment, or if the device lost its encryption keys, the process to recover this data is complicated until Windows 10 version 1703.

With Windows 10 version 1709 onwards, Microsoft has made provision that device encryption keys get automatically backed up with the Azure AD identity in Azure AD.

We can re-enroll the device with the same user again with MDM OR MAM only method, and the device will download data encryption keys automatically on the client machine and data should be accessible again without any issues

WIP policy (without enrollment) won't block application installation / execution on Windows 10 devices. This policy cannot directly control a BYOD device administratively but can protect unauthorised sharing / leakage of corporate data. The method is not 100% full proof and intruders still may find loopholes, but it's still pretty useful in BYOD scenarios.

In Part 2 of this series, we will focus on WIP Policy (With Enrollment) where we can administer BYOD devices along with application installation / execution restrictions in addition to data encryption.

I hope this article has been informative. If you found it useful, please click Thumbs-up icon below.