When are devices blocked after enabling conditional access?

This week a blog post with only one purpose, and that purpose is, providing an overview. Providing an overview about when devices will be blocked after enabling conditional access. That information is available in the TechNet documentation (see the More information section of this post), but it might be a bit difficult to find. As the question pops up in the TechNet forums at a regular basis, I got the suggestion that it would be a good idea to provide a quick, but clear, overview.

This post will provide nice tables, for Microsoft Intune standalone and Microsoft Intune hybrid, with the time it will take before a device will be blocked from Exchange. That information will be provided for two different setups and three different scenarios. A quick spoiler, the tables for Microsoft Intune standalone and Microsoft Intune hybrid are identical.

Overview

Let’s have a look at the mentioned overview tables for Microsoft Intune standalone and Microsoft Intune hybrid. However, before looking at the overview tables, it’s important to understand the following details about the scenarios.

  • After user setting up email profile – This scenario is applicable when the end-user wants to configure email on a device that is not enrolled;
  • After user enrolling blocked device – This scenario is applicable when the end-user wants to get email on a device that’s just enrolled, or just remediated;
  • After user un-enrolling device – This scenario is applicable when the end-user has un-enrolled its device.

Microsoft Intune standalone

Below is the overview table for Microsoft Intune standalone.

After user setting up email profile After user enrolling blocked device After user un-enrolling device
Exchange Online Device is blocked immediately Device is unblocked within 2 minutes Device is blocked after around 6 hours
Exchange on-premises Device is blocked after around 1-3 hours Device is unblocked within 2 minutes Device is blocked after around 1-3 hours

Note: The legacy Exchange Online Dedicated is identical to Exchange on-premises.

Microsoft Intune hybrid

Below is the overview table for Microsoft Intune hybrid.

After user setting up email profile After user enrolling blocked device After user un-enrolling device
Exchange Online Device is blocked immediately Device is unblocked within 2 minutes Device is blocked after around 6 hours
Exchange on-premises Device is blocked after around 1-3 hours Device is unblocked within 2 minutes Device is blocked after around 1-3 hours

Note: The legacy Exchange Online Dedicated is identical to Exchange on-premises.

More information

For more information about managing email access via Microsoft Intune standalone or Microsoft Intune hybrid, please refer to:

Enable modern authentication for Exchange Online

ExchangeOnline_OauthThis blog post is about enabling modern authentication on Exchange Online. Modern authentication is a requirement for conditional access for PCs. For SharePoint Online that’s enabled by default and for Exchange Online that’s disabled by default. However, that configuration is now available via PowerShell. This post is meant to show how easy this can be achieved now. Before this had to be done by enrolling in to the preview program. Now it’s publically available.

Why I’m posting about Exchange Online? Well, actually that’s quite simple, I can’t get around it. If I want to configure conditional access in Microsoft Intune standalone or hybrid, I often need to use Exchange Online. In this post I’ll go through five simple steps to connect, verify and configure modern authentication on Exchange Online.

Connect to Exchange Online

The first thing that is required is to connect to Exchange Online. The good thing about connecting to Exchange Online via PowerShell is that it doesn’t require the installation of any additional modules. Simply walkthrough the following three steps to get connected with Exchange Online.

Step 1: Provide credentials

The first step is to provide the admin credentials for the Office 365 tenant. This can be achieved fairly easy by using the Get-Credential cmdlet. That will show a Windows PowerShell credential request dialog box that can be used for providing these credentials.

$O365Credential = Get-Credential

Step 2: Create a new session

The second step is to create a new remote session to Exchange Online. This can be achieved by using the New-PSSession cmdlet. The session can be created by using the provided credentials and by providing the URI mentioned below.

$EOSession = New-PSSession -ConfigurationName Microsoft.Exchange ` -ConnectionUri https://outlook.office365.com/powershell-liveid/ ` -Credential $O365Credential -Authentication Basic -AllowRedirection

Step 3: Import the new session

The third step is to import the remote session. This can be achieved by using the Import-PSSesion cmdlet. That will import the remote commands to the current session by using providing the new session information. To connect the remote session again, simply use the Remove-PSSession cmdlet.

Import-PSSession $EOSession

Enable modern authentication

The next thing is what this post is actually about, enabling modern authentication on Exchange Online. In two relatively simple steps it’s possible to verify the configuration and to enable modern authentication.

Step 4: Verify the configuration

The fourth step is to verify the current configuration of modern authentication. This can be achieved by using the Get-OrganizationConfig cmdlet. That will get the configuration data for the Exchange organization. In this case simply use a specific select to only get the OAuth* configuration.

Get-OrganizationConfig | Select Name, OAuth*

Step 5: Enable modern authentication

The fifth step is to truly enable modern authentication. This can be achieved by using the Set-OrganizationConfig cmdlet. That can configure the various settings for the Exchange organization. One of the parameters OAuth2ClientProfileEnabled can be used to enable or disable modern authentication on Exchange Online.

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true

More information

For more information about modern authentication, Exchange Online and PowerShell please refer to the following links:

My Experts Live session and content

ExpertsLive2015November has been a crazy month for me so far. The frequent visitors of my blog might have noticed a complete silence the last couple of weeks. Well, it’s time to break that silence again! This month started with my first MVP Summit and I have to say that it would be awesome to be there again next year!

After that I had the great opportunity to present on Experts Live 2015. I had a session about conditional access and mobile application management. This post will contain the slide deck of that session and the movies of the demos. The sessions were not recorded, but as I always create movies of my demos, as a backup scenario, I thought lets post those movies instead.

Slide deck

ExpertsLive_SlideLet’s start with the slide deck of my session. The PDF of my slide deck will be made available on the site of Experts Live and is available for download on my own site by clicking on picture of my slide deck here on the side. This will start a direct download.

Demos

Let’s continue with the bigger part of this post, the movies of my demos. These movies were created as a backup scenario, in case there would be a problem with the Internet connection. Even to those that attended my session, these movies will include new information. During my session I could only show the Microsoft Intune hybrid configurations, due to time considerations. These movies also include the Microsoft Intune standalone configurations.

Demo – Conditional access on Exchange Online and SharePoint Online

During this demo I’ll walkthrough the end-user experience for conditional access. This provides a clear overview of what conditional access is and what it will be for the end-user. During this demo I’ll go through the following actions, on a Dutch iPad:

  • Go to Settings > General and show the missing Management Profile;
  • Go to Settings > Mail and add <user>@petervanderwoude.nl;
  • Open the native mail app and show the conditional access email;
  • Open the Microsoft Outlook app and show the enrollment message for <user>@petervanderwoude.nl;
  • Open the Microsoft Intune Company Portal app and walkthrough the steps to enroll the device;
  • During the enrollment solve the issue with the configured mail profile;
  • Open the native mail app and show the access to <user>@petervanderwoude.nl;
  • Open the Microsoft Outlook app and show the access to <user>@petervanderwoude.nl.

Demo – Configuring conditional access on Exchange Online and SharePoint Online

During this demo I’ll walkthrough the settings that are available for configuring compliance policies and conditional access on Exchange Online and SharePoint Online for Microsoft Intune standalone and hybrid. This demo is cut in four parts, one for conditional access on Exchange Online, one for conditional access SharePoint Online, one for compliance policies in Microsoft Intune hybrid and one for compliance policies in Microsoft Intune standalone. During the first part I’ll go through the following actions:

  • Open the Configuration Manager console and navigate to Assets and Compliance;
  • Navigate to Compliance Settings > Conditional Access > Exchange Online;
  • Select Configure conditional access policy in the Intune console;
  • Select Enable conditional access policy for Exchange Online;
  • Walkthrough the settings for apps using modern authentication;
  • Walkthrough the settings for apps using basic authentication;
  • Walkthrough the targeted and exempted groups;
  • (Additional) Show the Service to Service Connector.

During the second part I’ll go through the following actions:

  • Open the Configuration Manager console and navigate to Assets and Compliance;
  • Navigate to Compliance Settings > Conditional Access > SharePoint Online;
  • Select Configure conditional access policy in the Intune console;
  • Select Enable conditional access policy for SharePoint Online;
  • Walkthrough the settings for apps using modern authentication;
  • Walkthrough the targeted and exempted groups.

During the third part I’ll go through the following actions:

  • Open the Configuration Manager console and navigate to Assets and Compliance;
  • Navigate to Compliance Settings > Compliance Policies;
  • Select Create Compliance Policy;
  • Walkthrough the available Rules and the impact of the selected Platform;
  • Walkthrough the Deployment Settings.

During the fourth part I’ll go through the following actions:

  • Open the Microsoft Intune console and navigate to POLICY > Configuration Policies;
  • Select Add…;
  • Walkthrough the available Policies Settings;
  • Walkthrough the Deployment options.

Demo – Mobile application management

During this demo I’ll walkthrough the end-user experience for mobile application management. This provides a clear overview of what can be achieved with mobile application management and what the experience will be for the end-user. This demo is cut in two parts, one for starting to manage an app and one for the managed app experience. During the first part of this demo I’ll go through the following actions, on a Dutch iPad:

  • Go to Settings > General and show the missing apps in the Management Profile;
  • Open the Microsoft Intune Company Portal app;
  • Install, configure and allow management of the Microsoft Outlook app;
  • Go to Settings > General and show the Microsoft Outlook app in the Management Profile.

During the second part of this demo I’ll go through the following actions, on an English iPad:

  • Open the Microsoft Outlook app;
  • Walkthrough the behavior of blocked and allowed URLs from company email;
  • Walkthrough the behavior of copying and pasting content from company email;
  • Walkthrough the behavior of attachments in company email.

Demo – Configuring mobile application management

During this demo I’ll walkthrough the settings that are available for configuring mobile application management for Microsoft Intune standalone and hybrid. This demo is cut in two parts, one for Microsoft Intune hybrid and one for Microsoft Intune standalone. During the first part I’ll go through the following actions:

  • Open the Configuration Manager console and navigate to Software Library;
  • Navigate to Application Management > Application Management Policies;
  • Select Create Application Management Policy;
  • Walkthrough the Policy Types and the impact on the Policy Settings;
  • Walkthrough the Deployment options.

During the second part I’ll go through the following actions:

  • Open the Microsoft Intune console and navigate to POLICY > Configuration Policies;
  • Select Add…;
  • Select Software > Mobile Application Management (iOS 7.1 and later);
  • Select Create a Custom Policy;
  • Walkthrough the available Policies Settings;
  • Walkthrough the Deployment options.

Demo – Retire mobile device

The last demo showed the impact of retiring a mobile device. This is the only demo that I didn’t record, simply because I made it up at the last moment and I didn’t decide until the end of the session how I was going to retire the mobile device. Depending on the available time I would pick between the Configuration Manager console, PowerShell, or the iPad.

The conditional access flow of the other Office apps

Microsoft_WordThis week something similar to last week, this week I’ll be looking at the conditional access flow of the other Office apps. By that I basically mean every Microsoft app, connecting to Office 365, using modern authentication, except for the Outlook app for iOS and Android. Like last week I’ll be looking at a high-level from a component perspective. It will be like a what-happens-when-and-where flow. The biggest difference with the Outlook app for iOS and Android is that the other Office apps don’t use the Outlook Cloud Service and instead go directly, with their access token, to Office 365.

Before I’ll start with the what-happens-when-and-where flow, I think it’s important to again first provide a bit of information about Active Directory Authentication Library (ADAL)-based authentication and the Open Authentication (OAuth) protocol in combination with Office 365. These components make the what-happens-when-and-where flow. During this post I’ll use the Word app as an example for the other Office apps.

ADAL-based authentication

The Word app uses ADAL-based authentication to access Office 365. ADAL-based authentication enables the Word app to use browser-based authentication with Office 365 and facilitates a sign-in with Azure AD. This allows the end-user to sign in directly to the Office 365 identity provider, which can be Azure AD, or a federated identity provider like AD FS, instead of providing credentials directly to the Word app.

OAuth for Office 365

The ADAL-based sign-in enables OAuth for Office 365 accounts. By enabling OAuth it provides the Word app with a secure mechanism to access email without requiring access to end-user credentials. At sign-in, the end-user authenticates directly with the Office 365 identity provider, which can be Azure AD, or a federated identity provider like AD FS, and receives an access token in return. That token grants the Word app access to the appropriate content in Office 365.

Conditional access flow

Now let’s have a look at how everything fits together in the what-happens-when-and-where flow for conditional access of the Word app.

WordApp_CA

1. Authenticate user and device – The Word app uses ADAL-based authentication to authenticate the end-user with Azure AD.
A. Not compliant/ registered – When the device of the end-user is not compliant, or not registered, the end-user will receive a message to enroll the device including a link to the Company Portal app.
B. Register device | Enroll device – When the end-user performs the required activities, the device will be registered in Azure AD and the device will be enrolled in Microsoft Intune.
C. Set device management/ compliance status – After the device is enrolled it has to be evaluated by Microsoft Intune to see if it’s compliant with the company policies. When the device is considered compliant, the required properties in Azure AD will be set (DeviceId, isManaged and MDMStatus).
2. Issue access token – When the device is registered and compliant, the Word app gets the access token and the refresh token that are required for accessing the Office 365.
3. Access with AAD token – The Word app provides the access token to Office 365.
4. Access to content provided – Based on the access token Office 365 will provide the end-user with access to the company content in the Word app.

More information

For more information about the Office apps, conditional access and SharePoint Online, please refer to the following links:

The conditional access flow of the Outlook app for iOS and Android

Microsoft_OutlookThis week something completely different, this week I’ll be looking at the conditional access flow of the Outlook app for iOS and Android. By that I don’t mean that I’ll be looking at the high-level decision flow, which is available on TechNet, but more from a component perspective. It will be more of a what-happens-when-and-where flow.

Before I’ll start with the what-happens-when-and-where flow, I think it’s important to first provide a bit of information about Active Directory Authentication Library (ADAL)-based authentication, the Open Authentication (OAuth) protocol and the Outlook Cloud Service in combination with Office 365. These components make the what-happens-when-and-where flow.

ADAL-based authentication

The Outlook app for iOS and Android uses ADAL-based authentication to access Office 365. ADAL-based authentication enables the Outlook app for iOS and Android to use browser-based authentication with Office 365 and facilitates a sign-in with Azure AD. This allows the end-user to sign in directly to the Office 365 identity provider, which can be Azure AD, or a federated identity provider like AD FS, instead of providing credentials directly to the Outlook app for iOS and Android.

OAuth for Office 365

The ADAL-based sign-in enables OAuth for Office 365 accounts. By enabling OAuth it provides the Outlook app for iOS and Android with a secure mechanism to access email without requiring access to end-user credentials. At sign-in, the end-user authenticates directly with the Office 365 identity provider, which can be Azure AD, or a federated identity provider like AD FS, and receives an access token in return. That token grants the Outlook app for iOS and Android access to the appropriate mailbox, in Office 365, of the end-user (via the Outlook Cloud Service).

Outlook Cloud Service

The Outlook app for iOS and Android also uses the Outlook Cloud Service, which is an aggregation service to help the end-user with grabbing email. The Outlook app for iOS and Android uses OAuth for all accounts that support it, which includes Office 365. OAuth provides the Outlook app for iOS and Android with a secure mechanism to access Office 365 and the Outlook Cloud Service without needing the end-user credentials.

Conditional access flow

Now let’s have a look at how everything fits together in the what-happens-when-and-where flow for conditional access of the Outlook app for iOS and Android.

OutlookApp_CA

1. Authenticate user and device – The Outlook app for iOS and Android uses ADAL-based authentication to authenticate the end-user with Azure AD.
A. Not compliant/ registered – When the device of the end-user is not compliant, or not registered, the end-user will receive a message, or an email describing the steps to enroll, or to get compliant.
B. Register device | Enroll device – When the end-user performs the required activities, the device will be registered in Azure AD and the device will be enrolled in Microsoft Intune.
C. Set device management/ compliance status – After the device is enrolled it has to be evaluated by Microsoft Intune to see if it’s compliant with the company policies. When the device is considered compliant, the required properties in Azure AD will be set (DeviceId, isManaged and MDMStatus).
2. Issue access token – When the device is registered and compliant, the Outlook app for iOS and Android gets the access token and refresh token that are required for accessing the Office 365.
3. Access with AAD token – The Outlook app for iOS and Android  will provide the required access token to the Outlook Cloud Service.
4. Verify access token – The Outlook Cloud Service will verify with Azure AD to see if it’s a valid access token. When the access token is valid, the Outlook Cloud Service will get a second level of security token that allows the Outlook Cloud Service to say that it wants to get email on behalf of the end-user.
5. Get company email – The Outlook Cloud Service will get the company email for the end-user from Office 365.
6. Email delivered – The Outlook Cloud Service delivers the company email for the end-user in the Outlook app for iOS and Android.

More information

For more information about the Outlook app for iOS and Android, conditional access and Exchange Online, please refer to the following links:

Conditional Access for PCs – Part III: Exchange Online

Keep in mind that by default modern authentication is disabled on Exchange Online. To enable this please following this guidance.

Two weeks ago I started with this series of blog posts about conditional access for PCs and I started with the requirements for conditional access for PCs. Last week I built onto those requirements by adding the SharePoint Online Policy, and the Compliance Policy, and I finished with showing the end-user experience.

This week, in the third part of this blog series, I’ll also build onto those requirements by adding the Exchange Online Policy and again the Compliance Policy. After those configurations are in place, I’ll also finish, this third part of this blog series, with the end-user experience.

Note: This post shows a few identical configurations as I also mentioned in the second part of this blog series. This allows one to configure the Exchange Online Policy without going through the configuration of the SharePoint Online Policy.

Configuration

The configuration of conditional access for PCs contains two actions. The first action is to configure the Exchange Online Policy and the second action is to configure the Compliance Policy.

Exchange Online Policy

Now let’s start with the first action, which is the configuration of the Exchange Online Policy. This policy is used to manage access to Exchange mail, based on the configured conditions.

The configuration of the Exchange Online Policy is the same for both Microsoft Intune standalone and Microsoft Intune hybrid. The road to the setting might differ, but, in the end, the configuration has to be performed from the Microsoft Intune administration console.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

Exchange_Online_PolicyIn the Microsoft Intune administration console navigate to Policy > Conditional Access > Exchange Online Policy;

To enable the Exchange Online Policy for PCs select at least Enable conditional access policy for SharePoint Online and Windows devices must meet the following requirements and choose, based on the requirements, between Devices must be compliant, Devices must be domain joined or Devices must be domain joined or compliant.

To prevent mail apps with basic authentication from connecting select Require mobile devices to be compliant and choose Block access to email from devices that are not supported by Microsoft Intune. However, this configuration should not be required, as one of the requirements is to also block non-modern authentication protocols in AD FS.

To make sure that the Exchange Online Policy is targeted to users, configure a security group as a Targeted Group and, when there are users that need to be exempted, make sure to configure a security group as an Exempted Group. After saving the policy, it takes effect immediately.

Note: For testing the end-user experience I’ve tested the Exchange Online Policy with all three possible configurations for Windows devices.

Compliancy Policy

The next action 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. A good thing to 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.

The configuration of the Compliance Policy differs between Microsoft Intune standalone and Microsoft Intune hybrid.

Environment Configuration
Microsoft Intune standalone

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

To configure a Compliance Policy for PCs, choose, based on the requirements, between the applicable Password and Encryption settings.

Microsoft Intune hybrid

Compliance_Policy_ConfigMgrIn 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 for PCs, choose, based on the requirements, during the Create Compliance Policy Wizard the Supported Platforms and choose between the applicable Password and Encryption Rules.

Note: If only a Windows desktop platform is selected as a Supported Platform, only the Minimum password length Rule Type will be possible, while the File encryption on mobile device Rule Type also seems to be applicable.

Note: It’s possible to create multiple Compliance Policies for different devices, or different scenarios. After creating the different policies, don’t forget to the deploy the policies to users, or computers.

End-user experience

After the complete configuration is done, it’s time to look at the end-user experience for the Outlook desktop application. In this case I’m talking about the end-user experience of a blocked user, as the end-user experience of an allowed user doesn’t differ from any other Outlook experience.

When the end-users’ device is not compliant, or not joined to the domain, the end-user can get the messages as shown below when Outlook is trying to connect to Exchange Online. The not compliant message will also show when the combined option is configured. The examples are shown for Outlook 2013, but the Outlook 2016 experience is identical.

Not compliant Not domain joined
Outlook2013_Security Outlook2013_Domain

Note: It might take a moment before an existing Outlook connection will be blocked when the device is not longer compliant.

More information

For more information about the Exchange Online Policy and the Compliance Policy, that are used for conditional access for PCs, please refer to the following links:

Conditional Access for PCs – Part II: SharePoint Online

Last week I started with this series of blog posts about conditional access for PCs. I started with the requirements for conditional access for PCs. This week, in the second part of this blog series, I’ll build onto those requirements by adding the SharePoint Online Policy and the Compliance Policy. After those configurations are in place, I’ll finish, this second part of this blog series, with the end-user experience.

Note: This post shows a few identical configurations as I also mention in the third part of this blog series. This allows one to configure the SharePoint Online Policy without going through the configuration of the Exchange Online Policy.

Configuration

The configuration of conditional access for PCs contains two actions. The first action is to configure the SharePoint Online Policy and the second action is to configure the Compliance Policy.

SharePoint Online Policy

Now let’s start with the first action, which is the configuration of the SharePoint Online Policy. This policy is used to manage access to OneDrive for Business files located on SharePoint Online, based on the configured conditions.

The configuration of the SharePoint Online Policy is the same for both Microsoft Intune standalone and Microsoft Intune hybrid. The road to the setting might differ, but, in the end, the configuration has to be performed from the Microsoft Intune administration console.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

SharePoint_Online_PolicyIn the Microsoft Intune administration console navigate to Policy > Conditional Access > SharePoint Online Policy;

To enable the SharePoint Online Policy for PCs select at least Enable conditional access policy for SharePoint Online and Windows devices must meet the following requirements and choose, based on the requirements, between Devices must be compliant, Devices must be domain joined or Devices must be domain joined or compliant.

To make sure that the SharePoint Online Policy is targeted to users, configure a security group as a Targeted Group and, when there are users that need to be exempted, make sure to configure a security group as an Exempted Group. After saving the policy, it takes effect immediately.

Note: For testing the end-user experience I’ve tested the SharePoint Online Policy with all three possible configurations for Windows devices.

Compliancy Policy

The next action 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. A good thing to 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.

The configuration of the Compliance Policy differs between Microsoft Intune standalone and Microsoft Intune hybrid.

Environment Configuration
Microsof Intune standalone

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

To configure a Compliance Policy for PCs, choose, based on the requirements, between the applicable Password and Encryption settings.

Microsoft Intune hybrid

Compliance_Policy_ConfigMgrIn 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 for PCs, choose, based on the requirements, during the Create Compliance Policy Wizard the Supported Platforms and choose between the applicable Password and Encryption Rules.

Note: If only a Windows desktop platform is selected as a Supported Platform, only the Minimum password length Rule Type will be possible, while the File encryption on mobile device Rule Type also seems to be applicable.

Note: It’s possible to create multiple Compliance Policies for different devices, or different scenarios. After creating the different policies, don’t forget to the deploy the policies to users, or computers.

End-user experience

After the complete configuration is done, it’s time to look at the end-user experience for the most common used Office applications. In this case I’m talking about the end-user experience of a blocked user, as the end-user experience of an allowed user doesn’t differ from any other Office experience.

When the end-users’ device is not compliant, or not joined to the domain, the end-user can get the messages as shown below when the end-user is trying to access files on SharePoint Online. The not compliant message will also show when the combined option is configured. The examples are shown for Word 2013, Excel 2013 and PowerPoint 2013. In that order.

Initial Not compliant Not domain joined
Word2013_SignIn Word2013_Security Word2013_Domain
Excel2013_SignIn Excel2013_Security Excel2013_Domain
PowerPoint2013_SignIn PowerPoint2013_Security PowerPoint2013_Domain

Note: At this moment this works perfect for Office 2013. However, with Office 2016 I’m still experiencing some weird behavior with multiple apps, like Word 2016 and PowerPoint 2016. To be continued.

More information

For more information about the SharePoint Online Policy and the Compliance Policy, that are used for conditional access for PCs, please refer to the following links:

Conditional Access for PCs – Part I: Requirements

Another new capability that’s added, during the August 2015 update, to Microsoft Intune, is conditional access for PCs that run Office desktop applications to access Exchange Online and SharePoint Online. This nice capability enables us to require that PCs must be either domain joined or compliant. In order to be compliant, the PCs must be enrolled in Microsoft Intune and the PCs must comply with the policies.

This capability has more requirements and requires more configurations than the most other Microsoft Intune standalone or Microsoft Intune hybrid capabilities. That’s why I decided to make this another blog series. This blog series will contain three parts:

  1. Requirements – This part will list all the requirements and the required configurations to start with the different conditional access scenarios;
  2. SharePoint Online – This part will show the configuration of conditional access for SharePoint Online, including the end-user experience;
  3. Exchange Online – This part will show the configuration of conditional access for Exchange Online, including the end-user experience.

Requirements

Now let’s start with the requirements for conditional access for PCs. The number of requirements depends on the used scenario. The most complicated scenario, of using on-premises ADFS and using being domain joined as the conditional access check, requires all of the following requirements.

Requirement 1 – Operating System

The first requirement, is the easiest the requirement, as it simply requires a specific operating system level. To use conditional access for PCs, Windows 7.0 or later is required.

Requirement 2 – Enable modern authentication in Office

The second requirement is still not really challenging, but it contains two important requirements. To use conditional access for PCs, the Office installation must meet one of the following requirements:

  • Office 2013 is used, including the March 2015 update or later, and modern authentication is enabled. To enable modern authentication, make sure that the following registry keys are set:

    Registry key Type Value
    HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL REG_DWORD 1
    HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version REG_DWORD 1
  • Office 2016 is used;

Requirement 3 – Automatically register device in Azure AD

The third requirement is already more challenging, because it contains multiple configurations that need to be in place. To use conditional access for PCs, a domain joined device needs to be automatically registered in Azure AD. This requires the following three configurations.

Configure an additional Azure AD relying part trust claim rule

  • Open the AD FS Management console;
  • Navigate to AD FS > Trust Relationships
    > Relying Part Trusts;
  • Right-click the Microsoft Office 365 Identity Platform
    trust and select Edit Claim Rules…;
  • Navigate to Issuance Transform Rules and click
    Add Rule… to open the Add Transform Claim
    Rule Wizard
    ;
  • On the Choose Rule Type page, select Send Claims
    Using a Custom Rule
    and click Next;
  • On the Choose Claim Rule page, specify a Claim rule
    name
    , provide the following Claim rule and click
    Finish.
  • c:[Type == “http://schemas.microsoft.com/claims/authnmethodsreferences”]
    => issue(claim = c);

Configure an additional Azure AD relying part trust authentication class

  • Open Windows PowerShell and run the following command;
    Set-AdfsRelyingPartyTrust ` -TargetName "Microsoft Office 365 Identity Platform" ` -AllowedAuthenticationClassReferences wiaormultiauthn

Configure automatic device registration

  • Windows 7 is used and automatic workplace joined is enabled. To enable automatic workplace join, on Windows 7, install the following software package: https://connect.microsoft.com/site1164;
  • Windows 8.1 and later is used and automatic workplace join is enabled. To enable automatic workplace join, on Windows 8.1, make sure that a GPO, like the following, is configured and linked:
    • Open the Group Policy Management console;
    • Navigate to Group Policy Management > Forest:<TheForest> > Domains > <TheDomain>;
    • Right-click Group Policy Objects and select New.
    • Provide a Name and click OK;
    • Right-click the new Group Policy Object and select Edit;
    • Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Workplace Join;
    • Right-click the Automatically workplace join client computers setting and select Edit;
    • Select Enabled and click OK.

Note: There are also required configurations for the ADFS Global Authentication Policy, Internet Explorer and the network connectivity, but those are all considered default.

Requirement 4 – Block non-modern authentication protocols in AD FS

The fourth requirement is the most challenging, at least for me. To use conditional access for PCs, non-modern authentication protocols should be blocked to Office 365. Basically, everything except ActiveSync and browser-based logins should be blocked. A good thing to keep in mind, in this case, is that Outlook uses MAPI/HTTP to connect to Office 365. This can be achieved by making sure that a configuration like the following example is in place (other examples can be found in the linked articles):

  • Open the AD FS Management console;
  • Navigate to AD FS > Trust Relationships > Relying Part Trusts;
  • Right-click the Microsoft Office 365 Identity Platform trust and select
    Edit Claim Rules…;
  • Navigate to Issuance Authorization Rules and click Add Rule… to open the Add Issuance Authorization Claim Rule Wizard;
  • On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next.
  • 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”])
    && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”,
    Value == “Microsoft.Exchange.Autodiscover”])
    && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”,
    Value == “Microsoft.Exchange.ActiveSync”])
    && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”,
    Value == “Microsoft.Exchange.Mapi”])
    && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”,
    Value == “Microsoft.Exchange.Nspi”])
    && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”,
    Value == “/adfs/ls/”])
    => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

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

Note: This example claim rule blocks all the traffic through the proxy unless the context is auto discover, ActiveSync, Mapi, Nspi or a browser.

More information

For more information about the requirements for conditional access for PCs, please refer to the following links:

Multi-identity in the managed Outlook app – Part 2

This blog post will show the behavior of the multi identities in the Microsoft Outlook app, as described in my posts about multi-identity in the managed Outlook app – part 1 and the Microsoft Intune Managed Browser. I’ve made four small movies that will show the behavior of the Microsoft Outlook app. A general note with these movies is that they’ll start to blink and act all funny at the moments that a managed app is opened, or a when a PIN is required.

Part I – Install and configure the Microsoft Outlook app

In this first part I’ll show how the Microsoft Outlook app behaves during the installation and initial configuration. During this movie I’ll go through the following actions:

  • Open the Company Portal app;
  • Install the Microsoft Outlook app;
  • Open the Microsoft Outlook app;
  • Configure the PIN.

Part II – Open URLs in the Microsoft Outlook app

In this second part I’ll show how the Microsoft Outlook app behaves with opening URLs. During this movie I’ll go through the following actions:

  • Open the Microsoft Outlook app;
  • Open a blocked URL from company email;
  • Open an allowed URL from company email;
  • Open an URL from personal email.

Part III – Copy and paste content in the Microsoft Outlook app

In this third part I’ll show how the Microsoft Outlook app behaves with copying and pasting content to different apps. During this movie I’ll go through the following actions:

  • Open the Microsoft Outlook app;
  • Copy content from company email;
  • Paste the content in an unmanaged app;
  • Paste the content in a managed app;
  • Copy content from personal email;
  • Paste the content in any app.

Part IV – Open and save attachments in the Microsoft Outlook app

In this fourth part I’ll show how the Microsoft Outlook app behaves with saving attachments. During this movie I’ll go through the following actions:

  • Open the Microsoft Outlook app;
  • Open an attachment from company email;
  • Save the attachment;
  • Open an attachment from personal email;
  • Save the attachment.

Multi-identity in the managed Outlook app – Part 1

Microsoft_OutlookThis blog post can be seen as a follow up about a previous post about the email profile behavior after retiring a mobile device. During that post I showed the behavior of email profiles in the native mail app and the Outlook app after retiring the mobile device. In this post I’ll dive deeper into the Outlook app. More specifically, the behavior of the managed Outlook app and multi-identities. To be complete, I’ll divide this blog post in two parts. This first part will describe the assumptions, the configuration and the behavior and the second part will show the behavior in a real example.

Assumptions

During this blog post I’ve done four important assumption, about the used environment, that might impact the test results. When these four items are not in place, the results might differ from the results in this blog post. The key is that these four items create a fully managed Outlook app for company email.

  1. Office 365, including Exchange Online, is in place for the company email;
  2. Microsoft Intune hybrid, or standalone, is in place for managing the mobile devices;
  3. Conditional access is used to provide access to the company email;
  4. Application management policies are in place to protect the company email.

Configuration

During this blog post I’ve used the configuration, for the managed Outlook app, as shown in the pictures below. These pictures are taken from a Microsoft Intune hybrid environment, but the settings that can be configured are identical to the settings that can be configured in a Microsoft Intune standalone environment.

iOS Android
iOS_AppManagementPolicy Android_AppManagementPolicy

Behavior

One key takeaway about the behavior is a difference in the behavior of the Outlook app for iOS and the Outlook app for Android.

If a PIN requirement is configured, the Outlook app for iOS will always prompt for a PIN.

It will even prompt for a PIN during the initial startup. On the other hand, if a PIN requirement is configured, the Outlook app for Android will only prompt for a PIN after a company email profile is configured.

Besides that key difference the behavior of the Outlook app for iOS and the Outlook app for Android will be identical. Based on the configured managed application policy the end-user will experience the following behavior.

Setting Company email Personal email
Restrict web content to display in the Managed Browser

The end-user will experience that an URL will open in the Managed Browser.

Note: When the Managed Browser is used with an allow list, the URL has to be part of that list.

The end-user will experience that an URL will open in the default browser.
Prevent Android backups (Android only)1 The end-user will not experience anything special. The end-user will not experience anything special.
Prevent iTunes and iCloud backups (iOS only)1 The end-user will not experience anything special. The end-user will not experience anything special.
Allow app to transfer data to other apps The end-user will experience that data can only be transferred to other managed apps. The end-user will experience that data can be transferred to any other apps.
Allow app to receive data from other apps The end-user will experience that data can be received from all other apps. The end-user will experience that data can be received from all other apps.
Prevent “Save As The end-user will experience that the “Save As” option is missing for attachments. The end-user will experience that the “Save As” option is available for attachments.
Restrict cut, copy, and paste with other apps The end-user will experience that content and attachments can only be copied and pasted to other managed apps. The end-user will experience that content and attachments can be copied and pasted to all other apps.
Require simple PIN for access (including number of attempts before PIN reset) The end-user will experience that a PIN is required for access.

iOS – The end-user will experience that a PIN is required for access.

Android – The end-user will experience that a PIN is not required for access.

Require corporate credentials for access The end-user will experience that corporate credentials are required for access.

iOS – The end-user will experience that corporate credentials are  required for access.

Android – The end-user will experience that corporate credentials are not required for access.

Require device compliance with corporate policy for access The end-user will experience that there is no access when the device is jailbroken (iOS) or rooted (Android). The end-user will experience that there is always access.
Recheck the access requirements after timeout and offline grace period3 The end-user will not experience anything special. The end-user will not experience anything special.
Encrypt app data4 The end-user will not experience anything special. The end-user will not experience anything special.
Block screen capture(Android only) The end-user will experience that the screen capture option can’t be used. The end-user will experience that the screen capture option can be used.

1 This setting would make sure that the backup of the Outlook app is disabled, but, by default, the Outlook app already doesn’t perform online backups.
2 This setting will make sure that the access requirements for the Outlook app are checked again after the specified timeout and grace period.
3 This setting will make sure that all data associated with the Outlook app will be encrypted. On iOS the data is encrypted at rest using the device level encryption of iOS and on Android the data is encrypted during file I/O operations via encryption provided by Microsoft.

More information

For more information about controlling managed apps, please refer to the following links: