Conditional access and apps that cannot be installed on the device

This week a relatively short blog post related to conditional access. More specifically, about the ability to create a compliance policy with an apps that cannot be installed list. Before starting, let’s start with the minor detail that this is a Microsoft Intune hybrid only configuration at this moment. Introduced in Configuration Manager 1702. I’ll start this post with a short introduction, followed by the required configurations. Including how to find the required information. I’ll end this post with the end-user experience on an iOS and Android device.

Introduction

Let’s start with a short introduction about the apps that cannot be installed list. The apps that cannot be installed list is an additional rule that can be configured as part of a compliance policy. When the end-user installs an app from the apps that cannot be installed list, the end-user will be blocked when trying to access corporate email and other corporate resources that support conditional access. The end-user will be blocked until the app is removed from the device. This rule requires the app name and the app ID when adding an app to the apps that cannot be installed list, defined by the admin. The app publisher can also be added, but it’s not required.

This rule is supported on iOS 6+, Android 4.0+ and Samsung KNOX Standard 4.0+.

Configuration

Now let’s walk through the steps to add an app to the apps that cannot be installed rule of a compliance policy. Let’s start by getting the required app ID, followed by the steps to use that information in a compliance policy.

Get app ID

First get the app ID, as it’s required information for the apps that cannot be installed rule. An app ID is the identifier that uniquely identifies the app within the Apple and Google application services. I’ll use the OWA app as an example.

Android

The app ID for Android can easily be found in the Google Play store URL that was used to browse to the app. As an example see the app ID for the OWA app in the following URL (bold): https://play.google.com/store/apps/details?id=com.microsoft.exchange.mowa&hl=en

iOS

The app ID for iOS is a bit more challenging. To find the app ID, follow the next steps.

1 Find the ID number in the iTunes store URL. As an example see the ID for the OWA app in the following URL (bold): https://itunes.apple.com/us/app/owa-for-ipad/id659524331?mt=8;
2 Open a web browser and navigate to the following URL, using the example ID of the OWA app: https://itunes.apple.com/lookup?id=659524331;
3 Download and open the 1.txt file;
4 1_txtIn the 1.txt file, search for the text bundleId. The value with the text is the app ID. With the OWA app example, the app ID is com.microsoft.exchange.mowa.

Configure compliance policy

After finding the app ID, it’s now time to use that information in a compliance policy. Below are the required steps for creating a compliance policy and adding the OWA app to the apps that cannot be installed list. After creating the compliance policy, simply deploy it like any other policy.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies;
2 Click Create Compliance Policy to open the Create Compliance Policy Wizard;
3 On the General page, provide a unique name, select Compliance rules for devices managed without the Configuration Manager client and click Next;
4 On the Supported Platforms page, select iPhone or/and iPad or/and Android or/and Android For Work and click Next;
5

IH_BlockedAppListOn the Rules page, click New to open the Add Rule dialog box. In the Add Rule dialog box, select Apps that cannot be installed and click Add to open the Add app to blocked application list dialog box. In the Add app to blocked application list dialog box, specify the Name and App ID of the app and click OK, OK, Next;

6 On the Summary page, click Next;
7 On the Completion page, click Close.

End-user experience

When the configuration is done, let’s have a look at the most important thing, the end-user experience. Below on the left is the end-user experience when connecting to corporate resource with conditional access enabled. This is a standard message for non-compliant devices. Below on the right is the additional information in the Company Portal app. In this case it will clearly show (at least on iOS) that the end-user must first uninstall the OWA app to get a compliant device. The first row is an iOS device, the second row is an Android device.

IMG_0107 IMG_0106
Screenshot_20170624-075046 Screenshot_20170624-074745

Note: From an administrator perspective, have a look at Monitoring > Overview > Deployments for a clear view of which end-users are non-compliant for the compliance policy.

Using the Desktop App Convertor to create a Windows app package

This week something completely different compared to the last few weeks, maybe even months. This week I’m going to create some awareness for the Desktop App Converter (DAC). DAC is a tool that can be used to bring desktop apps to the Universal Windows Platform (UWP) by using the Desktop Bridge. In this post I’ll start with a short introduction about the Desktop Bridge, followed by an introduction and the usage of DAC. I’ll end this post by providing some deployment considerations.

Desktop Bridge

Lets start with a short introduction about the Desktop Bridge.

desktop-bridge-4

The Desktop Bridge, also known as the Desktop to UWP bridge, is the infrastructure that is built into the platform that lets the administrator distribute Windows Forms, WPF, or Win32 desktop app or game efficiently by using a modern Windows app package.
This package gives the app an identity and with that identity, the desktop app has access to Windows Universal Platform (UWP) APIs. These UWP APIs can be used to light up modern and engaging experiences such as live tiles and notifications. Use simple conditional compilation and runtime checks to run UWP code only when the app runs on Windows 10. Aside from the code that is used to light up Windows 10 experiences, the app remains unchanged and the administrator can continue to distribute it to the existing Windows 7, Windows Vista, or Windows XP user base. On Windows 10, the app continues to run in full-trust user mode just like it’s doing today.

Desktop App Convertor

There are multiple methods available to create Windows app packages, from manual packaging (MakeAppx.exe) until using Visual Studio or third-party tooling. All of these are out of scope for this post. IIn this post ’m going to specifically look at using DAC.

Introduction

DAC can be used to bring desktop apps to the UWP. This includes Win32 apps and apps that are created by using .NET 4.6.1. While the term “Converter” appears in the name of this tool, it doesn’t actually convert the app. The app remains unchanged. However, this tool generates a Windows app package with a package identity and the ability to call a vast range of WinRT APIs. The converter runs the desktop installer in an isolated Windows environment by using a clean base image provided as part of the converter download. It captures any registry and file system I/O made by the desktop installer and packages it as part of the output. For an overview of the workflow, have a look the picture below.

DAC_Workflow

DAC can be very convenient in cases where the app makes lots of system modifications, or if there are any uncertainties about what the installer does. DAC also does a few extra things. Here are a few of them.

  • Automatically register preview handlers, thumbnail handlers, property handlers, firewall rules, URL flags;
  • Automatically register file type mappings that enable users to group files in File Explorer;
  • Register public COM servers;
  • Automatically sign the package so that it can be easily tested;
  • Validate the app against Desktop Bridge and Windows Store requirements.

Requirements

The goal of this post is to create a Windows app package by using DAC. However, before using DAC, make sure that the system meets the following requirements.

Setup environment

When the system meets the requirements, lets start with setting up the environment. To use DAC for packaging an app that uses an installer, use the following steps to install and set up DAC.

1 Download and install the Desktop App Convertor app;
2 Download the Desktop App Convertor base image that matches the current operating system (in my case I downloaded BaseImage-15063.wim to C:\Temp);
3 Right-click the Desktop App Convertor app and select Run as administrator to start the DesktopAppConvertor console window;
4 In the DesktopAppConvertor console window, set the PowerShell execution policy by using Set-ExecutionPolicy ByPass;
5

In the DesktopAppConvertor console window, set up the convertor by using DesktopAppConvertor.exe –Setup –BaseImage .C:\Temp\BaseImage-15063.wim –verbose

Note: Make sure to adjust the location and name of the base image when using a different location and/or version;

6 If needed, restart the computer.

Create Windows app package

After setting up the environment, lets start with converting an app. Well, as mentioned before, it’s not actually converting an app, it’s creating a Windows app package. That being said, to use DAC for creating a Windows app package that has a setup executable file, use the following steps.

1 Get the content available locally of the installer that must be converted (in my case I used KeePass-1.33-Setup.exe and placed it in C:\Temp);
2 Right-click the Desktop App Convertor app and select Run as administrator to start the DesktopAppConvertor console window;
3

In the DesktopAppConvertor console window, start the conversion by using DesktopAppConverter.exe -Installer C:\Temp\KeePass-1.33-Setup.exe -InstallerArguments “/SILENT” -Destination C:\Temp -PackageName “MyKeePass” -Publisher “CN=PTCLOUD” -Version 0.0.0.1 –MakeAppx –Sign –Verbose -Verify

Note: Make sure to adjust the parameters to reflect the information of the app and its location. Also, make sure to run a silent installation, as DAC needs to run the installer in unattended mode.


The parameters are used for the following purpose:

  • Installer: The path to the installer of the application;
  • InstallerArguments: The arguments to run the installer silently;.
  • Destination: The destination for the converter’s appx output;
  • PackageName: The name of the Windows app package;
  • Publisher: The publisher of the Windows app package;
  • Version: The version of the Windows app package;
  • MakeAppx: A switch that triggers the creation of the Windows app package;
  • Sign: A switch that triggers the signing of the Windows app package, with a generated certificate. This can be used for easily testing the created Windows app package;
  • Verify: A switch that triggers the verification of the Windows app package against the Desktop Bridge and Windows Store requirements.
4

Install_KeePassTest the application by installing the auto-generated.cer and simply double-clicking the created Windows app package (in my case MyKeePass.appx) and clicking Install.

Note: An alternative method is not signing the Windows app package and using the Add-AppxPackage cmdlet.

Result

After creating the Windows app package, lets have a look at the results. There many things to look at, but, for this post, the most interesting thing is the created report (VerifyReport.xml). That report will provide a quick overview of the results for the created Windows app package. Below is the report available for the created KeePass app, on the left, and the report for a created Notepad++ app, on the right. A successful check on the left and a failed check on the right. The KeePass app shows no issues with the the Desktop Bridge and Windows Store requirements, while the Notepad++ app shows an issues with administrative permissions. An easy first check for a new Windows app package.

CDAA_KeePass petervanderwoude.nl

Deployment considerations

Now that the Windows app package is created it’s time to think about deploying the Windows app package. The most logical options are publishing the Windows app package to the Windows Store and using deployment tooling to distribute the Windows app package. The Windows Store can be used in combination with the Windows Store for Business and the deployment tooling can be one of my favorites, Microsoft Intune or Configuration Manager.

For publishing the Windows app package to the Windows Store, use this form to start the onboarding process. For distributing the Windows app package via Microsoft Intune and Configuration Manager, it’s important to sign the Windows app package. The used certificate must be of a trusted vendor, or must be installed in the trusted root/ trusted people certificate store.

More information

For more information about de Desktop Bridge and the Desktop App Convertor, please refer:

Windows 10, MAM-WE and Office desktop apps

The last couple of weeks I did blog posts about the configuration and the end-user experience of Windows 10 and MAM-WE. One of the most common questions I received was, “what about the Office desktops apps?”. In this blog post I’ll provide the steps to get the required information about the Office desktop apps, for usage within MAM-WE app policies (or any other WIP-related policies). I’ll also show how to use that information in the MAM-WE app policy and I’ll show the end-user experience. Including some of the current challenges with the end-user experience.

Important: Keep in mind that the Office desktop apps are not yet mentioned on the list of enlightened Microsoft apps for use with WIP (see this article). That could mean that the apps might behave different than expected. As my end-user experience section will show, make sure to test carefully before implementing.

Get Office desktop information

Lets start by getting the required information about the Office desktop apps. These methods are the same for every desktop app that must be configured with any WIP-related policy. There are two methods available, the first method is using the Get-AppLockerFileInformation cmdlet, and the second method is using the Local Security Policy editor to create an AppLocker configuration XML file. I’ll use the PowerShell method in this post. Simply using the mentioned cmdlet, as shown below, provides the information that is needed for adding desktop apps to the MAM-WE app policy,

(Get-AppLockerFileInformation -Path “C:\Program Files\Microsoft Office\root\Office16\excel.exe”).Publisher

For the most common Office desktop apps, version 1609, this results in the following information.

PublisherName ProductName BinaryName BinaryVersion
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 EXCEL.EXE 16.0.7369.2130
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 OUTLOOK.EXE 16.0.7369.2130
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 POWERPNT.EXE 16.0.7369.2130
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 WINWORD.EXE 16.0.7369.2130

Add Office desktop information

The next step is to add the Office desktop app information, to the MAM-WE app policy. For the step-by-step activities, please refer to my post about configuring MAM-WE app policies for Windows 10. Here I’ll only show the required actions for adding the Office desktop app information to a MAM-WE app policy. The following steps go through adding the Office desktop apps to an existing Windows 10 MAM-WE app policy.

1 Open the Azure portal and navigate to Intune mobile application management;
2 Select App policy to open the App policy blade;
3 On the App policy blade, select the [Windows 10 MAM-WE app policy] to open the [Windows 10 MAM-WE app policy] blade;
4 On the [Windows 10 MAM-WE app policy] blade, select Allowed apps to open the Allowed apps blade;
5

On the Allowed apps blade, click Add apps to open the Add apps blade. On the Add apps blade, select Desktop apps. On the Desktop apps blade, provide the following information and click OK to return to the Allowed apps blade.

  • NAME: Provide a name for the desktop app;
  • PUBLISHER: Provide the PublsherName of the Get-AppLockerFileInformation cmdlet;
  • PRODUCT NAME: Provide the ProductName of the Get-AppLockerFileInformation cmdlet
  • FILE: Provide the BinaryName of the Get-AppLockerFileInformation cmdlet
  • MIN VERSION: (Optional) Provide a minimum version of desktop app. This can be used to, for example, make sure that at least a version is used that’s WIP enlightened;
  • MAX VERSION: (Optional) Provide a maximum version of desktop app.

MAMWE_AddOffice

6

Back on the Allowed apps blade, click Save to save the adjustments.

Note: At this moment the Allowed apps blade will show the same NAME as the PRODUCT NAME for manually added apps.

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll show the end-user experience by opening a work document. The first action is to open a work document via Word Online. Once opened I’ll select Edit Document > Edit in Word. This provides me with the question “How do you want to open this?”, as shown below on the left. It doesn’t mention that Word 2016 opens work and personal files, but I can open the document with Word 2016. Once opened, I’m still able to copy content to non-managed apps. When I choose Word Mobile, I’m not able to copy content to non-managed apps.

The second action is to download a work document from SharePoint Online. Once downloaded I select Open with. This provides me with the question “How do you want to open this work file?”, as shown below on the right. It correctly shows that Word 2016 opens work and personal files. However, again I’m still able to copy content to non-managed apps. When I choose Word Mobile, I’m not able to copy content to non-managed apps.

MAMWE_OfficeWord1 MAMWE_OfficeWord2

This clearly shows that this configuration enables the end-user to use Office desktop apps for work data. However, at this moment, it also clearly shows that it provides the end-user with more options on work data than the company might like.

More information

For more information about enlightened apps and Microsoft apps, please refer to:

Windows 10 and MAM-WE – Part 2: End-user experience

This week part 2 of my blog post about Windows 10 and MAM-WE. Last week it was about the configuration, this week it’s about the end-user experience. I’ll start this post with a short introduction about the settings that are configured for the end-user experience in this post. After that I’ll show the end-user experience with the enrollment, with accessing data and after enrollment.

Introduction

As I explained last week, there are a few Important settings that should be considered. The end-user experience shown throughout this post is based on the following configuration:

  • Allowed apps: Microsoft Edge, PowerPoint Mobile, Excel Mobile, Word Mobile, IE11, Microsoft Remote Desktop, Microsoft Paint, Microsoft OneDrive, Notepad;
  • Required settings:
    • Windows Information Protection mode: Allow Overrides;
  • Advanced settings:
    • Network boundary: All Microsoft cloud services;
    • Revoke encryption keys on unenroll: On;
    • Show the enterprise data protection icon: On.

Enroll device

Now let’s start with the end-user experience for enrolling the Windows 10 device. Keep in mind that the end-user must be Microsoft Intune licensed and must be using at least Windows 10, version 1703. The en-user can now navigate to Settings > Accounts > Access work or school and click Connect (see below on the left). This will start the enrollment experience that is similar to a normal MDM enrollment. The difference is in the background process. Once MAM enrollment is enabled, Windows 10, version 1703, will enroll the device for MAM. After enrollment this can be verified by selecting the work or school account and by clicking Info. This will show the information about the Management Server Address that points to the MAM check-in URL (see below on the right).

MAMWE_Enrollment1 MAMWE_Enrollment2

Note: After enrolling the device, an administrative user can find an additional device for the end-user in Azure AD. That device has the Trust Type attribute set to Workplace and the Managed By attribute set to None.

Access cloud work data

After enrolling the device it’s possible to connect to the configured Microsoft cloud services, like SharePoint Online. With and without conditional access configured. Browsing to SharePoint  Online will show the enterprise data protection icon, the briefcase, next to the URL (see below on the top). When clicking on the enterprise data protection icon, a message will show indicating that the website is managed (see below on the bottom).

petervanderwoude.nl
petervanderwoude.nl

Access local work data

When connecting to the configured Microsoft cloud services, like SharePoint Online, it’s also possible to download data, like documents. The downloaded documents will be marked as work data. The fact that it’s work data, ensures that the documents are encrypted. The work data can be recognized by the enterprise data protection icon, the briefcase, and by the File ownership. The File ownership will be set to the company (see below on the left). Work data can only be opened with managed apps. A clear example will show when using Open with > Choose another app. That will show the programs that can be used to open the document, including information about if the program can open work or personal files (see below on the right).

MAMWE_Local1 MAMWE_Local2

Copy work data

Now that it’s possible to open work data, it’s good to have a look at the behavior with copying content. In this case, opening work data, like a document, in Word Online (as shown below on the left) and Word Mobile (as shown below on the right).

MAMWE_WordOnline MAMWE_WordMobile

When copying content to an unmanged app, like WordPad, the end-user will be prompted for giving temporary access to use work content (as shown below). After clicking Give access, the content will be copied and the action will be logged.

MAMWE_Confirm

Note: Keep in mind that every activity related to accessing work data, is logged, in the Event Viewer, In the EDP-Audit-Regular log.

Switch owner

After enrolling the device it’s possible to switch the owner of local data. It’s even possible to switch the owner of the data, when selecting to download it. That enables the end-user to switch personal data to company data and company data to personal data (as shown below). When marked as work data, the data will be encrypted. When marked as personal data, the data will be unencrypted and free accessible.

MAMWE_Switch

Note: Keep in mind that every activity related to switching the owner of work data, is logged, in the Event Viewer, in the EDP-Audit-Regular log.

Unenroll device

Another important end-user action is unenrolling the device. With the current configuration this will revoke the encryption keys, which will revoke the end-user access to downloaded work data (as shown below on the left). It’s also really important to know that setting Revoke encryption keys on unenroll to Off will not revoke the end-user access to downloaded work data (as shown below on the right). The indication that it’s work data is still available, but the end-user has full access.

MAMWE_Unenroll1 MAMWE_Unenroll2

Note: Keep in mind that setting Revoke encryption keys on unenroll  to No, should only be used in specific scenarios. Using it in a normal production configuration will create major data leakage.