Conditional access and named locations

This week another blog post about a recently introduced feature that can be used in commination with conditional access, named named locations. Within conditional access policies, named locations can be used like trusted IPs. The complication with trusted IPs was that it’s actually a feature configuration of multi-factor authentication. That did not really make a lot of sense. In this post I’ll look at the configuration of named locations and how those configurations can be used within a conditional access policy.

A very good scenario for named locations in a conditional access policy is using Office 365 in a terminal services environment. It enables organizations to make an exclusions for a specific named location. In this post I’ll use an example that will blocks access to SharePoint Online with the exception of the configured named location.

Configuration

Now let’s start with having a look at the configuration of named locations and how those named locations can be used within conditional access policies.

Named location

Named locations is a feature of Azure AD that enables administrators to label trusted IP address ranges in their organizations. In the environment, administrators can use named locations in the context of the detection of risk events to reduce the number of reported false positives for the Impossible travel to atypical locations risk event type. However, since recently named locations are also available for use in Azure AD conditional access policies under preview. To create a named location in Azure AD, use the following 3 steps.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Named locations;
2 On the Named locations blade, click New location to open the New blade;
3

CA_NamedLocationOn the New blade, provide a Name and IP range, and click Create;

Note: Even though the example shows that a private IP range is used, for usage with conditional access policies that doesn’t make sense. Use a public IP range. When a device arrives with Azure AD, for authentication, it provides the public IP address to Azure AD (see also the blocked example in the end-user experience section).

Conditional access policy

Using named locations within conditional access policies, is similar to using trusted IPs in conditional access policies. The biggest difference is the location of the configuration. Trusted IPs is a feature configuration of multi-factor authentication, while named locations is a feature configuration of conditional access. To use the configured named location within a conditional access policy, to block all external access to SharePoint Online, follow the 7 steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 CA_UsersGroupsOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 CA_SharePointOnlineOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 SharePoint Online and click Done;
5 CA_ExcludeLocationOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Locations to open the Locations blade. On the Locations blade select Yes with Configure, select All locations on the Include tab, select All trusted IPs in the Exclude tab and click Done. Back in the Conditions blade, click Done;
6

CA_BlockAccessOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select.

Note: This configuration will make sure that all locations are blocked access to SharePoint Online, with the exclusion of the named location. The devices within the named location can now connect to SharePoint Online without any additional requirements.

7 On the New blade, select On with Enable policy and click Save.

End-user experience

As usual, let’s end this post with the end-user experience. Below on the left is an example of a connection to SharePoint Online within the configured named location and below on the right is an example of a connection to SharePoint Online outside of the named location. The blocked example clearly shows the external IP address that’s used to connect to SharePoint Online and that it’s blocked by conditional access.

SP_AllowedAccess SP_BlockedAccess

Note: Yes, the blocked example shows the same IP address, as the named location configuration. To simulate a good test, I simply temporarily adjusted the IP range of the named location. That allowed me to easily test the blocked behavior on my devices.

More information

For more information about conditional access and named locations, please refer to:

Share

Quick tip: View device in Azure Active Directory

This week a quick and short blog post about the feature, in Configuration Manager, to view a device in Azure AD. This is small new feature that was introduced in Configuration Manager 1702 and is mainly used for getting additional information about the compliance state of domain joined devices. Devices managed by a Configuration Manager client. In this post I’ll show the steps to use that feature and I’ll show the provided information.

View device in Azure AD

The feature to view a device in Azure AD, is only available when looking at non-compliant or compliant devices.  This can be achieved by going through the steps below.

1 Open the Configuration Manager administration console and navigate to Monitoring > Overview > Compliance Settings > Compliance Policies;
2 In the Overall Device Compliance overview, click on the Non-Compliant, or the Compliant, section of the donut and the Overall Device Compliance – Non-Compliant, or Overall Device Compliance – Compliant node will show;
3a ViewDevice_SelectOption 1: Select the device and click View Device in Azure Active Directory in the Home tab;
3b ViewDevice_RightOption 2: Right-click the device and click View Device in Azure Active Directory;
4 When the current user is not an administrative user in Azure AD, an additional dialog box will show. Simply provide the credential of an administrative user that has the permissions to view the device information and logon;
5 ViewDevice_AzureADThe View Device in Azure Active Directory dialog box will show. This dialog box provides up-to-date information about the compliance state of the device, including the important property Compliance Expires. That provides the administrator with the information about when the current compliance status expires. 
Share

Conditional access and Google Chrome on Windows 10

This week a short blog post to create some awareness about conditional access for Google Chrome on Windows 10. Starting with Windows 10, version 1703, it’s now possible to use Google Chrome in combination with conditional access. It will no longer simply being blocked. This can be achieved by installing and enabling the Windows 10 Accounts extension in Google Chrome. The screenshot below contains the name and URL of the extension.

Win10AccountsExt

Introduction

The Windows 10 Accounts extension for Google Chrome provides a single sign-on experience, to supported websites, to end-users that have a Microsoft supported identity on Windows 10,. Also, the Windows 10 Accounts extension for Google Chrome is required when the organization has implemented conditional access policies, to get the expected end-user experience. Currently, the Windows 10 Accounts extension for Google Chrome supports Azure AD identities.

End-user experience

Now let’s have a look at the end-user experience on a Windows 10, version 1703, device. I’ll go through the expected end-user behavior, with and without the Windows 10 Accounts extension for Google Chrome.

Chrome_WithOutExt_CAScenario: Google Chrome without the Windows 10 Accounts extension and with a conditional access policy that requires a compliant or domain joined device.

In this scenario, even when the device is complaint or domain joined, the device will be blocked when not using the Windows 10 Accounts extension. In this scenario, the end-user will receive a message that the current browser is not supported.

Chrome_WithOutExtScenario: Google Chrome without the Windows 10 Accounts extension and with a conditional access policy that uses app enforced restrictions on browsers of non-compliant or non-domain joined devices.

In this scenario, even when the device is complaint or domain joined, the device will have a limited experience when not using the Windows 10 Accounts extension. In this scenario, the end-user will receive a message that a limited experience is applied.

Chrome_WithExtScenario: Google Chrome with the Windows 10 Accounts extension and with a conditional access policy that requires a compliant or domain joined device, or with a conditional access that use app enforced restrictions on browsers of non-compliant or non-domain joined devices.

In these scenarios, with the Windows 10 Accounts extension enabled, the end-user experience will be the same as with Microsoft Edge or Internet Explorer. In this scenarios, the end-user will get the full experience.


Note
: The blue Windows-logo is an indication that the Windows 10 Accounts extension is enabled in Google Chrome.

Share

Conditional access and app enforced restrictions

This blog post is about a recently introduced feature in conditional access, named Session controls. More specific, the Session control of app enforced restrictions. Session controls enable a limiting experience within a cloud app. The great thing about Session controls is is that those controls are enforced by the cloud apps and that those controls rely on additional information provided by Azure AD to the cloud app, about the session. In other words, these controls can be used to require Azure AD to pass the device information to the cloud app. This enables the cloud app to know if the user is coming from a (non-)compliant device or (non-)domain joined device.

Currently Session controls are only supported with SharePoint Online as the cloud app. In this post I’ll go through the required configuration to get SharePoint Online configured with conditional access and app enforced restrictions. I’ll end this post with the end-user experience with app enforced restrictions.

Configuration

The administrator can block or limit access to SharePoint Online content on devices that are not managed, not compliant and/or not joined to a domain. To block access, the administrator usually configures one conditional access policy. To limit access, the administrator should configure two conditional access policies and configure a setting in the SharePoint Online. In this section I’ll start with a few important notes and follow that by the required steps to make the earlier mentioned configurations.

Important notes

Before configuring the limited access to SharePoint Online, be sure to be familiar with the  following important notes:

  • A subscriptions to Azure AD Premium is required;
  • A subscription to Microsoft Intune is required;
  • (At this moment) First Release must be enabled in Office 365;
  • Limited access will also apply to users on managed devices, if they use one of the following browser and operating system combinations:
    • Chrome, Firefox, or any other browser other than Microsoft Edge or Microsoft Internet Explorer in Windows 10 or Windows Server 2016;
    • Firefox in Windows 8.1, Windows 7, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2.

Block access to mobile apps and desktop clients

The first configuration to limit access to SharePoint Online, is to block access for mobile apps and desktop clients. These apps will not get the limited experience, which means that these apps should be blocked to prevent users from using company data on non-compliant or non-domain joined devices. To create a conditional access policy that will block access for mobile apps and desktop clients to SharePoint Online, follow the 7 steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access;
2 On the Policies blade, click Add to open the New blade;
3 AP_CA_UsersGroupsOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users, or select Select users and groups to specify a specific group, and click Done;
4 AP_CA_CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 SharePoint Online and click Done;
5 AP_CA_ClientApp_MobileAppsOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps to open the Client apps blade. On the Client apps blade select Yes with Configure, select Select client apps and Mobile apps and desktop clients, and click Select. Back in the Conditions blade, click Done;
6 AP_CA_GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access and at least one of the requirements, and click Select.
7 On the New blade, select On with Enable policy and click Save.

Use app enforced restrictions for browsers

The second configuration to limit access to SharePoint Online, is to enforce restrictions to browsers. This will make sure that browsers will get the limited experiences in SharePoint Online, on non-compliant or non-domain joined devices. To create a conditional access policy that will enforce restrictions for browsers to SharePoint Online, follow the 7 steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access;
2 On the Policies blade, click Add to open the New blade;
3 AP_CA_UsersGroupsOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users, or select Select users and groups  to specify a specific group, and click Done;
4 AP_CA_CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 SharePoint Online and click Done;
5 AP_CA_ClientApp_BrowserOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps to open the Client apps blade. On the Client apps blade select Yes with Configure, select Select client apps and Browser, and click Select. Back in the Conditions blade, click Done;
6 AP_CA_SessionOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Use app enforced restrictions and click Select.
7 On the New blade, select On with Enable policy and click Save.

Allow limited access in SharePoint Online

The third configuration to limit access to SharePoint Online, is a configuration within SharePoint Online. The cloud app must be configured to use limited access for devices that aren’t compliant or domain joined. When the administrator configures limited access, users will be able to view but not edit Office files in SharePoint Online. The Download, Print, Sync, Open in desktop app, Embed, Move to, and Copy to buttons won’t appear in the new SharePoint Online experiences. To configure this limited access, follow the 2 steps below.

1 Open the SharePoint admin center and navigate to device access;
2

SPO_ControlAccessOn the Restrict access based on device or network location page, specify the following information and click OK:

  • In the section Control access from devices that aren’t compliant or joined to a domain, select Allow limited access (web-only, without the Download, Print, and Sync commands) with Select the appropriate SharePoint enforced restriction and choose between Allow downloading and Block downloading with For files that can’t be viewed on the web;
  • In the section Control access from apps that don’t use modern authentication, select Block with The setting applies to third party apps and Office 2010 and earlier.

End-user experience

Now let’s end this post with the end-user experience. I’ll do that by showing the limited access experience on Windows 10 (Surface Pro), iOS (iPad) and Android (Samsung Galaxy). Also in that order. Below are examples of of the limited access message in SharePoint Online on the left and the limited access experience in Word Online on the right.

Windows10_SPO Windows10_SPO_Doc
IMG_0102 IMG_0103
Screenshot_20170409-075823 Screenshot_20170409-081417

More information

For more information about conditional access and app enforced restrictions, please refer to:

Share

Require multi-factor authentication for enrollment

This week’s blog post will continue about conditional access. However, this time I’m going to look at a specific scenario in which conditional access is the key to making it easy to solve. This week I’m going to show three options, well actually only two, for requiring multi-factor authentication (MFA) during the enrollment of a device. First I’m going through the different configuration options and after that I’ll show the end-user experience per configuration option.

Configuration options

Now let’s start by having a look at the different configuration options. When I’m looking at the different configuration options, I want to look a little bit further than just the Microsoft Intune enrollment. I also want to include the Azure AD join, as it’s a common additional configuration. That makes that to require MFA during the enrollment of a device, the following options are available:

  • Require MFA to join Azure AD;
  • Require MFA for Microsoft Intune enrollment;
  • Require MFA for Microsoft Intune enrollment for Windows devices only.

Option 1: Multi-factor authentication to join Azure AD

The first option is to require MFA to join a device to Azure AD. When Microsoft Intune is configured in Azure AD to automatically enroll during the Azure AD join, it’s possible to simply require MFA to join Azure AD. That would require the end-user to use MFA to join and enroll the device. However, the down-side of this configuration is that it’s really specific to Windows devices that can perform an Azure AD join. When other platforms are in the picture, this solution will not be enough to require MFA during every enrollment.

To configure the MFA requirement for joining Azure AD, the Azure portal and the Azure classic portal can be used. Both configuration options are described below.

Azure portal – In the Azure portal the requirement to use MFA to join devices to Azure AD can be configured by using the following steps.

  • In the Azure portal navigate to Azure Active Directory > Users and groups > Device Settings;
  • Select Yes with Require Multi-Factor Auth to join devices and click Save.
AzurePortal_MFA

Azure classic portal – In the Azure classic portal the requirement to use MFA to join devices to Azure AD can be configured by using the following steps.

  • In the Azure classic portal navigate to ACTIVE DIRECTORY > <Tenant>CONFIGURE;
  • Navigate to the section devices;
  • Select YES with REQUIRE MULTI-FACTOR AUTH TO JOIN DEVICES and click SAVE.
AzureClassicPortal_MFA

Note: Not only do both configuration options have the same effect, but both configurations options are stored in the same location. In other words, when this is configured in the Azure portal it will also show in the Azure classic portal and vice versa.

Option 2: Multi-factor authentication for Microsoft Intune enrollment

The second option is to require MFA to enroll a device into Microsoft Intune. This configuration would require the end-user to always use MFA to enroll a device. For every supported platform. The down-side of this configuration is that it’s really specific to Microsoft Intune enrollments. When there are devices that only need to perform an Azure AD join, this solution will not be enough to require MFA during every Azure AD join.

To configure the MFA requirement for enrolling into Microsoft Intune, the Azure portal and the Azure classic portal can be used. Both configuration options are described below.

Azure portal – In the Azure portal the requirement to use MFA to enroll devices to Microsoft Intune can be configured by using the following steps.

  • In the Azure portal navigate to Azure Active Directory > Enterprise applications > All applications > Microsoft Intune Enrollment > Conditional access;
  • Click Add and specify the following:
    • Specify a name to identify the conditional access policy;
    • In the Users and groups assignment, select All users and click Done;
    • In the Cloud apps assignment, Microsoft Intune Enrollment should be preselected;
    • In the Grant control, select Allow access and Require multi-factor authentication and click Select;
    • Click On with Enable policy and click Create.
AzurePortal_CA_MFA

Azure classic portal – In the Azure classic portal the requirement to use MFA to enroll devices to Microsoft Intune can be configured by using the following steps.

  • In the Azure classic portal navigate to ACTIVE DIRECTORY > <Tenant>APPLICATIONS > Microsoft Intune Enrollment > CONFIGURE;
  • Navigate to the section multi-factor authentication and location based access rules;
  • Select ON with ENABLE ACCESS RULES, select Require multi-factor authentication with RULES and click SAVE.
AzureClassicPortal_CA_MFA

Note: In the Azure portal there are multiple roads to eventually create a conditional access. One is as shown above, by starting with the application, and another is by going straight to Azure Active Directory > Conditional access. This is the overview location of conditional access that shows all the created policies. Adding a new policy at this location, only requires an additional actions to select the correct Cloud app.

Option 3: Multi-factor authentication for Microsoft Intune enrollment for Windows devices only

The third option used to be the option to require MFA to enroll a Windows device into Microsoft Intune. That configuration could be done through the Intune Silverlight portal and through the Configuration Manager console. The configuration is even still available in the Configuration Manager console. However, this option should not be used anymore. The advise is to use one of the other two options. This was also the most limiting MFA requirement, as it was only available for Windows devices.

End-user experience

Let’s end this post with a brief look at the end-user experience. It’s hard to point out any differences between the different methods. At least from a look-and-feel perspective. The only difference might be the moment of the MFA prompt. However, that might not even be noticed by a normal end-user. The end-user will simply get a MFA challenge during the authentication and will probably not notice the difference in timing.

In other words, choosing the right option really depends on the scenario that must be addressed. It will not further impact the end-user.

MFA

More information

For more information about multi-factor authentication and conditional access, please refer to:

Share

Conditional access is getting better and better and better

Yeah, I know, I’ve been using similar blog post titles recently. And yes, it might sound cheesy. However, looking specifically at conditional access, it’s easy to say that the current evolution, in the Azure portal, is better than it is in the Azure classic portal, which is better than it is in the Intune Silverlight portal. Based on that, maybe  “The evolution of conditional access” would have been a nice title also. In this post I will go through a little bit of history of conditional access, followed by going through the enhanced capabilities of conditional access in the Azure portal.

Little bit of history

Let’s start by looking at a little bit of history of conditional access. No, I won’t put all the evolutions on a timeline, but I will try to show the biggest changes. Conditional access started as a feature in the Intune Silverlight portal only. In that time it was limited to a few Office 365 services. Later on conditional access also became part of the Azure classic portal and the functionalities got expanded to include other cloud apps and published apps. Very recently conditional access also became part of the Azure portal (still in preview) and the functionalities got expanded to include multiple policies and many, many configuration options. Now let’s go through these evolution in a bit more detail.

Intune Silverlight portal – The Intune Silverlight portal is the portal were it all started for the conditional access functionalities. In the Intune Silverlight portal it’s possible to enable and configure conditional access for the following Microsoft cloud services:

  • Exchange Online;
  • Exchange On-premises;
  • Exchange Online Dedicated (new and legacy);
  • SharePoint Online;
  • Skype for Business Online;
  • Dynamics CRM Online.

Within the conditional access policies it’s possible to configure the following conditions:

  • Platforms (all or specific);
  • Browser (all or supported only);
  • Groups (targeted and/or exempted).
IntuneSilverlight_Example

Azure classic portal – The Azure classic portal is the portal that started with providing more capabilities by making conditional access configurations available as part of Azure AD. In the Azure classic portal it’s possible to configure conditional access for the following additional apps (in addition to the Intune Silverlight portal):

  • Software as a service (SaaS) apps connected to Azure AD;
  • On-premises apps published via the Azure AD Application Proxy.

Within the conditional access policies it’s possible to configure the following additional conditions (in addition to the Intune Silverlight portal):

  • Multi-factor authentication (always, when not at work, block when not at work).
AzureClassic_Example

Azure portal – The Azure portal is still in preview for the Azure AD functionalities. However, the Azure portal is were conditional access becomes  a grown-up functionality. The Azure portal also supports all the mentioned apps from the Azure classic portal and the Intune Silverlight portal. On top of that, it enables the ability to create one policy for all apps, or a policy per app, or even multiple policies per app.

Within the conditional access policies it’s also possible to configure all the mentioned conditions from the Azure classis portal and the Intune Silverlight portal. On top of that, it enables to ability to make every available combination of the available conditions.

Note: The Azure portal even includes the capability to configure conditional access for managed apps. This is part of the Intune mobile app management configuration.

Azure_Example

Note: At this moment all three locations are still available for configuring conditional access. When a conditional access policy is configured at multiple locations, the end-user only gets access when all requirements are met.

Conditional access in the Azure portal

This section is about a preview of the Azure AD management experience in the Azure portal.

Now let’s have a look at the new conditional access experience in the Azure portal and why these changes are really interesting. Let’s do this by going through the different controls and condition statements that are available in the Azure portal.

Policies

The first thing that’s important to know, is that there is no limit anymore in creating conditional access policies for specific apps. The configuration in the Azure portal enables the administrator to create multiple conditional access policies. Not just one per cloud app, but it can even be multiple policies per cloud app. Before every sign-in, Azure AD evaluates all applicable policies and ensures that all requirements are met before granting access to the end-user. Now let’s have a look at adding a policy in more detail.

Policy – When adding a new conditional access policies there are the following 4 sections that can be configured:

  • Name: Every conditional access policy requires a name. That name will be used to identify the policy;
  • Assignments: With assignments the administrator defines the criteria that need to be met, for the controls to be applied, in the form of a condition statement;
  • Controls: With controls the administrator can either block access or allow access. And by allowing access the administrator can also add additional requirements;
  • Enable policy: Every conditional access policy will only be applied when it’s enabled.

Azure_NewPolicy

Assignments

The next thing is to have a look the different assignments that can be part of the condition statement. The assignments can be configured for User and groups, Cloud apps and additional Conditions. When there are multiple assignments configured in the conditional access policy, all assignments are logically ANDed. If there are multiple assignment configured, all assignments must be satisfied.

User and groups – In the User and groups assignment, the administrator can configure to who the conditional access policy must be applied. This can be done by including all users, or by  selecting specific users and/or groups. When specific users must be excluded, that can be configured by adding those users in the exclude section of this assignment. Azure_UsersGroups
Cloud apps – In the Cloud apps assignment, the administrator can configure to what the conditional access policy must be applied. This can be done by including all cloud apps, or by selecting specific cloud apps. When specific apps must be excluded, that can be configured by adding those apps in the exclude section of this assignment. Azure_CloudApps

Conditions – In the Conditions assignment, the administrator can configure how the conditional access must be applied. This can be done by configuring conditions in the following areas:

  • Sign-in risk: In the Sign-in risk condition, the administrator can configure to which risk the conditional access policy must be applied. This can be done by selecting the risk level of High, Medium, Low and No risk;
  • Device platforms: In the Device platforms condition, the administrator can configure to which platforms the conditional access policy must be applied. This can be done by including all platforms, or by selecting specific platforms. When specific platforms must be excluded, that can be configured by adding those platforms in the exclude section of this condition;
  • Locations: In the Location condition, the administrator can configure to which locations the conditional access policy must be applied. The location is identified by the IP address of the device used by the end-user. This can be done by including all locations, or by selecting specific trusted IPs. When trusted IPs must be excluded, that can be configured by selecting those trusted IPs in the exclude section of this condition;
  • Clients apps: In the Client apps condition, the administrator can configure to which apps the conditional access policy must be applied. This can be done by selecting Browser and/or Mobile apps and desktop app.
Azure_Conditions

Controls

Let’s end this post by having a look at the different controls. The controls can be used to either block or allow access. And by allowing access the administrator can, and also must, add additional requirements.

Grant – In the Grant control, the administrator can configure what must be done when the configured conditions happen. This can be done by selecting Block access or Allow access. When the control is used to allow access at least one of the following requirements must be configured:

  • Require multi-factor authentication: The multi-factor authentication requirement can be used to require strong authentication. This can be used in combination with Azure multi-factor authentication, or with an on-premises multi-factor authentication provider (in combination with ADFS);
  • Require compliant device: The compliant device requirement can be used to require a device to be compliant to an additional device compliancy policy. That compliancy policy can be targeted through Microsoft Intune (or any other MDM management solution);
  • Require domain joined device: The domain joined device requirement can be used to require a device to be domain joined to an on-premises AD. The domain join requires automatic registration of the domain joined device in Azure AD.

When multiple requirements are configured in the conditional access policy, the administrator can choose to require all the selected controls or just one of them.

Azure_Grant

Note: Currently, when the control requires multi-factor authentication or a compliant device, the user will be prompted for multi-factor authentication irrespective of the device compliance state.

More information

For more information about conditional access via the Azure portal, the Azure classic portal, or the Intune Silverlight portal, please refer to:

Share

Conditional access for managed apps

After a great MVP Summit and a session at a great Experts Live, it’s finally time for a new blog post. This blog post will be about conditional access for managed apps (MAM CA). About a month ago, I did a first post about this feature when it was still in preview. The good news is that the first part of this feature is now production ready for all tenants. In this post I’ll go through an introduction of MAM CA, the flow of MAM CA, the prerequisites of MAM CA, the configuration of MAM CA and the end-user experience of MAM CA.

Introduction

By now, I think, everybody should be familiar with the mobile app management without enrollment (MAM-WE, previously also referred to as MDM-less MAM) feature. MAM-WE helps with making sure that company data and resources are protected, even though the device is not managed. MAM CA adds an additional layer to that picture. MAM CA helps with making sure that only mobile apps that support Intune MAM policies are allowed to access Office 365 services (for now only Exchange Online). That enables us to allow access to Office 365 services, without the need to require enrollment and only for apps that can be managed.

Flow

Now let’s have a look at the flow that is used by MAM CA, by going through the steps in the picture shown below.

CA_MAMWE

Note: In the above picture CP is referring to the Company Portal app on Android and AA is referring to the Azure Authenticator app on iOS.

  1. Start: The end-user signs in to a managed app;
  2. App Approved?: When the end-user is restricted with MAM CA policies, a check is done to see if it’s an approved app. The approved apps are stored on a list in Azure AD and during the sign-in the app is validated with that list. When the app is not on the list, the end-user will be prompted that it’s not allowed to sign in via the app;
  3. CP/AA Present?: When it’s an approved app, a check is done to see if the broker app is installed on the device. On iOS this is the Azure Authenticator app and on Android this is the Company Portal app. When the broker app is not installed on the device, the end-user will be prompted to install the app;
  4. AAD Registered?: When the broker app is installed, and the end-user is signed in, a check is done to see if the device is registered in Azure AD. When the device is not registered in Azure AD, the end-user will be prompted to register the device.
  5. Approved: When the device is registered in Azure AD, the end-user can access Exchange Online via the managed app.

Note: The device registration in Azure AD will create a device record and certificate against which tokens are issued. There is no management profile installed on the device and there are no policies applied to the device. The device record in Azure AD only contains the alternativeSecurityIds, the deviceOSType, the deviceOSVersion and the displayName properties.

Configuration

After knowing what MAM CA is and knowing how MAM CA works, it’s time to look at the perquisites and the configuration.

Prerequisites

Before starting looking at the configuration, it’s good to be aware of the following prerequisites/ requirements/ limitation.

  • The end-user must be licensed for Enterprise Mobility + Security or Azure Active Directory premium;
  • At this moment MAM CA is only available for Exchange Online;
  • The end-user must install the broker app on their device;
  • MAM CA relies on modern authentication.

Configuration options

Now let’s have a look at the configuration options for MAM CA. The MAM CA polices contain three different configuration sections. These three sections together are the targeted MAM CA policy. Let’s go through these three section and see how they can be used.

1

MAMCA_AllAppsThe first configuration section is Allowed apps. The Allowed apps is used to select the mobile apps for iOS and Android that are allowed to access Exchange Online.

MAMCA_ManagedAppsTo allow apps to connect to Exchange Online the administrator can choose between selecting Allow all apps and Allow apps that support Intune app policies. The latter selection currently contains Skype for Business, Excel, PowerPoint, Word, OneNote, Outlook, Microsoft SharePoint and OneDrive for Android and iOS.

2 MAMCA_RestrUsGrThe second configuration section is Restricted user groups. The Restricted user groups section is used as the targeting mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be restricted by the MAM CA policy, immediately after saving the MAM CA policy.
3 petervanderwoude.nlThe third configuration part is Exempted user groups. The Targeted apps section is used as an exemption mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be exempted from the MAM CA policy, immediately after saving the MAM CA policy.

Additional considerations

An additional consideration for MAM CA is to close the gap for apps that don’t support modern authentication. Without closing that gap, apps that don’t support conditional access might still be able to connect. Let’s go through a method to close that gap.

4

ADFS_ModernAuthAn additional consideration is to use AD FS to block non-modern authentication. This can be achieved in AD FS 2016 by creating an Access Control Policy and assigning it to the Microsoft Office 365 Identity Platform Relying Party Trust.

That Access Control Policy must contain at least a rule to Permit users with Endpoint Path contains (/adfs/ls)|(/adfs/oauth2) in the request. This will make sure that only apps, using modern authentication, can connect to any cloud services that uses the Microsoft Office 365 Identity Platform Relying Party Trust.

End-user experience

After configuring MAM CA, it’s time to have a look at the end-user experience. I’m going to show the end-user experience of an end-user signing in to an approved app. However, before showing that experience it’s good to mention a few important facts about the end-user experience.

  • Every Exchange Active Sync mail client, including the built-in mail clients on iOS and Android, will be blocked. Instead end-users receive an email informing them that they need to use the Outlook mail app (see also this post);
  • If an end-user is targeted with MAM CA and “normal” conditional access (Device CA) policies, the end-user must meet one of the two requirements:
    • The used app is allowed by MAM CA;
    • The used device is managed by Microsoft Intune (hybrid or standalone) and compliant, or it’s a domain-joined PC.

Now let’s have a look at the Microsoft Outlook app and the flow that I described earlier. The end-user signs in to the Microsoft Outlook app and is prompted to install the Azure Authenticator app (see first screenshot). Once the end-user signs in to the Microsoft Outlook app and the Azure Authenticator app is installed, the end-user is prompted to open the Azure Authenticator app (see second screenshot).

Azure Authenticator app not installed Azure Authenticator app is installed
IMG_0098 IMG_0099

After switching to, and signing in to, the Azure Authenticator app, and the device is not registered, the end-user is prompted to register the device (see first screenshot). Once the device is successfully registered, and the end-user is successfully signed in, the end-user will be allowed access and receive the configured MAM policies (see second screenshot).

Device is not registered Device is registered
IMG_0100 IMG_0101

More information

Fore more information about MAM CA and related components, please refer to:

Share

Blocking non-modern authentication is getting easier and easier

This week a short post about blocking non-modern authentication protocols. I’ve already provided many examples throughout the blog post I’ve posted regarding conditional access, but the release of Windows Server 2016 triggered me again. The main reason for that are the the additions to Active Directory Federation Services (ADFS) in Windows Server 2016. The main addition to ADFS, for this cause, is the addition of Access Control Policies.  During this blog post I want to slightly touch that subject, as it’s getting a pretty easy and common addition to the default conditional access policies of Microsoft Intune and Azure AD.

The funny thing is that I’m not even speaking about the ability to block legacy authentication protocols directly on SharePoint Online, which is of course easier compared to using ADFS. However, it’s not a complete solution, at this moment, as it’s not available for Exchange Online. As long as it’s not a complete solution for blocking non-modern authentication, ADFS will stay really important for completely closing conditional access.

Active and passive authentication

Before I’m going to look at Access Control Policies, I think it would be smart to mention something about active versus passive authentication. I’ve been mentioning it a lot, but I’ve never even tried to explain the differences. When I’m mentioning modern authentication, I’m actually referring to passive authentication protocols and when I’m mentioning non-modern authentication, I’m actually referring to active authentication protocols. The main difference between these two are, in a very simplistic way, the following.

  • Passive authentication: Passive authentication uses the browser to do redirects to the identity provider to request a token. The protocol that is used is WS-Federation;
  • Active authentication:  Active authentication uses direct connection to request a token and login. In this case the protocol that is used is WS-Trust.

Access Control Policies

ADFS now supports the use of Access Control Policy templates. By using Access Control Policy templates, an administrator can enforce policy settings by assigning the policy template to a relying party or a group of relying parties. The administrator can make updates to the policy template and the changes will be applied automatically to the relying parties.

Access Control Policy templates replace the old model where administrators had to configure issuance authorization rules using claims language. The old PowerShell cmdlets of issuance authorization rules still apply but it is mutually exclusive of the new model. Administrators can choose to either  use the new model or use the old model. The new model allows administrators to easily control when to grant access, including enforcing multi-factor authentication.

Access Control Policy templates use a permit model. This means that by default no one has access and that access must be explicitly granted. However, this is not just an all or nothing permit. Administrators can add exceptions to the permit rule. Within a rule, of an Access Control Policy, if an administrator selects multiple conditions, they are of an AND relationship. Actions are mutually exclusive and for one policy rule an administrator can only choose one action. If the administrator selects multiple exceptions, they are of an OR relationship.

Configuration options

With all this information it’s time to look at some policy rule examples. Let’s say that I want to permit everything on the intranet and block legacy apps on the Internet. That can be configured in a pretty easier manner, without really getting in to the claims language. There are two different methods to achieve the same result. Both methods start with a rule Permit users from intranet network. Let’s look at the second rule for both of them.

  • Permit everything except active authentication: In this approach I use a second rule Permit users from Internet network except with Endpoint Path equals /adfs/services/trust/2005/usernamemixed in the request. This can be achieved by selecting from specific network and with specific claims in the request in the rule editor.
  • Permit only passive authentication: In this approach I use a second rule Permit users from Internet network and with Endpoint Path contains (/adfs/ls)|(/adfs/oauth2) in the request. This can be achieved by selecting from specific network and with specific claims in the request in the rule editor.
Except active authentication Permit passive authentication
ADFS_ACP01 ADFS_ACP02

More information

Fore more information about Active Directory Federation Services and active versus and passive authentication, please refer to:

Share

Conditional access for managed apps (preview)

This blog post is about an Azure preview feature. A preview may include preview, beta, or other pre-release features, services, software, or regions. Previews are subject to reduced or different service terms. In other words, previews are for early testing and should not be considered as fully production ready.

During the session Secure access to Office 365, SaaS, and on-premises apps and files with Azure AD and Intune, at Microsoft Ignite, a nice new feature for mobile app management without enrollment (MDM-less MAM) was shown. That new feature is conditional access for managed apps. During that session they showed the URL to that new feature. What makes it even better, that specific URL already works with existing tenants. It simply brings the administrator to a public preview feature.

During this blog post I’ll provide some information about this new feature, I’ll go through the currently available configuration options of this new feature, I’ll show the end-user experience with this new features and I’ll provide my first impression with this new feature.

Information

This new feature will enable an administrator to restrict access to Exchange Online and SharePoint Online so that access can come only from managed apps such as Outlook, Word, Excel, PowerPoint and OneDrive. This new feature also pairs up perfectly with Intune mobile app management (MAM) policies, as it enables the administrator to block access to built-in mail clients or other apps that have not been configured with the Intune MAM policies.

During my first tests with this new feature I noticed that on iOS the Microsoft Authenticator app is required and on Android the Microsoft Intune Company Portal app is required.

Configuration in the Azure portal

Now let’s have a look at the configuration of this new feature. The conditional access policies are configured through the Azure portal, just like the MDM-less MAM policies. I’ll first go through the different configuration options followed by the basic step-by-step configurations.

Different configuration options

The conditional access policies in the Azure portal, contain three different configuration sections. These three sections together are the targeted conditional access policy. Let’s go through these three sections and see how they fit together.

1

CA_EXOThe first configuration section is Allowed apps. The Allowed apps is used to select the mobile apps for iOS and Android that are allowed to access Exchange Online and SharePoint Online.

CA_SPOAt this moment, Outlook is the only selectable app for iOS and Android with Exchange Online. For SharePoint Online there are more selectable apps. It has the option of Skype for Business, Excel, PowerPoint, Word, OneNote and Outlook for iOS and Android, Microsoft SharePoint, OneDrive for iOS only and OneDrive for Android only.

2 CA_RestrUsGrThe second configuration section is Restricted user groups. The Restricted user groups section is the same for Exchange Online and SharePoint Online. It must be used as the targeting mechanism for the conditional access policy. Every available group in Azure AD can be selected here.
3 CA_ExUsGrThe third configuration part is Exempted user groups. The Targeted apps section is the same for Exchange Online and SharePoint Online. It can be used as an exemption mechanism for the conditional access policy. Every available group in Azure AD can be selected here.

Basic steps

After getting familiar with the different configuration options, it’s time to look at the creation and the targeting of a conditional access policy. The following 10 straight forward steps will guide anyone through the configuration and targeting.

1 Open the Azure portal via this link and navigate to Intune mobile application management > Settings to open the Settings blade;
2 In the Settings blade, click Exchange Online to open the Exchange Online blade;
3 In the Exchange Online blade, click Allowed apps to open the Allowed apps blade;
4 In the Allowed apps blade, select the allowed apps.
5 Back in the Exchange Online blade, click Restricted user groups to open the Restricted user groups blade;
6 In the Restricted user groups blade, click Add user group to open the Add user group blade;
7 In the Add user group blade, select an user group and click Select to save the changes and to return to the Restricted user groups blade.
8 (Optional) Back in the Exchange Online blade, click Exempt user groups to open the Exempt user groups blade;
9 (Optional) In the Exempt user groups blade, click Add user group to open the Add user group blade;
10 (Optional) In the Add user group blade, select an user group and click Select to save the changes and to return to the Exempt user groups blade.

Note: The same steps are applicable to the configuration for SharePoint Online. The only real difference is the selection of SharePoint Online instead of Exchange Online.

End-user experience

Now it’s time to have a look at the end-user experience. When an end-user is targeted with a conditional access policy for managed apps and the end-users wants to use one of the blocked apps, the end-user will get the messages below after providing company credentials. The first message will show after adding a company email account to the native mail client and the second message will show after using a blocked app.

Native mail client Blocked app
IMG_0088 IMG_0089

First impressions

My first impressions of this new feature are mixed, from a great addition to leaving room for improvements. The idea of blocking apps that are not managed is great and is something that would be an awesome addition to the product. Especially when looking specifically at MDM without enrollment. However, at this moment it’s not blocking everything. There are three section that I can see a need for improvement:

  1. Only the native mail client on Android and iOS is blocked with Exchange Online. Other mail apps, not using modern authentication, are a hit-miss exercise;
  2. Only apps using modern authentication are blocked with SharePoint Online. Other apps can still connect and sync data;
  3. Browser access is not blocked.
Share

Conditional access for published ConfigMgr reports

This week another post about the world of conditional access in Azure AD. Last week I started with looking at conditional access for Yammer. This week I’ll add-on to that idea by publishing a custom application, in this case my ConfigMgr reports, and apply conditional access to that configuration. To make it even better, it even allows a single sign-on configuration. In other words, I can use pre-authentication on Azure AD and use that token for the single sign-on experience of the end-user in the published application. Really nice!

Prerequisites

Before starting with the configuration, it’s important to know that his post does require two important prerequisites to be in place, which are not part of this post.

  1. Azure AD Application Proxy: This component is used for publishing an on-premises application. The steps to enable the Azure AD Application proxy are documented here;
  2. Windows Authentication: This is required to be able to use single sign-on in combination reporting services. The steps to configure Windows authentication on the report server are documented here.

Configuration

The configuration of conditional access, with single sign-on, for ConfigMgr reporting services contains four steps. The first step is to add the application, the second step is to configure the application, the third step is to enable device access rules and the fourth step is to configure the compliance policy.

Step 1: Add an application

Let’s start with the first step, which is publishing an application that will be accessible outside my network. This requires that the Azure AD Application Proxy is enabled and installed. The publishing of the application can be done via the Azure portal and the Azure Management portal. At this point I’m still using the Azure Management portal, as I can’t do every required configuration via the Azure portal, yet.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

In the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS and click ADD;

To publish the ConfigMgr Web Portal, select Publish an application that will be accessible from outside your network and provide the following information.

  • AzureADApp_CRNAME: [Specify a unique name for the published application]
  • INTERNAL URL: [Provide the internal ConfigMgr Web Portal URL]
  • PREAUTHENTICATION METHOD: Azure Active Directory

Step 2: Configure the application

The second step is to configure the application with a single sign-on experience for the end-user. As I’m using pre-authentication on Azure AD, to enable the option for conditional access, I don’t want to require the end-user to provide the credentials again. That’s why I want to configure single sign-on for the published application.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

In the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS > [New application] > CONFIGURE;

To enable single sign-on for the ConfigMgr Web Portal, provide at least the following information.

  • AzureADApp_CRAuthINTERNAL AUTHENTICATION METHOD: Integrated Windows Authentication
  • INTERNAL APPLICATION SPN: [Provide the internal SPN]
  • DELEGATED LOGIN IDENTITY: User principal name

Step 3: Enable device access rules

The third step is to configure the application with a conditional access experience for the end-user. As the application is now configured with pre-authentication on Azure AD, it’s a small step to enable a device access rule, which is enabling conditional access. That will make sure that all access attempts, from a device that doesn’t meet the configuration, will be denied.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

In the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS > [New application] > CONFIGURE;

To enable conditional access for the ConfigMgr Web Portal, switch ENABLE ACCESS RULES to ON and select with APPLY TO the users which the rules should apply.

AzureADApp_CRCATo make sure that all the devices must be compliant to access the ConfigMgr Web Portal, make sure to configure the applicable platforms with DEVICE RULES and click SAVE.

Note: With custom applications this configuration will be enforced for browsers and native applications.

Step 4: Configure compliance policy

The fourth and last step, an optional step, is to configure a compliance policy in Microsoft Intune standalone and Microsoft Intune hybrid. This configuration part hasn’t changed and is still the right addition to require additional settings on a device. A compliance policy defines the rules and settings that a device must comply with in order to be considered compliant. 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. 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

CustomApp_MISIn 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 available Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Device Security Settings, Jailbreak and Operating System Version settings.

Microsoft Intune hybrid

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

CustomApp_MIHTo 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, Device Security Settings, 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 configurations of adding the application, enabling the device access rules and configuring the compliance policy, it’s time to look at the end-user experience. This time I’ll go through all the common scenario’s that the end-user can end up with. Starting with the initial configuration of the application in Azure AD. Once the application is created in Azure AD and the end-user tries to access them without being licensed, or without being assigned to the application, the end-user can expect the messages shown below.

Not licensed Not assigned
IMG_0080 IMG_0083

Once the end-user is licensed and is assigned to the application, the end-user reaches the conditional access checks of Azure AD. When the device of the end-user is not enrolled, or not compliant, the end-user can expect the messages shown below.

Not enrolled Not compliant
IMG_0079 IMG_0082

Once the end-user has the device enrolled and compliant, the end-user reaches the published application. In this case the ConfigMgr reports. When the end-user has no permissions within the ConfigMgr reports, the end-user will still be able to sign-in. However, the end-user will receive a message, as shown below, about missing the necessary permissions. When the end-user has the required permissions, the end-user will be able to browse through the reports as shown below.

No permissions All requirements met
IMG_0081 IMG_0084

Note: During my tests I’ve upgraded from SQL Server 2014 to SQL Server 2016. Even though SQL Server 2016 looks much better, my mobile devices like to display the reports from SQL Server 2014 much more. In other words, I could simply display my reports when using SQL Server 2014 and my reports wouldn’t display information when using SQL Server 2016. The permission setup works in both configurations.

More information

For more information about conditional access, applications in Azure, compliance policies in Microsoft Intune and Windows authentication for reporting services, please refer to:

Share