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

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 Exchange Online to the max

This week I want to show another look at conditional for Exchange Online. I want to do that by providing a scenario. That scenario will cover more than just conditional access. Mainly because conditional access simply blocks access to non-compliant devices, but what if I want to take it one step further? What if I also want to prevent potential data leakage? In that case I can’t just look at conditional access. In that case I also need to add mobile app management to the playing field. This post will address those subjects for Exchange Online.

Scenario

Now lets start with the scenario that I want to cover. Even though I know that I will use Microsoft Intune and related technologies to do the configuration, I want the scenario to describe functional requirements. The configuration should address the following requirements:

  • Email access is only allowed on managed and compliant devices;
  • Email data leakage must be prevented on managed and compliant devices;
  • Email access is available via the browser;
  • Email access is supported on iOS, Android and Windows 10.

Configuration

Now lets have a look at what I need to configure to address that scenario. The good news is that I can support this scenario with Microsoft Intune. However, the default configuration is not sufficient. I need to get creative. To address this scenario I need to make sure that email access is only available through browsers and apps that can be managed by mobile app management (MAM) policies or by Enterprise Data Protection (EDP)/ Windows Information Protection (WIP). No back doors allowed. That means that to address this scenario I need to add the following technical configurations on top of the standard conditional access and MAM (and WIP):

  • The OWA app for iOS and Android must be blocked;
  • ActiveSync apps that use basic authentication must be blocked;
  • The default browsers on iOS and Android must be blocked.

Block the OWA app

ADFS_DenyOWAThe first thing that I want to configure is a deny for the Microsoft OWA app. That specific app bypasses every form of conditional access. Luckily that doesn’t mean that there is nothing that I can do to block the app. I can use AD FS to deny specific client user agent claims for the Microsoft OWA app. 

The following example claim will deny every active claim that arrives via the AD FS proxy with a client user agent that contains MOWAHost. That should be distinctive enough to only deny the Microsoft OWA app. However, keep in mind that the Microsoft OWA app will only be blocked once it tries to verify the credentials.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/services/trust/2005/usernamemixed”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “MOWAHost”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Block Exchange ActiveSync apps with basic authentication

The second thing I want to configure is a deny on every Exchange ActiveSync app with basic authentication, like the default mail app on iOS and Android. Those apps are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those apps can still leak data. The combination of the following three components allows me to only allow the Microsoft Outlook app, which is capable of working with MAM policies, on mobile devices.

1

ExchangeOnlinePolicy_EASThe first component that I need to address is the Exchange Online Policy for conditional access. I don’t want Microsoft Intune to control the access for the Exchange ActiveSync apps with basic authentication, I want Exchange Online to take care of those apps. Within Exchange Online I’ve got the ability to easily block or allow access to specific device families and models. Microsoft Outlook is available as a device family.

To achieve that Microsoft Intune doesn’t control those apps, I need to make sure that the setting Block non-compliant devices on platforms supported by Microsoft Intune and the setting Block all other devices on platforms not supported by Microsoft Intune are disabled in the conditional access policy for Exchange Online.

2

EA_AccessSettingsThe second component that I need to address are the Exchange ActiveSync access settings. Within these settings I can define the default behavior of Exchange Online when a device isn’t managed by a rule or personal exemption. In this case I want to block access to all mobile devices that are not part of the rule that I will define.

To achieve that every device is blocked when it’s not managed by a rule, I need to configure the Exchange ActiveSync Access settings to Block access.

3

EA_DeviceAccessThe third component that I need to address is the Device Access Rule. With a rule like this I can define which device families and models are allowed, blocked or quarantined. In this case I want to allow access to all mobile devices that use Outlook to connect.

To achieve that all mobile devices that use Outlook are allowed, I need to create a Device Access Rule with the Outlook device family and for All models.

Note: It’s even possible to specifically select Outlook for iOS and Android as model, but at this moment that cannot be enforced.

Block default browsers on iOS and Android

The third thing that I want to configure is a deny on the default browsers on iOS (Safari) and Android (Chrome). Those browsers are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those browsers can still leak data. Luckily that doesn’t mean that there is nothing that I can do to block those browsers.

ADFS_DenySafariDefault browser iOS (Safari)
I can use AD FS to deny specific client user agent claims for the Safari browser. However, the Safari browser is tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Safari. That isn’t only applicable to iOS, but also to Android and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Safari, but doesn’t contain Windows or Android. That should be distinctive enough to deny the Safari browser on iOS devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Safari/”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Windows|Android”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

ADFS_DenyChrome

Default browser Android (Chrome)
I can also use AD FS to deny specific client user agent claims for the Chrome browser. However, the Chrome browser is also tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Chrome. That isn’t only applicable to Android, but also to iOS and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Chrome and Android, but doesn’t contain PKeyAuth or ManagedBrowser. That should be distinctive enough to deny the Chrome browser on Android devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Chrome/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Android”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “PKeyAuth|ManagedBrowser|Windows”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Result

The result is awesome, in my personal opinion. I’ve successfully tested this configurations on iOS, Android and Windows 10 devices with multiple browsers and apps. This configuration, in combination with conditional access and MAM (and WIP), provides the following results:

  • Email access is only available on managed and compliant iOS and Android devices via the Managed Browser and on managed and compliant Windows 10 devices via Internet Explorer and Microsoft Edge. These browsers can be managed via MAM and WIP to prevent data leakage. Other browsers will be blocked by conditional access, or AD FS;
  • Email access is only available on managed and compliant iOS and Android devices via the Microsoft Outlook app on managed and compliant Windows 10 devices via Outlook. These apps can be managed via MAM and WIP to prevent data leakage. Other apps will be blocked by Exchange Online;
  • Known back doors are closed. The OWA app will be blocked by AD FS.

More information

Fore more information about conditional access for Exchange Online and mobile app management, please refer to:

Share

Prevent specific devices from accessing Microsoft Intune

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

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

Construct claim rule

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

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

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

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

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

Configure relying party trust

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

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

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

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

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

End-user experience

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

iPad Mini 2 Nokia Lumia 930
IMG_0037 wp_ss_20160501_0001

More information

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

Share

Conditional access for PCs managed by ConfigMgr

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

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

Introduction

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

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

Configuration

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

Pre-release feature

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

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

Conditional access policy

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

Exchange Online Policy SharePoint Online Policy
CA_ConfigMgr_ExchangeOnline CA_ConfigMgr_SharePointOnline

Compliance policy

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

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

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

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

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

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

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

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

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

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

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

Policy effect

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

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

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

End-user experience

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

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

More information

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

Share

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:

Share

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:

Share

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:

Share

Blog series about how to integrate Microsoft Intune and ConfigMgr with Single Sign-On

A few weeks ago I did a blog post about How to configure a relying party trust between on-premises AD FS and Microsoft Azure AD for single sign-on in Microsoft Intune. Based on that blog post I’ve got a lot of feedback of people mentioning that it was a great post, but that they would like to see the complete picture. That made me decide to create a step-by-step guide for a basic lab setup of Microsoft Intune and ConfigMgr with single sign-on. Starting today the complete series is online on windows-noob. I’ve sliced this guide in to the following four pieces:

  1. How to integrate Microsoft Intune and System Center 2012 R2 Configuration Manager with Single Sign-On – Part 1: Introduction and prerequisites;
    • This first part is about what this blog series will deliver and what the prerequisites are that need to be in place.
  2. How to integrate Microsoft Intune and System Center 2012 R2 Configuration Manager with Single Sign-On – Part 2: Install and configure Active Directory Federation Service;
    • This second part is about installing and configuring AD FS, WAP and single sign-on.
  3. How to integrate Microsoft Intune and System Center 2012 R2 Configuration Manager with Single Sign-On – Part 3: Configure directory synchronization;
    • This third part is about configuring the synchronization of the on-premises user accounts to the Azure AD.
  4. How to integrate Microsoft Intune and System Center 2012 R2 Configuration Manager with Single Sign-On – Part 4: Integrate ConfigMgr and Microsoft Intune;
    • This fourth part is about integrating Microsoft Intune with ConfigMgr to leverage the single sign-on experience.

Available for download

As a small extra for those reading my blog, I’ve also created a PDF that contains the content of this blog series. Starting now this PDF is available for download on the TechNet Galleries.

>> The complete PDF is available via download in the TechNet Galleries! <<

Share

How to configure a relying party trust between on-premises AD FS and Microsoft Azure AD for single sign-on in Microsoft Intune

ADFS_SSOOne of the things that is often requested by customers is to configure single sign-on for Microsoft Intune (with or without ConfigMgr integration). The main reasons for that request are simple, it’s to make the user experience better and to prevent the user from having different accounts and passwords. In this blog post I will show how relatively easy it is to federate on-premises Active Directory Federation Services (AD FS) with the Microsoft Azure Active Directory (Micorosoft Azure AD). The best thing about this is that after this configuration is done, all Microsoft Intune authentication requests will redirect to the on-premises AD FS.

Also, in this post I will skip a few important steps (see prerequisites). I assume that those steps are more common knowledge. If that’s not the case, please let me know.

Prerequisites

A few important installations and configurations should be in place before trying to use the configuration mentioned further in this post. To be able to configure a relying party trust between the on-premises AD FS and the Microsoft Azure AD make sure that following installations and configurations are in place:

Configuration

When all the prerequisites are in place, it’s time to start with creating the federation. In a maximum of six relatively simple steps it is possible to create a relying party trust between the on-premises AD FS and the Microsoft Azure AD. This trust will make sure that the Microsoft Azure AD will trust the authentication response of the on-premises AD FS. The easiest method to create this trust is to use PowerShell. In the following six steps I will name the required cmdlets and explain the actions that it will perform.

  1. The first step is to make sure that the Microsoft Azure Active Directory PowerShell Module is installed.
  2. The second step is to load the cmdlets by either starting Microsoft Azure Active Directory Module for Windows PowerShell, or by importing the module via the following command.
    Import-Module MSOnline

  3. The third steps is to connect to the Microsoft Azure AD (used by Microsoft Intune) by using the cmdlet Connect-MsolService. An easy method to provide the required credentials, to connect to the Micosoft Azure AD, is to use an empty variable. This empty variably will make sure that the cmdlet prompts for the credentials of the Microsoft Intune subscription. Simply use the –Credentials parameter to specify the credentials (parameter) by running a command like the following.
    Connect-MsolService –Credential $cred

  4. (Optional) The fourth step is to connect to the on-premises primary AD FS server by using the cmdlet Set-MsolADFSContext. Simply use the –Computer parameter to specify the name of the on-premises primary ADFS server by running a command like the following.
    Set-MsolADFSContext -Computer cldsrv01.ptcloud.local

  5. The fifth step is to add a new single sign-on domain, also known as an identity-federated domain, to the Microsoft Azure AD by using the cmdlet New-MsolFederatedDomain. This cmdlet will perform the real action, as it will configure a relying party trust between the on-premises AD FS server and the Microsoft Azure AD. Simply use the –DomainName parameter to specify the name of the single sign-on domain by running a command like the following.
    New-MsolFederatedDomain –DomainName petervanderwoude.nl

  6. (Optional) The sixth step is to convert the domain from standard authentication to single sign-on, also known as identity-federated, by using the cmdlet Convert-MsolDomainToFederated.  This cmdlet will perform the real action, as it will convert the domain from standard authentication to single sign-on and also configures a relying party trust between the on-premises ADFS server and the Microsoft Azure AD. Simply use the –DomainName parameter to specify the name of the single sign-on domain by running a command like the following. 
    Convert-MsolDomainToFederated –DomainName petervanderwoude.nl

Note: Step 4 is only required when the cmdlets are not used locally on the AD FS server and step 6 is only required if the new single sign-on domain already exists as a standard authentication domain. In that last case a very clear message stating New-MsolFederatedDomain : The domain already exists as a standard authentication domain.  To convert the domain to identity federation, use convert-MSOLDomainToFederated. will show after performing step 5.

Result

ADFS_exampleAfter setting up the federation with Microsoft Azure AD, every logon to one of the Microsoft Online Services will redirect to the on-premises AD FS when a user name with the UPN of @petervanderwoude.nl is used. This includes Microsoft Intune. For demonstration purposes I can go to https://admin.manage.microsoft.com/ to see if it all works. As soon as I use an user account with the @petervanderwoude.nl UPN, the login page will automatically redirect to the on-premises AD FS server. This way the credentials will be verified on-premises.

Other places to see the successful configuration are in the Account Portal of Microsoft Intune, in the on-premises AD FS configuration and of course via PowerShell by using the cmdlet Get-MsolFederationProperty.

Further reading

A simplified installation guide for single sign-on for Office 365: http://technet.microsoft.com/en-us/magazine/jj631606.aspx

A checklist to use AD FS to implement and manage single sign-on: http://technet.microsoft.com/en-us/library/jj205462.aspx

A scenario about managing identities for single-forest hybrid environments using on-premises authentication: http://technet.microsoft.com/library/dn550987.aspx

Share