Application Error Post Implementing Intune WIP

Welcome to today’s topic – how to determine if reported application access denied error is due to Intune WIP policy and how to fix the same.

Do you have users complaining any existing application has stopped working post WIP enforcement?
How can you confirm if the reported application issue is due to WIP enforcement?
Are you confused about what method to use for app whitelisting – file hash, file path, or publisher information?

If you are having any of the queries in your mind, then this blog post is for you.

Table of Contents

Getting Started

When you have a user complaining that a particular app when trying to access a corporate resource is getting blocked post WIP enforcement on the system, what would you do as an Intune Admin?

You start checking by excluding the particular user/device from the WIP policy and doing a sync, and post this, if the applications works, it confirms that the application in context was getting blocked by WIP policy.

What would be the next step that you should do?

Use EDP-AppLearning Event To Determine if Application Error is because of Intune WIP

Head over to Event Viewer on the user system (if on the remote session, or you can ask the user to send it over) and check for EDP-AppLearning events to check for an entry that should match the application.

EDP-AppLearning Events shows you application information those are not explicitly allowed and thus gets blocked by WIP policy for trying to access corporate resources

Applications that are not explicitly allowed (whitelisted) in your WIP policy, when trying to work with WIP protected resources (that you define in the policy) will get blocked and there will be an event for each such attempt here.

When I say explicitly allowed, I mean they are simply not added to the WIP policy in either the Protected apps or Exempt apps section.

If you flip over to see the Details tab of the captured Event, you can see the Application in context which tried to access a corporate resource protected by WIP policy and got access denied error.

EDP-AppLearning WIP Event shows the blocked application details — EDP-AppLearning WIP Event shows the blocked application Publisher details (if available)

If the Application in context has Publisher information available, you can get that information from here with which you can add the app to the WIP policy as a Desktop app – either in Protected apps or Exempt apps based on your requirement.

Use PowerShell To Quickly Get Application Publisher Information

Initially, since you have already confirmed that WIP is the culprit by excluding the user/device from the policy and checking the app behavior, you can directly check if the application has Publisher information available using a one-line PowerShell command.

Get-AppLockerFileInformation -Path <Path to EXE>

Sample Example
==============
PS C:\Users\Joy>Get-AppLockerFileInformation -Path "C:\Users\a758430\Downloads\vlc-3.0.12-win64.exe"
  
Output
----------
Publisher:  O=VIDEOLAN, L=PARIS, C=FR\\,0.0.0.0
Hash: SHA256 0xEA4C3E0F5DDE814A0955C6167A723B40035A2B21DA38C51C6286BF9A7138BEAA

With this information in hand, you can add the app to the WIP policy – either in Protected apps or Exempt apps.

Till this, it’s good for applications having Publisher Information (means signed application packages). But…

What if Application Publisher information is Not Available?

EDP-AppLearning event details will show you the Path to the Executable that is getting blocked due to WIP policy, instead.

If App Publisher info is not present, EDP-AppLearning event will show you the file path for the executable that is being blocked by WIP.

If there is no Publisher Information available, PowerShell command Get-AppLockerFileInformation will give only the File Hash.

Sample Example
==============
PS C:\Users\Joy> Get-AppLockerFileInformation -Path "C:\Users\a758430\Downloads\7z1900-x64.exe"
  
Output
----------
Publisher:
Hash: SHA256 0x12C7635E53E70F626B5D6B7ECE26AC1CD92AF4ECDB86046F172BF89AD7B9A8C4

Note that the Publisher Information space is left blank. If you try to check if you can retrieve Publisher Information using AppLocker wizard [secpol.msc], you will get this error instead.

AppLocker wizard gives error when you try to create a Publisher based rule for an unsigned application

For such applications (mostly unsigned packages) you need to create an AppLocker rule and export the policy as an XML to be added to the Intune WIP policy.

Herein comes another decision point – AppLocker Rule can be created based on Publisher, File Path, and File Hash.

Since Publisher info is not available anyways, so out of File Hash and File Path, which one should you choose between the other two?

Why choose File Hash over File Path for creating AppLocker Rule?

If an application does not have Publisher information, recommended is to consider whitelisting based on its File Hash property instead.

This is because, even though File Path may seem to be more convenient, it has an inherent security risk associated with it.

Any technical user (even with a standard account) can make it from the registry what path is whitelisted and can then put any (compromised!) application run from that path to work with protected resources.

However, whitelisting applications based on File Hash information, though more secure, has an inherent downside.

Since the File Hash value will change with an update to the app package, every new version of the application will require creating a new  AppLocker policy for that particular version for WIP whitelisting.

Creating AppLocker Policy using Local Security Policy [secpol.msc]

If you have worked with AppLocker policies previously, this would be a piece of cake for you.

From Local Security Policy, on the left side pane, expand Application Control Policies to create a new Executable Rule.

Creating AppLocker Policy for Intune WIP to remediate Application Error Access Denied

Click on Next.

Creating AppLocker Policy for Intune WIP

Click on Next again.

Choose File Hash method and click on Next.

You can use Browse Files or Browse Folders option as applicable and select all the executable files related to the application.

Click on Create.

Click on No on the pop-up window.

Select No while creating AppLocker rule to not add default rules

The AppLocker rule is now created.

On the left window pane of the Local Security Policy window, right-click on the AppLocker node and select Export Policy. Save the XML policy file.

IMPORTANT
=========
Before closing the Local Security Policy [secpol.msc] window, make sure to delete the AppLocker rule that you just created. 

Since we omitted default rules while creating this rule, if you close the secpol window without deleting the rule, the system might get locked to a state where it will only allow running the app for which the rule is created. The only way to overcome this would require a reset/re-image.

Now that you have the AppLocker policy file exported as an XML file, comes the all-important question.

Where to add the Application in the WIP policy?

Decision To Add Application to Intune WIP Policy – Protected or Exempt App?

Where to add application Publisher Info or Applocker rule to the Intune WIP policy?

The decision of adding an application to either of the categories (or not adding the application at all?) directly impacts the application behavior working with WIP-protected resources.

If you know an application is WIP Enlightened, you can simply add it to your WIP policy as Protected App as you can be sure that the app will only apply protection as enforced when the data in context is identified as corporate.

For an Unenlightened App (3rd party apps and LOB apps), the decision to add it to Protected Apps or Exempt Apps is 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.

However, an Unenlightened app may work with both personal and corporate data, it is advisable to add such apps to the Exempt Apps section of the policy instead, so that the app can continue to work with both personal and corporate data

If such an app is added to the Protected Apps list of your WIP policy, either the app functionality might get affected or you will hamper the user experience. In this scenario, you essentially trade-off security for user experience.

Add Application AppLocker Information to WIP policy in Intune

For apps with Publisher Information available, you can add it as a Desktop App to the WIP policy, either Protected App or Exempt App list as explained above. You would need to fill up the details in the UI as below.

Name	Publisher	Product name	File	Min Version	Max Version	Action
Name to identify the app in WIP policy	Publisher details as obtained	*	*	*	*	Allow

I recommend whitelisting such applications by defining only the Name and Publisher column and leave the rest to wildcard [*] which makes all the executables from the same Publisher trusted.

The reason being, if the application is not constituted of a single EXE but multiple EXE files and all are required for the functioning of the application, then if you create the entry with Name, Publisher, and Product name defined, you would need to create individual entries for each individual executable file.

Also for an application that depends on multiple executables, it might not be the case that every of the dependent EXE will have the same Publisher information, or as I have seen, some might even be unsigned, meaning have no Publisher information available, even though as a whole, the main executable files of the application might be signed.

However, you might find this very rarely, and in such cases, you can choose to create a whitelist entry in the WIP policy using the Publisher info that is common to most of the executables, and for the rest, create AppLocker rule based on File Hash for the other dependent executables and add it to the WIP policy.

For apps without Publisher Information, you just import the AppLocker rule you created based on File Hash (XML export) for the application into the WIP policy, either into the Protected App or Exempt App list as explained above.

It’s Finally Wrap-Up

I have previously written 4 blog posts on Windows Information Protection, as such, if you would like to give them read, here are the links.

Some further MS documents that may help you in your journey with Windows Information Protection are given below.

That’s all for today.

If you are interested in Intune, you might want to give a read to my other posts. And if you like the content and want to receive email notifications for new posts on this blog, please SUBSCRIBE!