Controlling Microsoft Passport for Work on Windows 10 via OMA-DM

This week another blog post about Windows 10 and OMA-DM. However, this time it might not be that obvious. In this post I’ll go through the configuration of enabling the provisioning of Microsoft Passport for Work on Windows 10 devices. Maybe even more important, I’ll go through the PassportForWork configuration service provider (CSP) that is used to provision that configuration.

During this blog post I’ll go through the PassportForWork CSP, the configuration steps in Microsoft Intune hybrid and standalone and the end-user experience.

PassportForWork CSP

Before starting with the configuration of enabling the provisioning of Microsoft Passport for Work on Windows 10 devices, it’s good to get a better understanding  of what is actually used to get the configuration in place. The configuration through Microsoft Intune hybrid and standalone uses the PassportForWork CSP. That CSP is used to provision Microsoft Passport for Work, which allows the end-user to login to Windows using the AD, or Azure AD, account and replace passwords, smartcards, and virtual smart cards for that specific device. Microsoft Passport for Work lets the end-user use a user gesture to login, instead of a password. A user gesture can be a simple PIN, biometric authentication, or an external device.

Below is an overview of the nodes of the PassportForWork CSP. I won’t go through the nodes in detail, as that information will come during the configuration, but make sure to switch back a couple of times to connect the configuration with the CSP.

User configuration Device configuration
UserConfigDiagram DeviceConfigDiagram

Configuration

Now it’s time to start with the configuration of enabling the provisioning of Microsoft Passport for Work on Windows 10 devices. I’ll walk through the configuration steps for Microsoft Intune hybrid and standalone and I’ll provide the configuration options. While going through the configuration options, please make sure to switch back to the PassportForWork CSP a few times and connect the configuration options with the CSP nodes.

Microsoft Intune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to configure Microsoft Passport for Work for enrolled Windows 10 devices.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Cloud Services > Microsoft Intune Subscriptions;
2 Select Microsoft Intune Subscription and on the Home tab, click Configure Platforms > Windows to open the Microsoft Intune Subscription Properties;
3

On the Passport for Work tab, select Enable Passport for Work for enrolled devices, configure the following required settings and click OK;

  • MIHybrid_PropertiesUse a Trusted Platform Module (TPM): Select [Required] or [Preferred] to require or prefer the use of TPM. If TPM is preferred and not available, software encryption is used;
  • Require minimum PIN length: [Specify a minimum PIN length of at least 4 characters];
  • Require maximum PIN length: [Specify a maximum PIN length of up to 127 characters];
  • Require upper-case letters in PIN: Select [Not allowed] or [Required] to specify whether uppercase letters should be used or not;
  • Require lower-case letters in PIN: Select [Not allowed] or [Required] to specify whether lowercase letters should be used or not;
  • Require special characters: Select [Not allowed] or [Required] to specify whether special characters should be used or not;
  • Require PIN expiration: If enabled, [Specify a number of days before PIN must be changed];
  • Prevent reuse of previous PINs: If enabled, [Specify a number of previous PINs that are restricted from reuse];
  • Enable biometric gestures: Select [Yes] or [No] to enable biometric gestures for authentication. If enabled, end-users must still configure PIN in case biometric authentication fails;
  • Use enhanced anti-spoofing, when available: Select [Not configured], [Yes] or [No] to enable the support for anti-spoofing, when available;
  • Use Remote Passport: Select [Yes] or [No] to enable the support for remote passport for Azure AD joined devices or not.

Microsoft Intune standalone

Let’s continue with the same configuration within Microsoft Intune standalone. I’ll walk through the required steps to configure Microsoft Passport for Work for enrolled Windows 10 devices.

1 In the Microsoft Intune administration console, navigate to ADMIN > Mobile Device Management > Windows > Passport for Work;
2

On the Passport for Work page, select Enable Passport for Work on enrolled devices, configure the following required settings and click Save;

  • MIStandalone_PropertiesUse a Trusted Platform Module (TPM): Select [Required] or [Preferred] to require or prefer the use of TPM. If TPM is preferred and not available, software encryption is used;
  • Require minimum PIN length: [Specify a minimum PIN length of at least 4 characters];
  • Require maximum PIN length: [Specify a maximum PIN length of up to 127 characters];
  • Require lowercase letters in PIN: Select [Not allowed], [Allowed] or [Required] to specify whether lowercase letters should be used or not;
  • Require uppercase letters in PIN: Select [Not allowed], [Allowed] or [Required] to specify whether uppercase letters should be used or not;
  • Require special characters: Select [Not allowed], [Allowed] or [Required] to specify whether special characters should be used or not;
  • PIN expiration (days): If enabled, [Specify a number of days before PIN must be changed];
  • Remember PIN history: If enabled, [Specify a number of previous PINs that are restricted from reuse];
  • Enable biometric gestures: Select [Yes] or [No] to enable biometric gestures for authentication. If enabled, end-users must still configure PIN in case biometric authentication fails;
  • Use enhanced anti-spoofing, when available: Select [Not configured], [Yes] or [No] to enable the support for anti-spoofing, when available;
  • Use Remote Passport: Select [Yes] or [No] to enable the support for remote passport for Azure AD joined devices or not.

End-user experience

Let’s end this post with the most important thing, the end-user experience. After the device is registered in Azure AD and enrolled into Microsoft Intune hybrid, or standalone, Microsoft Passport for Work will be provisioned for the end-user. On a fresh device the end-user will be prompted to set up a PIN during the initial logon. A successful configuration will be logged in the User Device Registration node in the Event Viewer with Event ID 300.

End-user experience Event Viewer
PINConfig PINConfig_EV

More information

Fore more information about Microsoft Passport for Work on Windows 10 and the PassportForWork CSP, please refer to:

Setting up kiosk mode on Windows 10 via OMA-DM

A while ago I did a blog post about managing AppLocker on Windows 10 via OMA-DM. During that post I showed how to use OMA-DM, via Microsoft Intune hybrid and standalone, to configure AppLocker. In this post I’ll do something similar for setting up kiosk mode on Windows 10. Windows 10 Enterprise and Windows 10 Education provide a configuration service provider (CSP) for setting up kiosk mode. That’s the AssignedAccess CSP.

During this blog post I’ll go through the AssignedAccess CSP, and its required input, I’ll go through the configuration steps in Microsoft Intune hybrid and standalone and I’ll show the end-user experience with the Twitter app as an example.

AssignedAccess CSP

Before using the AssignedAccess CSP it’s good to get a better understanding  of the CSP. The CSP is used to set up the Windows 10 device to run in kiosk mode. Once the CSP has been executed, then the next user login, that is associated with the kiosk mode, puts the Windows 10 device in the kiosk mode running the specified application. Let’s go through the nodes of the AssignedAccess CSP.

  • AA_CSP./Vendor/MSFT/AssignedAccess– Defines the root node for the AssignedAccess configuration service provider;
  • ApplicationLaunchRestrictions – Defines a JSON string that contains the user account name and the Application User Model ID (AUMID) of the Kiosk mode app
    • The JSON string should look like the following example: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    • The account name can be a domain account as well as a local account. When a local account is used, the domain name should be the name of the device;
    • The Application User Model ID (AUMID) can be easily received through PowerShell. The following example can help with collecting the information:
      foreach ($App in (Get-AppxPackage)) { foreach ($Id in (Get-AppxPackageManifest $App).package.applications.application.id) { Write-Output ($App.packagefamilyname + "!" + $Id) } }

Configuration

Now it’s time to use the AssignedAccess CSP to set up Windows 10 devices in kiosk mode. In this configuration I’m going to use the Twitter app as an example for my domain user account and I’m going to show the required configuration for Microsoft Intune standalone and hybrid.

Microsoft Intune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to configure the required Configuration Item.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Items;
2 On the Home tab, click Create Configuration Item to open the Create Configuration Item Wizard;
3

On the General page, specify the following information and click Next;

  • Name: [Specify a unique name for the configuration item]
  • Description: [Specify details that help identifying the configuration item]
  • Select Windows 8.1 and Windows 10 with Settings for devices managed without the Configuration Manager client.
4

On the Supported Platforms page, select the following platforms and click Next;

  • All Windows 10 (64-bit)
  • All Windows 10 (32-bit)
5 On the Device Settings page, select Configure additional settings that are not in the default settings groups and click Next;
6 On the Additional Settings page, click Add to open the Browse Settings dialog box.
7 In the Browse Settings dialog box, click Create Setting to open the Create Setting dialog box;
8

KioskModeAppIn the Create Setting dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

  • Name: [Specify a unique name for the setting]
  • Description: [Specify details that help identifying the setting]
  • Setting type: OMA-URI
  • Data type: String
  • OMA-URI (Case Sensitive): ./Vendor/MSFT/AssignedAccess/KioskModeApp
    9 In the Browse Settings dialog box, select the newly created setting and click Select to open the Create Rule dialog box;
    10

    KioskModeApp_RuleIn the Create Rule dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

    • Name: [Specify a unique name for the rule]
    • Description: [Specify details that help identifying the rule]
    • Rule type: Value
    • The setting must comply with the following rule: Equals
    • the following values: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    • Select Remediate noncompliant rules when supported
    11 In the Browse Settings dialog box, click Close to return to the Additional Settings page;
    12 On the Additional Settings page, click Next;
    13 On the Platform Applicability page, click Next;
    14 On the Summary page, click Next;
    14 On the Completion page, click Close;

    Note: This created a configuration item that can be deployed like any other configuration item, as a part of a configuration baseline.

    Microsoft Intune hybrid

    Let’s continue with the same configuration within Microsoft Intune standalone. I’ll walk through the required steps to configure the required Configuration Policy.

    1 In the Microsoft Intune administration console, navigate to Policy > Configuration Policies and click Add to open the Create a New Policy dialog box;
    2 In the Create a New Policy dialog box, select Windows > Custom Configuration (Windows 10 Desktop and Mobile and later) and click Create Policy to open the Create Policy page;
    3

    On the Create Policy page, specify the following information in the General section and click Add in the OMA-URI Settings section to open the Add or edit OMA-URI Setting dialog box;

    • Name: [Specify a unique name for the policy]
    • Description: [Specify details that help identifying the policy]
    4

    KioskModeApp_SAIn the Add or edit OMA-URI Setting dialog box, specify the following information and click OK to return to the Create Policy page;

    • Setting name: [Specify a unique name for the setting]
    • Setting description: [Specify details that help identifying the setting]
    • Data type: String
    • OMA-URI (case sensitive): ./Vendor/MSFT/AssignedAccess/KioskModeApp
    • Value: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    5 On the Create Policy page, click Save Policy to open the Deploy Policy dialog box;
    6 In the Deploy Policy dialog box, click Yes to open the Manage Deployment dialog box;
    7 In the Manage Deployment dialog box, select a group click Add and click OK.

    End-user experience

    Let’s end this post with the most important thing, the end-user experience. After the device receives the new configuration and the configured end-user logs on, the end-user will receive a full screen Twitter app as shown below. The end-user won’t be able to close the Twitter app and can only get out of the kiosk mode by pressing Ctrl+Alt+Del. That will bring the end-user back to the logon screen.

    End-user experience
    TwitterApp

    More information

    Fore more information about kiosk mode on Windows 10, the AssignedAccess CSP and the AUMID, please refer to:

    Conditional access for Skype for Business Online

    Microsoft_Skype_for_Business_215x215This week another post about conditional access. This time about conditional access for Skype for Business Online. With this post I want to create more awareness for the availability of this feature and I want to show the currently available configuration options. During this post I’ll go into more detail about the prerequisites, the configuration and the end-users experience. The configurations that I’ll provide, are provided for Microsoft Intune standalone and Microsoft Intune hybrid.

    Prerequisites

    Before starting with the configuration steps for conditional access for Skype for Business Online, there are a few technical prerequisites that should be in place, or should be known.

    • Modern authentication must be enabled for Skype for Business Online. At this moment modern authentication must be enabled by enrolling into this Microsoft Connect program;
    • The end-user must use Skype for Business Online. Conditional access will not be applied to end-users who are in a Skype for Business on-premises deployment;
    • The end-user must use an Android or an iOS device. At this moment conditional access for Skype for Business Online is only supported for Android and iOS devices.

    Configuration

    The configuration of conditional access for Skype for Business Online contains two steps. The first step is to configure the Skype for Business Online policy and the second, and also optional, step is to configure the compliance policy.

    Step 1: Skype for Business Online policy

    Let’s start with the first step, which is the configuration of the Skype for Business Online policy. This policy makes sure that only managed and compliant devices can access Skype for Business Online. This policy will be be stored and targeted in Azure AD. The configuration of the Skype for Business Online policy is the same for Microsoft Intune standalone and Microsoft Intune hybrid. The configuration has to be done through the Microsoft Intune administration console. Keep in mind that after saving the policy, it takes effect immediately

    Environment Configuration
    Microsoft Intune standalone and Microsoft Intune hybrid

    SfBPolicyIn the Microsoft Intune administration console navigate to Policy > Conditional Access > Skype for Business Online Policy;

    To enable the Skype for Business Online policy select Enable conditional access policy and select the platforms to apply the conditional access policy to. The options are iOS and Android.

    To make sure that the Skype for Business Online policy is targeted to specific users, configure an Azure AD security group as a Targeted Group and, when there are users that need to be exempted, make sure to configure an Azure AD security group as an Exempted Group.

    Step 2: Compliance policy

    The next step is the configuration of the compliance policy. This policy defines the rules and settings that a device must comply with in order to be considered compliant by conditional access polices. The configuration of the compliance policy differs between Microsoft Intune standalone and Microsoft Intune hybrid. After creating the compliance policy, it can be deployed to users like any other policy. Keep in mind is that it’s not required to configure and deploy a compliance policy. When no compliance policy is configured and deployed, the device will automatically be considered compliant.

    Environment Configuration
    Microsoft Intune standalone

    MSIntuneSA_CPIn the Microsoft Intune administration console navigate to Policy > Conditional Access > Compliance Policies and click Add….

    To configure a compliance policy,  choose, based on the requirements, between the applicable Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Jailbreak and Operating System Version settings.

    Microsoft Intune hybrid

    MSIntuneHy_CPIn the Configuration Manager administration console navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies and click Create Compliance Policy.

    To configure a compliance policy, choose, based on the requirements, during the Create Compliance Policy Wizard the Supported Platforms and choose between the applicable Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Jailbreak and Operating System Version Rules.

    Note: Compliance policies can be used independently of conditional access. When used independently, the targeted devices are evaluated and reported with their compliance status.

    End-user experience

    After the configuration of the Skype for Business Online policy and the compliancy policy is completed, it’s time to look at the end-user experience. An enrolled and compliant device will give the end-user the normal experience. A not enrolled device, or a not compliant compliant device, will give the end-user a message based on the status of the device, when the end-user is trying to access Skype for Business Online. Those messages are shown below, using an iOS device as an example.

    Not enrolled Not compliant
    IMG_0038 IMG_0039

    More information

    For more information about conditional access, related to the Skype for Business Online Policy and the Compliance Policies, please refer to the following articles:

    Quick tip: Available token types for app configuration policies

    This is a quick and short blog post to create awareness about the existence of token types. Token types are basically just variables that can be used within a property list of an app configuration policy in Microsoft Intune hybrid and Microsoft Intune standalone. This blog post will provide a quick overview about the available token types with example values.

    Overview

    The following table contains the currently available token types for Microsoft Intune hybrid and Microsoft Intune standalone. Before going through this table, it’s good to know that the {{ and }} characters are used by token types only and should not be used for other purposes.

    Token type Example value
    {{userprincipalname}} pvanderwoude@petervanderwoude.nl
    {{mail}} pvanderwoude@petervanderwoude.nl
    {{partialupn}} pvanderwoude
    {{accountid}} fcc00012-123e-f479-aabe-abe2a1123b45
    {{deviceid}} c7d01dd3-136f-40c5-b843-711e958c4eef
    {{userid}} 2dda638e-28b7-4bdc-a4fd-70faaa811010
    {{username}} Peter van der Woude
    {{serialnumber}} F9FPVD86FCM5
    {{serialnumberlast4digits}} FCM5

    More information

    For more information about iOS apps with mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

    Prevent specific devices from accessing Microsoft Intune

    This week again something completely different. This week I’m going into the world of AD FS. More specifically, I’m going to use AD FS to prevent specific devices from accessing Microsoft Intune (and Office 365). I’ve received that question a few times lately, of which a couple of times on the Microsoft Intune forums, and I thought it would be worth a small blog post.

    Using AD FS to deny specific claims is not the prettiest method to prevent users and/or devices from accessing Microsoft Intune (or Office 365). However, it can be very efficient for specific use cases. This blog post will provide an easy method to find the required information to construct the claim rules and a step-by-step direction for configuring the relying party trust. However, keep in mind that it’s only meant to provide a configuration suggestion and to show the many configuration capabilities of AD FS. This suggestion can be easily expanded to create a more specific scenario.

    Construct claim rule

    Let’s start with finding the required information to create and configure the claim rule. I always like to use an environment in which I can simply deny all the access to the specific relying party. That will make it fairly easy to find the required information for the claim rule. By not permitting access to the relying party, the Event Viewer will generate messages about every request for a token for the relying party. Especially the Event ID 501 messages are interesting. Those messages provide information about the caller identity, which includes the information about the device that’s being used.

    The information that I’m looking for is available in the claim http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent. That claim contains the information that I’m looking for. However, keep in mind that it differs per application and per device, which information is provided as part of that claim. I used the Company Portal app, during my search for the required information, and that provided me with the following information about the devices that I used.

    Device Value
    iPad Mini 2 Mozilla/5.0 (iPad; CPU OS 9_3_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13E238
    Nokia Lumia 930 Mozilla/5.0 (Windows Phone 8.1; ARM; Trident/8.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 930) like Gecko

    That information can be used during the construction of the required claim rules. In the claim rules I can check for the existence of a specific value that’s provided in the claim. Based on the information, that was provided, I created the following existence rules, in which “(?i)” means that it’s not case sensitive.

    Device Value
    iPad Mini 2 exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)ipad”])
    Nokia Lumia 930 exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)lumia\ 930”])

    Configure relying party trust

    The existence rule can be used to deny the access to the relying party. The following step-by-step example will create a claim rule that checks if the device enters through the proxy (x-ms-proxy) and that checks for the device type (x-ms-client-user-agent). When both are evaluated  as true, the access will be denied.

    1. Open the AD FS Management console;
    2. Navigate to AD FS > Trust Relationships > Relying Part Trusts;
    3. Right-click the Microsoft Office 365 Identity Platform trust and select
      Edit Claim Rules…;
    4. Navigate to Issuance Authorization Rules and click Add Rule… to open the Add Issuance Authorization Claim Rule Wizard;
    5. On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next.
    6. On the Choose Claim Rule page, specify a Claim rule name, provide the following Claim rule and click Finish.

      exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) &&
      exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “(?i)lumia\ 930”])
        => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

    7. Verify that this new claim rule is created below the default Permit Access to All Users claim rule.

    This example will prevent the end-user from using a Nokia Lumia 930 for accessing the relying party. Simply perform the same steps and adjust the existence rule to prevent an iPad from accessing the relying party.

    End-user experience

    Now it’s time to have a look at the end-user experience. This time it’s extra important to realize the impact on the end-user experience, as the end-user will not get a very clear error message. Based on the examples used in this blog post the end-user will have the following experience on an iPad Mini 2 and a Nokia Lumia 930.

    iPad Mini 2 Nokia Lumia 930
    IMG_0037 wp_ss_20160501_0001

    More information

    For more information about limiting access to Office 365 and using regex in claim rules, please refer to the following articles:

    Microsoft Intune and the AppConfig Community

    This week I would like to write about Microsoft Intune and the AppConfig Community. I want to create some awareness about what the AppConfig Community is and I want to show how even Microsoft Intune can, and will, benefit of that great alliance.

    What is the AppConfig Community?

    Let’s start with what the AppConfig Community actually is. I could do that by providing my own explanation about the AppConfig Community, but to prevent any possible misinterpretation from my side, I will provide the good and clear explanation as provided on the AppConfig Community website.

    The AppConfig Community is a collection of industry leading Enterprise Mobility Management (EMM) solution providers and app developers that have come together to make it easier for developers and customers to drive mobility in business. The community’s mission is to streamline the adoption and deployment of mobile enterprise applications by providing a standard approach to app configuration and management, building upon the extensive app security and configuration frameworks available in the OS. Working together, the members of the AppConfig Community are making it simpler for developers to implement a consistent set of controls so that enterprise IT administrators can easily configure and manage apps according to their business policies and requirements.

    Historically, developers used proprietary software development kits (SDKs) to enable configuration and management features of their apps through EMM. This required app developers to build different versions of their apps for each EMM vendor. Now, with the AppConfig Community tools and best practices, developers do not require EMM-specific integrations for many enterprise use cases. End users also benefit from automated features such as an out-of-the-box experience to give the users instant app access without requiring cumbersome setup flows or user credentials.

    Microsoft Intune and the AppConfig Community

    Let’s continue with how Microsoft Intune works with the AppConfig Community. Well, it’s good to know that, at this moment, Microsoft Intune is not part of the collection of industry leading EMM solution providers that started the AppConfig Community. However, that doesn’t mean that the apps, created with the AppConfig Community standards, won’t work with Microsoft Intune. The XML format used by the AppConfig Community is similar to the XML format used by Microsoft and the Microsoft Intune app partners. In other words, the apps created by the partners, of the AppConfig Community, should also work with Microsoft Intune.

    Microsoft Intune example

    Now I want to show how Microsoft Intune works with an app, of a partner, of the AppConfig Community, to proof my previous statement. As an example app I use the amazing Nacho Mail app. Not only is it a great email app, it also has a great support team and some awesome configuration options. The support team is more than willing to help with providing the required information to apply app configurations to the Nacho Mail app.

    Configuration

    As I’m currently looking at multiple mail apps, with one of my customers, I’m also looking at the Nacho Mail app. One of the big pros, of the Nacho Mail app, is the fact that it allows the configuration of the app. It has the ability to configure a mail profile and it even has the ability to apply custom branding to the app. After contacting the support team, of the Nacho Mail app, they provided me with the following configuration key-value-pairs.

    Type Key Description
    String AppServiceHost Name of server
    Integer AppServicePort Port number
    String UserName User name
    String UserDomain Domain name
    String UserEmail User email address
    String BrandingName Name of app to be displayed
    String BrandingLogo Link to image to be displayed with app

    I could use those key-value-pairs to create a mail profile for Office365, including custom branding. It’s not required to specify AppServiceHost with outlook.office365.com, as the Nacho Mail app is intelligent enough to figure it out based on the provided mail address. However, I noticed that it would save me a certificate warning. Below is the configuration that I’ve created and to use this configuration, please refer to my post about App Configuration Policies for iOS.

    <dict>
       <key>AppServiceHost</key>
       <string>outlook.office365.com</string>
       <key>BrandingName</key>
       <string>petervanderwoude.nl</string>
       <key>BrandingLogo</key>
       <string>[Specify URL to logo]</string>
       <key>UserEmail</key>
       <string>{{userprincipalname}}</string>
    </dict>

    Note: I used the {{userprincipalname}} token type that is supported by Microsoft Intune to provide the user principal name of the end-user. However, at this moment Microsoft Intune hybrid seems to be having problems with the supported token types. Microsoft Intune standalone works like a charm.

    End-user experience

    After creating the app configuration, it’s time to look at the end-user experience. This time I will show the first two screens of the Nacho Mail app, after installation. That will provide a clear picture about how app configuration policies can be helpful for an end-user. The screenshots on the left show the default start of the Nacho Mail app and the screenshots on the right show the start of the Nacho Mail app after deploying the app together with the app configuration policy.

    On the second screenshot, on the right, it clearly shows the complete configuration of the mail profile and my custom branding. I love it!

    Before After
    IMG_0034 IMG_0030
    IMG_0035 IMG_0033

    More information

    For more information about the AppConfig Community and mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

    App Configuration Policies for iOS apps

    This week another blog post that is triggered by a feature that is introduced in ConfigMgr 1602. And again, it’s about a feature that already did exist in Microsoft Intune standalone. This post will be about the App Configuration Policies for iOS apps. These policies can make the life of an end-user a lot easier and are a very welcome addition to Microsoft Intune standalone and Microsoft Intune hybrid.

    For now the biggest challenge might be finding the apps that support App Configuration Policies and, maybe even more important, apps that have the settings documented. During the deployment of an app via ConfigMgr, or Microsoft Intune, it’s already visible if  an app could support App Configuration Policies. However, a lot of apps have the potential, but not yet the complete implementation.

    Introduction

    App Configuration Policies in Microsoft Intune hybrid and Microsoft Intune standalone, can be used to supply settings that might be required when the end-user runs an app. Settings that the end-user would have to specify manually. Think about settings like, a server name, a custom port number, a user name, a password, specific language settings and specific security settings.

    If these settings are incorrectly entered by the end-user, this can increase the burden on the service desk, and can also slow the adoption of new apps. App Configuration Policies can help with eliminating these problems by letting the organization deploy these settings to the end-users in a policy before they run the app. The settings are then supplied automatically, and the end-user doesn’t have to perform an action.

    These App Configuration Policies are not deployed directly to users and devices. Instead, they are associated with a deployment type during the deployment of the application. The policy settings will be used whenever the app checks for them (typically, the first time it is run).

    Configuration

    App Configuration Policies are configured per app, because every app supports different settings. In the following configuration examples I’m using the Acronis Access app as an example. During the configuration I will use one specific configuration setting, named enrollmentServerName. For all other supported Acronis Access app configuration settings, please refer to: https://www.acronis.com/en-us/support/documentation/AcronisAccessAdvanced_7.0/index.html#28935.html

    Microsoft Intune standalone

    The configuration of App Configuration Policies in Microsoft Intune standalone can be achieved by performing the following steps. After the configuration of the App Configuration Policy, it can be used during the deployment of the Acronis Access app.

    1 In the Microsoft Intune administration console, navigate to POLICY and click Add..;
    2 In the Create a New Policy dialog box, select iOS > Mobile App Configuration Policy and click Create Policy  to open the Create Policy page;
    3

    On the General section of the Create Policy page, specify the following information.

    • MI_AppConfig_GenName: [Specify a unique name for the app configuration policy];
    • Description: [Specify details that help identifying the app configuration policy].
    4

    In the Mobile App Configuration Policy section of the Create Policy page, specify the following information and click Verify;

    MI_AppConfig_Rule<dict>
       <key>enrollmentServerName</key>
       <string>[Specify an enrollment server name]</string>
    </dict>

    5 After verifying the created configuration, click Save Policy.

    Microsoft Intune hybrid

    The configuration of App Configuration Policies in Microsoft Intune standalone can be achieved by performing the following steps. After the configuration of the App Configuration Policy, it can be used during the deployment of the Acronis Access app.

    1 In the Configuration Manager administration console, navigate to Software Library > Overview > Application Management > App Configuration Policies;
    2 On the Home tab, click Create new Application Configuration Policy to open the Create App Configuration Policy Wizard;
    3

    CM_AppConfig_GenOn the General page, provide the following information and click Next.

    • Name: [Specify a unique name for the app configuration policy];
    • Description: [Specify details that help identifying the app configuration policy].
    4

    CM_AppConfig_PolOn the iOS Policy page, select Specify name and value pairs (for simple property list files without nesting) and click New to open the Edit Name/Value Pair dialog box.

    Note: Select Browse to a property list file (for more complex property list files with nesting) for adding more advanced configurations, or for adding the configuration in an XML format (like with the Microsoft Intune standalone configuration).

    5

    CM_AppConfig_RuleIn the Edit Name/Value Pair dialog box, provide the following information and click Ok to return to the iOS Policy page.

    • Type: String;
    • Name: enrollmentServerName;
    • Value: [Specify an enrollment server name].
    6 CM_AppConfig_ConfBack on the iOS Policy page, verify the created configuration and click Next.
    7 On the Summary page, click Next.
    8 On the Completion page, click Close.

    End-user experience

    Now it’s time to look at the end-user experience. This time I will show the first start of the Acronis Access app after installation. The first screenshots shows the default start of the Acronis Access app and the second screenshot shows the start of the Acronis Access app after deploying the app together with the App Configuration Policy. As I don’t really have a server to connect to, it stops at the connection screen in which it did configure my custom server URL.

    Before After
    IMG_0018 IMG_0017

    More information

    For more information about iOS with mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

    Conditional access, Windows 10 and Microsoft Intune: What are the compliance options?

    Recently Microsoft released a couple of blog posts about The Path to Modernizing Windows Management and about Clear & Simple Guidance: When ConfigMgr and Intune should be used with Windows 10, which should be really helpful with deciding how to managing the Windows 10 devices within an organization. I would really recommend everybody to read those posts. This blog post will not be directly related, but will continue on a more detailed level about the options for conditional access and Windows 10 devices.

    In this blog post I will provide nice tables of the different compliance rules, for Windows 10 devices, that are currently available for Microsoft Intune standalone and Microsoft Intune hybrid. In those tables I’ll show the different management scenarios and the currently available applicable compliance rules.

    Overview

    Before I’ll start with the overview, it’s good to provide a short explanation about the distinction between the conditional access policy and the compliance policy.

    The conditional access policy is a required configuration to enable conditional access on a particular service and to help secure access to that particular service. In the conditional access policy, the targeted platforms and the targeted users of devices are configured. Also, important for Windows 10 devices, in the conditional access policy it is possible to determine if Windows 10 devices must be compliant or domain joined.

    The compliance policies, on the other hand, are optional additional rules that can evaluate settings like PIN and encryption. The devices of targeted users must be compliant to those additional rules. When there are no compliance policies deployed, the device will automatically be evaluated as compliant.

    Microsoft Intune standalone

    Now let’s start with the overview of available compliance rules in Microsoft Intune standalone. In Microsoft Intune standalone, a Windows 10 device can be managed by the Microsoft Intune client and it can be enrolled as a mobile device. Those two options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined the only additional configuration for those devices.

    Intune client MDM
    Allow simple passwords N/A Yes (Mobile only)
    Maximum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
    Maximum Windows version N/A Yes (Desktop only)
    Minutes of inactivity before password is required N/A Yes
    Minimum password length N/A Yes
    Minimum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
    Minimum Windows version N/A Yes (Desktop only)
    Require a password to unlock an idle device N/A Yes (Mobile only)
    Password expiration N/A Yes
    Remember password history – Prevent reuse of previous passwords N/A Yes
    Required password type – Minimum number of character sets N/A Yes
    Require a password to unlock mobile devices N/A Yes (Mobile only)
    Require devices to be reported as healthy N/A Yes
    Require encryption on mobile device N/A Yes

    Microsoft Intune hybrid

    Let’s continue with the overview of available compliance rules in Microsoft Intune hybrid. In Microsoft Intune hybrid, a Windows 10 device can be managed by the Microsoft Intune client, the ConfigMgr client and it can be enrolled as a mobile device. Those three options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined  the only additional configuration for those devices.

    Intune client ConfigMgr client MDM
    All required updates installed with a deadline older than X days N/A Yes N/A
    Allow simple passwords N/A N/A Yes (Mobile only)
    File encryption on mobile device N/A N/A Yes
    Maximum operating system version N/a N/A Yes
    Minimum classification of required updates N/A N/A Yes
    Minimum operating system version N/A N/A Yes
    Minimum password length N/A N/A Yes
    Minutes of inactivity before password is required N/A N/A Yes
    Require a password to unlock an idle device N/A N/A Yes (Mobile only)
    Reported as healthy by Health Attestation Service N/A N/A Yes
    Require Antimalware N/A Yes N/A
    Require BitLocker drive encryption N/A Yes N/A
    Require password settings on mobile devices N/A N/A Yes
    Require registration in Azure Active Directory N/A Yes N/A

    More information

    For information about about conditional for Windows 10 devices with Microsoft Intune standalone or Microsoft Intune hybrid, please refer to:

    Conditional access and health attestation

    This week another blog post about conditional access. And another blog post that is triggered by a feature that is introduced in ConfigMgr 1602. However, this time it’s about a feature that already did exist in Microsoft Intune standalone. I’m talking about the new conditional access rule that uses the Health Attestation Service. This new rule creates the ability to ensure that Windows 10 devices have trustworthy BIOS, TPM, and boot software configurations enabled.

    In this blog post I’ll show the detailed configuration steps for Microsoft Intune hybrid and I’ll briefly note the most important configurations for Microsoft Intune standalone.

    Introduction

    Device health attestation is an additional level of restricting access to Exchange Online and SharePoint Online for Windows 10 devices. Currently only available for Windows 10 devices that are managed via OMA-DM. It adds the ability to create compliance policies that require Windows 10 devices to report as healthy. Device health attestation can be used to ensure that the following trustworthy configurations are enabled:

    • BitLocker: BitLocker provides encryption for all data stored on the Windows operating system volume.
    • Code integrity: Code Integrity provides improvements to the security of the operating system by validating the integrity of a driver, or system file, each time it is loaded into memory.
    • Early-launch antimalware (only applies to PCs): Early launch anti-malware (ELAM) provides protection for computers when they start up and before third-party drivers initialize.
    • Secure boot: Secure boot provides a security standard, which is developed by members of the PC industry, to help make sure that a PC boots with only software that is trusted by the PC manufacturer.

    Note: A Windows 10 device must be compliant to all of the applicable configurations to be reported as healthy by the Health Attestation Service.

    Pre-configuration

    Before looking at the configuration of conditional access and device health attestation, I will begin with mentioning a new client setting and the health attestation dashboard. This is at least as important, as it will provide a good understanding about the impact of using conditional access based on the status reported by the Health Attestation Service.

    Default client settings

    To start with collecting information about the status, reported by the Health Attestation Service, of Windows 10 devices, it’s good to start with enabling the communication with the Health Attestation Service,. The following 2 steps will make sure that the information will be collected.

    1 In the Configuration Manager administration console, navigate to Administration > Overview > Client Settings and open the Default Client Settings;
    2

    CA_ClientSettings_HAIn the Default Client Setting, navigate to Computer Agent and select Yes with Enable communication with Health Attestation Service and click OK to close the Default Client Settings..

    Health attestation dashboard

    After configuring the Default Client Settings, the information of the Health Attestation Service, on Windows 10 devices, will start showing in the health attestation dashboard and the List of devices by Health Attestation state report. This information can be used to get a good understanding about the impact of enabling conditional access based on the  status reported by the Health Attestation Service. The health attestation dashboard is available by navigating to Monitoring > Overview > Security > Health Attestation and will look like the following example.

    CA_Intune_HealthAttestation

    Note: In Microsoft Intune standalone similar reports are available, in the Reports section, named Health Attestation Reports.

    Configuration

    Let’s continue with looking at the real configuration for conditional access. I will start with briefly mentioning the conditional access policy and I’ll end this configuration section with going through all the required steps for creating the compliance policy.

    Conditional access policy

    Now that I know what the impact will be of using the health of a Windows 10 device, reported by the Health Attestation Service, I can start with enabling conditional access. Just like last week, I’ll only mention the conditional access policy briefly. It’s important that the setting Windows must meet the following requirements is selected and configured to Devices must be compliant. Also, for supporting Windows 10 mobile, it’s important to also select Windows 10 Mobile. These settings can be configured as shown below for Exchange Online and SharePoint Online.

    Exchange Online Policy SharePoint Online Policy
    CA_ExchOnl_Win10 CA_SPOnl_Win10

    Compliance policy

    Like last week, the more interesting configuration is the configuration of the new compliance policy. The following 9 steps will go through the creation of the compliance policy. After the creation of the compliancy policy, it can be deployed, like any other policy, to users.

    1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies;
    2 On the Home tab, click Create Compliance Policy to open the Create Compliance Policy Wizard;
    3

    On the General page, specify the following information and click Next;

    • CA_ConfigMgrIntune_CP_GeneralName: [Specify a unique name for the compliance policy]
    • Description: [Specify details that help identifying the compliance policy]
    • Select Compliance rules for devices managed without the Configuration Manager client with Specify the type of compliance policy that you want to create
      • Select Windows 8.1 and Windows 10

    Note: Select Windows Phone and Windows 10 Mobile for supporting the configuration on Windows 10 Mobile devices.

    4

    On the Supported Platforms page, select the following platforms and click Next;

    • CA_ConfigMgrIntune_CP_PlatformAll Windows 10 (64-bit)
    • All Windows 10 (32-bit)

    Note: Select All Windows 10 Mobile and higher for supporting the configuration on Windows 10 Mobile devices.

    5 On the Rules page, click New… to open the Add Rule dialog box;
    6

    ICA_ConfigMgrIntune_CP_AddRulen the Add Rule dialog box, select the Reported as healthy by the Health Attestation Service rule and click OK to return to the Rules page;

    7

    CA_ConfigMgrIntune_CP_RulesBack on the Rules page, verify the created configuration and click Next;

    8 On the Summary page, click Next
    9 On the Completion page, click Close.
    CA_Intune_CompliancePolicyNote: In Microsoft Intune standalone a similar compliance policy setting is available, in the Device Health section, named Require devices to be reported as healthy.

    End-user experience

    Now it’s time to look at the end-user experience. This time I won’t show the end-user experience of a non-compliant device connecting to Exchange Online, or SharePoint Online, as it’s similar to the messages shown during last weeks post. This time I’ll only show the end-user experience in the Company Portal app on a Windows 10 Desktop device and a Windows 10 Mobile device. The messages will be similar as shown below. It will not just show a non-compliant device, it will actually show which configuration is reported as not healthy by the Health Attestation Service.

    Non-compliant Compliant
    CA_Intune_CompanyPortal CA_Intune_CompanyPortal2
    wp_ss_20160319_0001 wp_ss_20160319_0002

    More information

    For more information about conditional access, Windows 10 device health attestation and the HealthAttestation CSP, please refer to:

    Conditional access for PCs managed by ConfigMgr

    This blog post is about a pre-release feature, which means that it’s included in the product for early testing in a production environment, but should not be considered production ready.

    This week a blog post about the Conditional access for managed PCs feature that is introduced in ConfigMgr 1602. This feature is introduced as a pre-release feature. The requirements for using Conditional access for managed PCs are similar to the requirements of the blog series that I did a few months ago about Conditional access for PCs. Make sure that those requirements are in-place before starting with the configurations described in this post.

    Introduction

    Conditional access for managed PCs is basically an additional level of restricting access to Exchange Online and SharePoint Online. Before the only level of restricting access was that device had to be enrolled via Microsoft Intune, or that the device had to be domain joined. Now it’s also possible to create additional compliance policies for managed PCs. Managed PCs by ConfigMgr. Those compliance policies can contain the following rules:

    • Require registration in Azure Active Directory: This rule checks if the end-user device is workplace joined to Azure AD. If not, the device is automatically registered in Azure AD. Automatic registration is currently only supported on Windows 8.1.
    • All required updates installed with a deadline older than a certain number of days: This rule checks to see if the end-user device has all required updates within the configured deadline and grace period. If not, any pending required updates are automatically installed.
    • Require BitLocker drive encryption: This is a check to see if the primary drive on the device is BitLocker encrypted. If not, access to Exchange Online and SharePoint Online is blocked.
    • Require Antimalware: This is a check to see if the antimalware software is enabled and running. If not, access to Exchange Online and SharePoint Online is blocked. At this moment only supported for System Center Endpoint Protection and Windows Defender.

    Configuration

    Now lets have a look at the configuration. I will briefly mention the conditional access policy, because I’ve written a lot about those in my previous blog series about Conditional access for PCs. After that I’ll go through all the required steps for creating the compliance policy and I’ll end this configuration section with the effect on the client.

    Pre-release feature

    As Conditional access for managed PCs is a pre-release feature, it must be specifically turned on. This can be achieved by simply performing the following 2 steps.

    1 In the Configuration Manager administration console, navigate to Administration > Overview > Cloud Services > Updates and Servicing > Features;
    2 Right-click Pre-release – Conditional access for managed PCs and select Turn on.

    Conditional access policy

    The reason why I do have to mention the conditional access policy, is one specific configuration setting. That specific setting is that the setting Windows must meet the following requirements is selected and configured to Devices must be compliant. This is very important, as any other configuration would make a domain join enough to be compliant, while in this configuration I want to create an additional compliance policy. That setting can be configured as shown below for Exchange Online and SharePoint Online.

    Exchange Online Policy SharePoint Online Policy
    CA_ConfigMgr_ExchangeOnline CA_ConfigMgr_SharePointOnline

    Compliance policy

    More interesting is the new compliance policy. Within the compliance policy it’s now possible to create a compliance policy specifically for devices managed with the ConfigMgr client. The following 9 steps will go through the creation of the compliance policy. After the creation of the compliancy policy, it can be deployed, like any other policy, to users.

    1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies;
    2 On the Home tab, click Create Compliance Policy to open the Create Compliance Policy Wizard;
    3

    On the General page, specify the following information and click Next;

    • CA_ConfigMgr_CP_GeneralName: [Specify a unique name for the compliance policy]
    • Description: [Specify details that help identifying the compliance policy]
    • Select Compliance rules for devices managed with the Configuration Manager client with Specify the type of compliance policy that you want to create
    4

    On the Supported Platforms page, select the following platforms and click Next;

    • CA_ConfigMgr_CP_PlatformAll Windows 7 (64-bit)
    • All Windows 7 (32-bit)
    • All Windows 8.1 (64-bit)
    • All Windows 8.1 (32-bit)
    • All Windows 10 (64-bit)
    • All Windows 10 (32-bit)
    5 On the Rules page, click New… to open the Add Rule dialog box;
    6

    In the Add Rule dialog box, select the following rules one-by-one and click OK to return to the Rules page;

    • CA_ConfigMgr_CP_AddRuleRequire registration in Azure Active Directory
    • All required updates installed with a deadline older than X days
    • Require BitLocker drive encryption
    • Require Antimalware
    7

    CA_ConfigMgr_CP_RulesBack on the Rules page, verify the created configuration and click Next;

    Note: As this screenshot shows, none of the rules require additional configuration except for the software updates rules. That rule requires the selection of the number of days that a deadline has been passed.

    8 On the Summary page, click Next
    9 On the Completion page, click Close.

    Policy effect

    A good place to look at the effect of the compliance policy, is to look at the reports. More specifically, the reports Compliance Access Compliance for Users and Compliance Access Compliance Report. However, I still like to think that the log files are the best place to look at the effect of the compliance policy. More specifically, the DcmWmiProvider.log. That log file provides detailed information about the compliance checks that are performed. Below is a log snippet about a successful compliance check.

    CreateInstanceEnumAsync called for the provider
    Class name CCM_SoftwareUpdateCompliance
    Days 5
    CCMSoftwareUpdateCompliance 20160313160716
    CCMSoftwareUpdateCompliance Select * from CCM_UpdateCIAssignment
    Determined 0 as not compliant with deadline exceeded by 5 days
    CCMEncryptionCompliance: Get instance of CCM_EncryptionCompliance
    Detected virtual machine: Drive encryption not applicable. Setting compliance to true
    Setting Encryption Compliance to: 1
    CheckWPJCert – Checking Machine\ cert store
    Found WorkplaceJoin cert
       Status: 2
       Error: 0
    CCMAntimalwareCompliance: Get instance of CCM_AntimalwareCompliance
    Retrieved RealTimeProtectionEnabled property = 1
    Retrieved AntivirusEnabled property = 1
    Setting Antimalware Compliance to: 1

    This log snippet provides clear information about the 4 rules, of the compliance policy, that are being checked. It clearly shows the software update check, the BitLocker encryption check, the workplace join check and the antimalware check. The log snippet even provides some details about how those checks are performed. For example, it shows that my test device was a virtual machine and that, because of that, the encryption check was skipped and that the compliance, for that check, was automatically set to true.

    End-user experience

    Now it’s time to look at the end-user experience. At this moment the end-user experience is as shown below. When a non-compliant managed PC tries to access Exchange Online, or SharePoint Online, it will get a message as shown below. A compliant managed PC will be able to simply access Exchange Online and SharePoint Online. To get the detailed information about the compliance of the managed PC, the end-user can use the Device compliance section in Software Center, as shown below.

    Non compliant Compliant
    CA_ConfigMgr Not applicable. A compliant managed PC will automatically have access. Meaning there is no special screen that the en-user will get.
    CA_SoftwareCenter_01 CA_SoftwareCenter_02

    More information

    For more information about conditional access for PCs that are managed by ConfigMgr, please refer to this article about Manage access to O365 services for PCs managed by System Center Configuration Manager.