Enterprise Mobility End to End // Part 5 – Define Access Conditions


In Part 5 we will focus on Conditional Access, Device Health Attestation and Multi Factor Authentication. Think about a combination of device health status (example: secure boot is enabled) and a location (example: outside of corp network) where you have the option to build powerful access condition policies and enforce MFA when needed. We recommend to have a clear strategy when you want to enforce an additional factor of authentication. If you followed the Blog so far, you have already a second factor authentication using Passport and Hello, adding Azure MFA is your 3 level of authentication. Don’t get crazy, your users will hate you and not adopt the solution if you over-engineer.

something only you know – Passport Pin + something only you are – Face or Iris + something only you have – Phone

Set-Up Conditional Access Using Configuration Manager with Intune (Hybrid)

With the move to cloud services and BYOD, organizations are looking for secure and effective solutions to protect data while enhancing user productivity and device flexibility. Tenant administrators can leverage conditional access policies to prevent users on non-compliant devices from accessing an O365 service, and to better protect Office 365 content that is accessed from these devices.

A typical flow for conditional access might look as follows:


Conditional access can be used to manage access to the following services:

  • Microsoft Exchange On-premises
  • Microsoft Exchange Online
  • Exchange Online Dedicated
  • SharePoint Online
  • Skype for Business Online

But the main purpose of this document is to define conditional access in relation to Office 365 Exchange Online for Windows 10 desktop and Mobile devices.

 

Prerequisites 

  • O365 subscription. The O365 subscription is for setting up Exchange Online, SharePoint Online and Skype for Business Online. Having O365 subscription will automatically give you an Azure AD
  • A Microsoft Intune Subscription. The Microsoft Intune Subscription should be configured in Configuration Manager and Devices should be enrolled to Intune except domain joined PC’s
  • Register the device in Azure Active Directory (this happens automatically when the device is enrolled with Intune)
  • Azure AD Connect to extend the on-premises directory to Azure AD (For managed PC’s)
  • Have activated email, which associates the device’s Exchange ActiveSync ID with the device record in Azure Active Directory (applies to iOS and Android devices only).
  • For Skype for Business Online you need to also enable the modern authentication. Fill this connect form to be enrolled in the modern authentication program. Plus, all your end-users must be using Skype for Business Online. If you have a deployment with both Skype for Business Online and Skype for Business on-premises, conditional access policy will not be applied to end-users. (Currently, applies only to iOS and Android devices).

The PCs must meet the following requirements:

  • Currently support only Exchange Online and SharePoint Online
  • Support for Exchange On Premise Conditional access will only be applicable if the device is Intune enrolled
  • Windows 10 build (build 10551 or newer) for devices
  • Automatic device registration with Azure Active Directory for Domain Joined PC
  • For BYOD PC’s, you must register your device to Azure AD by either adding Work Account or doing an Azure AD joined directly during Out of the Box Experience.
  • Office 365 Modern Authentication enabled on the tenant level.
  • If using Office 2013, it should have the latest office updates with modern authentication enabled (thru registry settings)
  • If Office 2016, modern authentication is already enabled by default.

You can also block access to Exchange email on the following platforms:

  • Android 4.0 and later, Samsung Knox Standard 4.0 and later (Built-in Native Mail client and Outlook App)
  • iOS 7.1 and later (Built-in Native Mail client and Outlook App)
  • Windows Phone 8.1 and later (Built-in Native Mail client and Outlook App)
  • The Modern
    Mail Application on Windows 8.1 Desktop and later

Note:
Outlook App for iOS and Android is NOT supported for Exchange On-Premise Conditional Access.The OWA apps for iOS and Android are not supported. They should be blocked through ADFS claims rules.

You can control access to SharePoint Online from the following apps for the listed platforms:

  • Microsoft Office Mobile (Android)
  • Microsoft OneDrive (Android and iOS)
  • Microsoft Word (Android and iOS)
  • Microsoft Excel (Android and iOS)
  • Microsoft PowerPoint (Android and iOS)
  • Microsoft OneNote (Android and iOS)

The device state is stored in Azure Active Directory which grants or blocks access to email, based on the evaluated conditions.

If a condition is not met, the user will be presented with one of the following messages when they log in:

  • If the device is not enrolled, or registered in Azure Active Directory, a message is displayed with instructions about how to install the company portal app and enroll
  • If the device is not compliant, a message is displayed that directs the user to the Intune web portal where they can find information about the problem and how to remediate it.
  • For a PC:
    • If the policy is set to require domain join, and the PC is not domain joined, a message is displayed to contact the IT admin.
    • If the policy is set to require domain join or compliant, then the PC does not meet either requirement, a message is displayed with instructions about how to install the company portal app and enroll.

Note:
Configuration Manager conditional access rules override, allow, block and quarantine rules that are defined in the Exchange Online admin console.

Enable Modern Authentication

Customers are asking for stronger authentication mechanisms and for better capabilities in controlling access to Office 365 services. Some customers want to enforce Multi-Factor Authentication outside of their network perimeter, require Smartcard authentication, or simply do not want to transmit their credentials (username/password) to Microsoft.

To respond to these needs, Office 365 services and clients are gradually updated to support new authentication flows, enabling “Modern Authentication” scenarios for Office 365 rich clients such as:

  • Multi-Factor Authentication support;
  • Smartcard and certificate-based authentication;
  • Claim-based authentication support (Basic Authentication no longer mandatory for Outlook);
  • Support for 3rd party SAML-based identity providers.

Office 365 Service Enablement

The Office 365 tenant/resource host (Exchange Online, SharePoint Online and Skype for Business Online) will need to be configured to accept a modern authentication connection. The table below summarizes Modern Authentication enablement status, for each workload:

Office 365 Service

Status

Detail

SharePoint Online Enabled on all tenants  No additional back-end activation needed.
Modern Auth flows are automatically enabled through the use of compatible clients.
Exchange Online Disabled by default Admin must enable the tenant for Modern Authentication
Suitable to production
deployments.
Skype for Business Disabled by default Admin must request tenant enablement with public preview:  http://aka.ms/PublicPreview
Yammer Enabled on all tenants No additional back-end activation needed.
Modern Auth flows are automatically enabled through the use of compatible clients.

Exchange Online: Modern Authentication TENANT Enablement

  1. Connect to Exchange Online using remote PowerShell: https://technet.microsoft.com/library/jj984289(v=exchg.160).aspx 
  2. Check the current status of your tenant
  •  Get-OrganizationConfig | fl OAuth2ClientProfileEnabled
  1. Run the following command:
  • Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true
  • Verify that the change was successful by running the following:
    • Get-OrganizationConfig | fl OAuth2ClientProfileEnabled

Office Client Modern Authentication Enablement

Modern authentication is already enabled for Office 2016 clients; you do not need to set registry keys for Office 2016. For Office 2013 client’s modern authentication is not enabled by default.

To enable modern authentication for any devices running Windows (for example on laptops and tablets), that have Microsoft Office 2013 installed, you need the following:

  1. You will need the latest Office 2013 update or at least March 2015 update patch described here: March 2015 Office Update Release
  2. Set the following registry keys. The keys have to be set on each device that you want to enable for modern authentication:


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

Once you have set the registry keys, you can set Office 2013 devices apps to use multifactor authentication (MFA)
with Office 365.

Block Non-Modern Authentication Client

Currently, apps that do not use modern authentication must be blocked access by using other methods, because they are not enforced by conditional access. This is primarily a consideration for Exchange and SharePoint access, as previous app versions have been built using older protocols.

Important:
If your organization is using Active Directory Federation Services (AD FS) for Client Access Filtering and have the scenario as describe in the table below and you enable modern authentication on your O365 Tenant, Rich Clients (Outlook and other Office apps) will be able to bypass your client access filtering policies and in ADFS access resources like Exchange Online and SharePoint online.

Current client access filtering policy

After enabling modern authentication

Action needed

1 Block all external access to Office 365 except Browser-based apps Implement conditional policies in Office 365/Azure AD to block “Rich Client” traffic (allow on ADFS). This scenario is not yet supported for public preview and we recommend organizations that rely on this scenario to not onboard their tenants for modern authentication.

 

The reason it will the bypass the Client Access filtering of ADFS is because the rich clients will now become browser based authentication unlike before the client sends basic authentication credentials over SSL to Exchange Online.  Exchange Online will proxy this authentication request to the customer’s AD FS server on behalf of the client, through this endpoint.

  • 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 Rule.

  • 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


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

Exchange Online: This Claim Rules will block ALL the traffic through the proxy unless the context is Autodiscover, ActiveSync, or Browser (Modern Auth).

If you don’t want to allow the native mail clients and only allow the Outlook App in the mobile devices, you can remove this line from the claim rule: “&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.Autodiscover”])”

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-endpoint-absolute-path”, Value == “/adfs/ls/“])

=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Note:

SharePoint Online

Legacy protocols can be disabled at SharePoint, by using the Set-SPOTenant cmdlet. This cmdlet will prevent Office clients using non-modern authentication protocols from accessing SharePoint Online resources.
Set-SPOTenant -LegacyAuthProtocolsEnabled $false

Configure Conditional Access Policy

Conditional Access Policy Vs Compliance Policy

Conditional Access Policy is a requirement configuration if you want to set certain conditions to a group of users to access a particular service like Exchange Online or SharePoint Online. Within this conditions you can choose either the devices must be domain joined or complaint or both.

Compliance Policy is an additional set of rules that you can add to complement the conditional access policy. If you selected the compliance policies that you want the device to evaluate like Encryption or PIN, they must meet those policies during evaluation in order to be tag as Compliant be allow to access a particular service if the policy set in Conditional access should be Compliant.

Note: Compliance Policy is not mandatory. If you didn’t specify any Compliance Policy but have set Conditional Access Policy, all devices will be evaluated as Complaint and will be allow to access the service you have defined.

To setup conditional access, you must first create a compliance policy and configure conditional access policy. When you configure conditional access policies for PCs you can require that the PCs be compliant with the compliance policy in order to access Exchange Online and SharePoint Online services or Domain Joined.

 

Enable the Exchange Online policy

  • In the Configuration Manager console, click Assets and Compliance
  • Expand Compliance Settings, expand Conditional Access, and then click Exchange Online.
  • On the Home tab, in the Links group, click Configure Conditional Access Policy in the Intune Console. You might need to provide the user name and password of the account used to connect Configuration Manager with any global administrator for the Intune service.
  • In the Microsoft Intune administration console, click Policy > Conditional Access > Exchange Online Policy.
  • On the Exchange Online Policy page, select Enable conditional access policy for Exchange Online. If you check this, the device must be compliant or domain joined, depend on your chosen condition. If this is not checked then conditional access is not applied.


Note: If you have not deployed a compliance policy and then enable the Exchange Online policy, all targeted devices are reported as compliant. Regardless of the compliance state, all users who are targeted by the policy will be required to enroll their devices with Intune.

  • Under Outlook and other apps using modern authentication, you can choose to restrict access only to devices that are compliant for each platform. Windows devices must either be domain joined, or be enrolled in Intune and compliant.


Note: Modern Authentication brings Active Directory Authentication Library (ADAL)-based sign in to Office clients.

The ADAL based authentication enables Office clients to engage in browser-based authentication (also known as passive authentication). To authenticate, the user is directed to a sign-in web page.

This new sign-in method enables new scenarios such as, conditional access, based on device compliance and whether multi-factor authentication was performed.

  • Using Exchange Online with Configuration Manager and Intune, you can not only manage mobile devices with conditional access, but also desktop computers as well. PCs must either be domain joined, or be enrolled in Intune and compliant.


    You can set the following requirements:

    • Devices must be domain joined or compliant. PCs must either be domain joined or compliant with the policies set in Intune. If a PC does not meet either of these requirements, the user is prompted to enroll the device with Intune.
    • Devices must be domain joined. PCs must be domain joined to access Exchange Online. If a PC is not domain joined, access to email is blocked and the user is prompted to contact the IT admin.
    • Devices must be compliant. PCs must be enrolled in Intune and compliant. If a PC is not enrolled, a message with instructions on how to enroll is displayed.

Note: If you want to enforce Compliance Policy for Managed PC to meet certain conditions like Require registration in Azure Active Directory,

All required updates installed with a deadline older than a certain number of days,
Require BitLocker drive encryption,
Require Antimalware before it can access the Exchange Online and SharePoint Online, You must select the Devices must be compliant option.

  • Under Outlook web access (OWA), you can choose to allow access to Exchange Online only through the supported browsers: Safari (iOS), and Chrome (Android) or Manage Intune Browser. Access from other browsers will be blocked. The same platform restrictions you selected for Application access for Outlook also apply here.


    For Android devices, users must enable the browser access. To do this the end-user must enable the “Enable Browser Access” option on the enrolled device as follows:

  1. Launch the Company Portal app.
  2. Go to the Settings page from the triple dots (…) or the hardware menu button.
  3. Press the Enable Browser Access button.
  4. In the Chrome browser, sign out of Office 365 and restart Chrome.

On iOS and Android platforms, to identify the device that is used to access the service, Azure Active Directory will issue a Transport layer security (TLS) certificate to the device. The device displays the certificate with a prompt to the end-user to select the certificate as seen in the screenshots below. The end-user must select this certificate before they can continue to use the browser.



  • Under Exchange ActiveSync mail apps, you can choose to block email from accessing Exchange Online if the device is noncompliant, and select whether to allow or block access to email when Intune cannot manage the device.


  • Under Targeted Groups, select the Active Directory Security Groups of users to which the policy will apply.


Note: For users that are in the Targeted groups, the Intune polices will replace Exchange rules and policies.
Exchange will only enforce Exchange allow, block and quarantine rules, and Exchange policies if:

  • The user is not licensed for Intune.
  • The user is licensed for Intune, but the user does not belong to any security groups targeted in the conditional access policy.

  • Under Exempted Groups, select the Active Directory security groups of users that are exempt from this policy. If a user is in both the targeted and exempted groups, they will be exempt from the policy and will have access to their email.


  • When you are finished, click Save.

Note:

  • You do not have to deploy the conditional access policy; it takes effect immediately.
  • After a user creates an email account, the device is blocked immediately.
  • If a blocked user enrolls the device with Intune (or remediates noncompliance), email access is unblocked within 2 minutes.
  • If the user un-enrolls their device, email is blocked after about 6 hours.

Configure Compliance Policy

When you are configuring Compliance Policy for Exchange Online, you can choose different requirement before you allow access:

  • Devices must be domain joined or compliant
  • Devices must be domain joined
  • Devices must be compliant

If you want to enforce Compliance Policy for Managed PC to meet certain conditions before it can allow access to Exchange Online like:

  • Require registration in Azure Active Directory– This rule checks if the user’s device is work-place joined to Azure AD, and if not, the device is automatically registered in Azure AD. Automatic registration is only supported on Windows 8.1. For Windows 7 PCs, deploy an MSI to perform the auto registration
  • All required updates installed with a deadline older than a certain number of days – This rule checks to see if the user’s device has all required updates (specified in the Required automatic updates rule) within deadline and grace period specified by you, and automatically install the any pending required updates. 
  • Require BitLocker drive encryption – This is a check to see if the primary drive (e.g. C:\) on the device is BitLocker encrypted. If BitLocker encryption is not enabled on the primary device access to email and SharePoint services is blocked.
  • Require Antimalware – This is a check to see if the antimalware software (System Center Endpoint Protection or Windows Defender only) is enabled and running. If it is not enabled, access to email and SharePoint services is blocked.

You must select Devices must be compliant option and that is very important as other configuration would make a domain joined PC enough to be compliant.


In Configuration Manager, we also currently have two types to configure Compliance Policy for Windows PC.


  1. For Windows PC that are BYOD only MDM managed, meaning this is WITHOUT Configuration Manager client installed. (Compliance policies for devices managed by Microsoft Intune)
  2. For Windows PC that are domain joined and WITH Configuration Manager client installed. (Compliance policies for PCs managed by System Center Configuration Manager)

Compliance Rules for devices managed WITHOUT the Configuration Manager client (MDM managed)

(Compliance policies for devices managed by Microsoft Intune)

Rule Windows 8.1 and Windows 10 Windows Phone 8.1 and later iOS 6.0 and later Android 4.0 and later Samsung KNOX Standard 4.0 and later
PIN or password configuration Remediated Remediated Remediated Quarantined Quarantined
Device encryption N/A Remediated Remediated (by setting PIN) Quarantined Quarantined
Jailbroken or rooted device N/A N/A Quarantined (not a setting) Quarantined (not a setting) Quarantined (not a setting)
Email profile N/A N/A Quarantined N/A N/A
Minimum OS version Quarantined Quarantined Quarantined Quarantined Quarantined
Maximum OS version Quarantined Quarantined Quarantined Quarantined Quarantined
Device Health Attestation (1602 update) Setting is not applicable to Windows 8.1
Windows 10 and Windows 10 Mobile are Quarantined.
N/A N/A N/A N/A

Remediated = Compliance is enforced by the device operating system (for example, the user is forced to set a PIN). There is never a case when the setting will be noncompliant.

Quarantined = The device operating system does not enforce compliance (for example, Android devices do not force the user to encrypt the device). In this case:

  • The device will be blocked if the user is targeted by a conditional access policy.
  • The company portal or web portal will notify the user about any compliance issues.
  1. In the Configuration Manager console, click Assets and Compliance.
  2. In the Assets and Compliance workspace, expand Compliance Settings, and then click Compliance Policies.
  3. On the Home tab, in the Create group, click Create Compliance Policy.


  4. On the General page of the Create Compliance Policy Wizard, specify the following information:


  5. On the Supported Platforms page, choose the device platforms that this compliance policy will be evaluated on, or click Select all to choose all device platforms.


  6. On the Rules page, you define one or more rules that define the configuration that devices must have in order to be evaluated as compliant. The following table shows the available rules. When you create a compliance policy, some rules are enabled by default, but you can edit or delete these.

You can now restrict access to email and 0365 services based on the health of the devices as reported by the Health Attestation Service. Additionally, devices managed by Intune are included in the device health reports.

Note: Not all rules will be applicable to Windows PC, there are some only applicable to Mobile devices. Please check: Manage device compliance policies in System Center Configuration Manager



Note:
Require devices to be reported as healthy” is only applicable to Window 10 PC and Windows 10 Phone. If you need to enable this capability, look on the Appendix section.

Require devices to be reported as healthy (1602 update) You can set a rule to require that Windows 10 devices must be reported as healthy in new or existing Compliance Policies. If this setting is enabled, Windows 10 devices will be evaluated via the Health Attestation Service (HAS) for the following data points:
– BitLocker is enabled
When BitLocker is on, the device is able to protect data that is stored on the drive from unauthorized access, when the system is turned off or goes to hibernation. Windows BitLocker Drive Encryption encrypts all data stored on the Windows operating system volume. BitLocker uses the TPM to help protect the Windows operating system and user data and helps to ensure that a computer is not tampered with, even if it is left unattended, lost, or stolen. If the computer is equipped with a compatible TPM, BitLocker uses the TPM to lock the encryption keys that protect the data. As a result, the keys cannot be accessed until the TPM has verified the state of the computer.

– Code integrity is enabled

Code integrity is a feature that validates the integrity of a driver or system file each time it is loaded into memory. Code integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrator privileges.

– Secure boot is enabled

When Secure Boot is enabled, the system is forced to boot to a factory trusted state. Also, when Secure Boot is enabled, the core components used to boot the machine must have correct cryptographic signatures that are trusted by the organization that manufactured the device. The UEFI firmware verifies this before it lets the machine start. If any files have been tampered with, breaking their signature, the system will not boot.

– Early-launch antimalware is enabled (this setting only applies to PCs.)

Early launch anti-malware (ELAM) provides protection for the computers in your network when they start up and before third-party drivers initialize. This rule is turned off by default.

For information on how the HAS service works, see Health Attestation CSP.

Deploy Compliance Policy Intune managed PC’s

  1. In the Configuration Manager console, click Assets and Compliance.
  2. In the Assets and Compliance workspace, expand Compliance Settings, and then click Compliance Policies.
  3. On the Home tab, in the Deployment group, click Deploy.
  4. In the Deploy Compliance Policy dialog box, click Browse to select the user collection to which to deploy the policy.


  5. Additionally, you can select options to generate alerts when the policy is not compliant, and also to configure the schedule by which this policy will be evaluated for compliance.
  6. When you are done, click OK.

Compliance Rules for devices managed WITH the Configuration Manager client

(Compliance policies for PCs managed by System Center Configuration Manager)

Note: Beginning in version 1602 of Configuration Manager, you can configure conditional access for PCs managed by System Center Configuration Manager.

For now, Conditional access for managed PCs is a pre-release feature, by default it is currently Turn Off. You must manually turn it ON.

Note:
Pre-release features are included in the product for early testing in a production environment, but should not be considered production ready.

Important:

Conditional access for PCs and Windows 10 Mobile devices with apps using modern authentication is not currently available to all Intune customers. If you are already using these features in Intune, you do not need to take any action. You can continue to use them.

This does not apply to PCs or Windows 10 Mobile devices for conditional access to Exchange On-premises.

If you have not created conditional access policies for PCs or Windows 10 Mobile for apps using modern authentication, you will need to submit a request for access. You can find out more information about known issues as well as how to get access to this feature at the connect site.

  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.


  1. Once you have turned On the feature, Login to your Intune Portal, click Policy > Conditional Access > Exchange Online Policy and Set the Windows PC requirement to Devices must be compliant
    option.

  2. Go back to the Configuration Manager console, click Assets and Compliance.
  3. In the Assets and Compliance workspace, expand Compliance Settings, and then click Compliance Policies.
  4. On the Home tab, in the Create group, click Create Compliance Policy.


  5. On the General page of the Create Compliance Policy Wizard, fill the Name and Select the option Compliance rules for devices managed with Configuration Manager client.


  6. On the Supported Platforms page, choose the device platforms that this compliance policy will be evaluated on, or click Select all to choose all device platforms.


  7. On the Rules page, you define one or more rules that define the configuration that devices must have in order to be evaluated as compliant. The following table shows the available rules. When you create a compliance policy, some rules are enabled by default, but you can edit or delete these.



  8. On the Summary page of the wizard, review the settings you made, and then complete the wizard.

Deploy Compliance Policy for SCCM manage PC’s

  1. In the Configuration Manager console, click Assets and Compliance.
  2. In the Assets and Compliance workspace, expand Compliance Settings, and then click Compliance Policies.
  3. On the Home tab, in the Deployment group, click Deploy.
  4. In the Deploy Compliance Policy dialog box, click Browse to select the user collection to which to deploy the policy.

    Additionally, you can select options to generate alerts when the policy is not compliant, and also to configure the schedule by which this policy will be evaluated for compliance.

  5. When you are done, click OK.

Note: To get the detailed information about the compliance of the managed PC, the end-user can use the Device compliance section in Software Center.

References:
Health attestation for System Center Configuration Manager
Manage access to O365 services for PCs managed by System Center Configuration Manager

Manage access to services in System Center Configuration Manager

Manage device compliance policies in System Center Configuration Manager

Enabling Device Health Attestation (DHA)

Administrators can view the status of Windows 10 Device Health Attestation in the Configuration Manager console. This functionality is available for Configuration Manager and Configuration Manager with Microsoft Intune. Device health attestation lets the administrator ensure that client computers have the following trustworthy BIOS, TPM, and boot software configurations enabled.

Note: DHA rules for Conditional Access are currently only supported via Hybrid configuration and not yet for full client on premise and these DHA rules cannot be configured individually yet even for hybrid. Meaning
it should enable and meet the four parameters to declare the device as healthy: Early-Launch Antimalware, BitLocker, Secure Boot, and Code Integrity


Requirements:

  • Client devices running Win10
  • TPM 2 enabled (requires UEFI Firmware)
  • The Configuration Manager client agent must be enabled to communicate Health Attestation service

How to enable Health Attestation service communication on Configuration Manager client computers

  1. In the Configuration Manager console, go Administration > Overview Client Settings. for Computer Agent settings.


  2. In the Default Settings dialog box, select Computer Agent and then scroll down to Enable communication with Health Attestation Service


  3. Set Enable communication with Health Attestation Service to Yes, and then click OK.

How to view Health Attestation

  1. To view the device health attestation in the Configuration Manager console, go to the Monitoring workspace, click Security node, and then click Health Attestation.


  2. To view the Device Health Attestation Reports in the Configuration Manager console, go to the Monitoring >Overview > Reporting > Device Management and select List of devices by Health Attestation State



  3. Device Health Attestation is displayed.

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

Reference:
https://technet.microsoft.com/en-us/library/mt651779.aspx
https://technet.microsoft.com/en-us/library/mt629503.aspx

Conditional access effect on the managed PC

If you have set your Conditional Access to allow Domain Joined or Complaint Devices, then ALL domain joined machines will be automatically granted to set up or access their Outlook client that are modern authentication enabled. But for non-domain joined machines it should meet the compliance policy set by the organization as shown below:

  1. Launch the Office Outlook Application. Click Next


  2. Select Yes and Click Next


  3. Enter your email address and password, click Next


  4. It will try to search your mailbox setting


  5. Once it found your mailbox settings, a browser based authentication will prompt and will ask you to re-enter your credentials.


  6. If your device is not yet enrolled to Intune MDM, it will ask you to enroll first your device and should meet the compliance policy settings set by your organization.


Note:
If the organization decided to block the legacy client or non-modern authentication client, it will not let you to set up your Outlook client or if you have existing account already it will keep on prompting to enter your credentials and will disconnect your outlook even you have entered you credential correctly.



Evaluate the effect of conditional access

Run the Conditional Access Compliance Report. It can be found in Monitoring section under Reports >Compliance and Settings Management. This displays the compliance status for all devices. Devices that are reported as not compliant will be blocked from accessing Exchange Online and SharePoint Online.

Note: The optional Exchange Server connector is optional and connects Configuration Manager to Microsoft Exchange Online and helps you monitor device information through the Configuration Manager console (see How to Manage Mobile Devices by Using Configuration Manager and Exchange). You do not need to use the connector to use compliance policies or conditional access policies, but is required to run reports that help evaluate the impact of conditional access.


 

Conditional Access Block Time

Microsoft Intune standalone

Below is the overview table for Microsoft Intune standalone.

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

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

Configuration Manager with Intune hybrid

Below is the overview table for Microsoft Intune hybrid.

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

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

Set-Up Per-Application Access Rules (Conditional Access based on Location and MFA)

You can apply multi-factor authentication rules to all users that are assigned to the application, or only for users within specified security groups. With conditional access based on application sensitivity, you can set multi-factor authentication (MFA) access rules per application, that provides the ability to block access for users who are not on a trusted network. Users may be excluded from the multi-factor authentication requirement if they are accessing the application from an IP address that in inside the organization’s network. 

Conditional Access rules are supported across various Azure AD application types. This list includes:

  • Federated applications from the Azure AD application gallery
  • Password SSO applications from the Azure AD application gallery
  • Applications registered with the Azure Application Proxy
  • Developed line of business and multi-tenant applications registered with Azure AD
  • Visual Studio Online
  • Azure Remote App
  • Dynamics CRM
  • Microsoft Office 365 Yammer
  • Microsoft Office 365 Exchange Online
  • Microsoft Office 365 SharePoint Online (includes OneDrive for Business)

Note:
These capabilities will be available to customers that have purchased an Azure Active Directory Premium license and Federated or managed Azure Active Directory tenant

  1. Sign in to the Azure classic portal Using an account that is a global administrator for Azure AD.
  2. On the left pane, select Active Directory.
  3. On the Directory tab, select your directory.


  4. Select the Applications tab.


  5. Select the application that the rule will be set for.
  6. Select the Configure tab.


  7. Enable the policy by selecting Enabled to be On.
  8. Specify the Group of Users the rule will apply to or you can select ALL Users
  9. Scroll down to the access rules section. Select the desired access rule.

    Access rule options
    The current preview supports the following options:

  • Require multi-factor authentication: With this option the users that the access rules apply to will be required to complete multi-factor authentication before accessing the application the policy applies to.
  • Require multi-factor authentication when not at work: With this option a user that is coming from a trusted IP address will not be required to perform multi-factor authentication. The trusted IP address ranges can be configured on the multi-factor authentication settings page or by using configuring public IP address ranges on the directory Configure tab.
  • Block access when not at work: With this option a user that is not coming from a trusted IP address will be blocked. The trusted IP address ranges can be configured on the multi-factor authentication settings page.

If you have decided to configure Trusted IPs, select either:


  • For requests from federated users originating from my intranet – All federated users who are signing in from the corporate network will bypass multi-factor authentication using a claim issued by AD FS.
  • For requests from a specific range of public IPs – enter the IP addresses in the boxes provided using CIDR notation. For example: xxx.xxx.xxx.0/24 for IP addresses in the range xxx.xxx.xxx.1 – xxx.xxx.xxx.254, or xxx.xxx.xxx.xxx/32 for a single IP address. You can enter up to 50 IP address ranges.

Reference:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access/
https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access-azuread-connected-apps/
https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-access-supported-apps/

Set-Up Azure Multi-Factor Authentication (MFA)

What is multi-factor authentication?

Multi-factor authentication, also commonly referred to as two-factor authentication, is a best practice for securing user access. It works by requiring any two or more of the following authentication factor:

  • A knowledge factor: something only you know (typically a password or a PIN).
  • A possession factor: something only you have (a trusted device that is not easily duplicated).
  • An inherence factor: something only you are (biometrics).

Azure MFA helps to deliver strong security via a range of easy authentication options. Thus, in addition to entering a username and password during sign in, enabled users are also required to authenticate with a mobile app on their mobile device or via an automated phone call or a text message, allowing these users to choose the method that works best for them. Consequently, in order for an attacker to gain access to a user’s account, they would need to know the user’s login credentials AND be in possession of the user’s phone. Furthermore, support for the above multiple methods enables to support more scenarios such as offline (no carrier) scenarios.

Azure MFA exists in different flavors:

  • Azure MFA stand-alone.
  • Included in Azure AD Premium (see below).
  • A subset of Azure MFA functionality included in Office 365 for both administrators and users.
  • Free for Azure administrators.

Whilst Azure MFA is powered by a cloud service, the stand-alone version and well as the one included in Azure AD Premium support on-premises, cloud, and hybrid scenarios. The following solutions are indeed available for use with Azure MFA:

  • Adding Multi-Factor Authentication to Azure AD. Azure MFA works with any applications that use the Azure AD directory tenants. As such, Azure MFA can be rapidly enabled for Azure AD identities to help secure access:
    • The Azure management portal,
    • Microsoft Online Services like Office 365, Intune, and Dynamics CRM Online, etc.
    • Any custom LOB, third-party multitenant cloud-based, or modern business applications that integrate with Azure AD for authentication,
    • As well as thousands of cloud SaaS applications like Box, GoToMeeting, Salesforce.com and others.

    Users will be prompted to set up additional verification the next time they sign in.

  • Enabling Multi-Factor Authentication for on-premises applications and Windows Server. The Multi-Factor Authentication Server works out-of-the-box with a wide range of on-premises applications, such as remote access VPNs, web applications, virtual desktops, single sign-on systems and much more. This includes:
    • Microsoft products and technologies like Microsoft VPN/RRAS, Remote Desktop Services and Remote Desktop Gateway, Universal Access Gateway, SharePoint, Outlook Web Access, etc.
    • As well as third party VPNs and virtual desktop system.

Multi-Factor Authentication Server allows the administrator to integrate with IIS authentication to secure Microsoft IIS web applications, RADIUS authentication, LDAP authentication, and Windows authentication.

Multi-Factor Authentication Server can be run on-premises on your existing hardware – as a virtual machine (VM) or not -, or in the cloud for instance as an Azure Virtual Machine. Multiple, redundant servers can be configured for high availability and fail-over.

  • Building Multi-Factor Authentication into custom applications. A Software Development Kit (SDK) is available for use for direct integration with custom cloud-based and on-premises applications. It enables to build Multi-Factor Authentication phone call and text message verification into the application’s sign-in or transaction processes and leverage the application’s existing user database.

Note:    This applies only to browser-based applications. Multi-Factor Authentication is not supported by non-browser applications, excepted with Office 365 ProPlus/Office 2013 applications with modern authentication enabled. Modern authentication is available to any customer running the March 2015 or later update for Office 2013 but is disabled by default. Office 2016 is already enabled by default.

For the other non-browser-based applications, an app password must be created. An app password is a password that allows to by-pass the Multi-Factor Authentication (more information on this later in this document). Eventually, app passwords are only available to users that do not have administrative privileges.

Configuring Azure AD for Multi-Factor Authentication

This section illustrates how to enable the Multi-Factor Authentication for Azure AD. The steps below assume you already have an Azure subscription with your Active AD directory tenants.

Note: Adding an Azure Multi-Factor Auth Provider is used to take advantage of features provided by the full version of Azure MFA. It is for users who do not have licenses through Azure MFA, Azure AD Premium, or EMS. Azure MFA, Azure AD Premium, and EMS include the full version of Azure MFA by default. If you have licenses then you do not need an Azure Multi-Factor Auth Provider.

To enable existing users for Multi-Factor Authentication, proceed with the following steps:

  1. From the Azure management portal, click ACTIVE DIRECTORY on the left pane.
  2. Under DIRECTORY, click the directory tenant for the user you want to create, for example Fabrikam Corporation as illustrated here.
  3. At the top, click USERS.
  4. In the tray at the bottom, click MANAGE MULTI-FACTOR AUTH. A new tab opens up with the multi-factor authentication page.


This page allows you to enable and disable Multi-Factor Authentication for users in your directory tenant. This also allows you to force users to provide their contact methods again, and reset application password.

  1. Change the view at the top to find the user(s) that you wish to enable for multi-factor authentication. From the View drop down select Sign-in allowed users.


  2. Check the box next to the users to enable for MFA, for example “Janet Schorr
    JanetS@corpfabrikam.onmicrosoft.com” as illustrated here.


  3. Click Enable on the right. This opens up a pop-up that specifies the next steps you need to take with your users.


  4. Review the content, and then click enable multi-factor auth.
  5. Click close.


Note:    As previously noticed, non-browser apps do not have built-in support for interactive prompts that are required by Multi-Factor Authentication. More specifically, in the context of Office 365, this applies to clients such as Outlook, Lync, Word, Excel, PowerPoint, PowerShell, SkyDrive Pro, Exchange ActiveSync (EAS), POP, and IMAP clients, etc. unless the Office 2013/2016 is already using modern authentication.

When you enable Multi-Factor Authentication for such an Office 365 user account, they will be able to use non-browser apps, such as Outlook, Lync, etc., until they have completed multi-factor enrollment or their account status is set to Enforced. In order to continue to use non-browser apps, they must create app passwords for these apps. An app password, is a password that allows them to by-pass the Multi-Factor Authentication and continue to use their non-browser apps. It is advised that you send them an email that informs them how they can use their non-browser apps and consequently not be locked out.

To allow Office 365 users the ability to create app passwords to enable non-browser apps access, proceed with the following steps:

  1. At the top of the multi-factor authentication page, click service settings.


  2. Ensure that the radio button next to Allow users to create app passwords to sign into non-browser applications is selected.
  3. Close the multi-factor authentication page.

Conversely, if you do not wish to enable non-browser apps access with app passwords for Multi-Factor Authentication-enabled users, this functionality can be disabled by selecting Do not allow use of app passwords (users enabled for multi-factor auth will not be able to sign in to non-browser applications) in the above step 2.

Using Multi-Factor Authentication with Azure AD

Once you have enabled the user account(s) for multi-factor authentication, the user(s) can sign-in and complete the enrollment process. This section walks you through the initial logon process, illustrating how to complete the enrollment process of Multi-Factor Authentication for a user.

To complete the enrollment process of the Multi-Factor Authentication, proceed with the following steps:

  1. Open an InPrivate browsing session and navigate to http://aka.ms/MFASetup. You will now be redirected to the login page.


  2. Click Use another account and sign-in with your user’s organizational account, for example as JanetS@corpfabrikam.onmicrosoft.com in our illustration. Because Multi-Factor Authentication has been enabled for this user, you are asked to configure it. This step is required the first time after Multi-Factor Authentication has been enabled for a user.


  3. Click Set it up now.


  4. From the Step 1: Specify the contact method we should use by default page, ensure Mobile phone is selected in the first drop-down.
  5. In the second drop down for the country or the region, select your country.
  6. Enter your mobile phone number in the textbox next to the country drop down.
  7. Under Mode, select Call me. Alternatively, you can select Send me a code by text message. The steps will be slightly different.
  8. Click next.


  9. From the Step 2: Let’s make sure that we can reach you on your Mobile Phone page, click verify now.
  10. When you receive the call, answer, press # and hang-up. When Multi-Factor Authentication is provided through a phone call, the user will always press # to proceed with the authentication.


  11. Click next.


  12. From the Step 3: Apps like Microsoft Office will need new passwords for this account page, click I don’t use this account with these apps.

To login with a configured account, proceed with the following steps:

  1. At the login screen, your organizational account is already entered, for example JanetS@corpfabrikam.onmicrosoft.com as illustrated here.
  2. Enter the password, click Sign In.


  3. When your phone rings, answer, press # and hang up.

Note:    While your preferred authentication method is the default, you can also choose to authenticate using any of the other authentication methods you have configured by selecting the Other authentication methods link.

Configuring the Multi-Factor Authentication mobile application

To configure the Multi-Factor Authentication mobile application, proceed with the following steps:

  1. From the application store on your phone, find and install the app Multi-Factor Authentication. As previously mentioned, this app is available for Windows Phone, iOS, and Android.
  2. Once the Multi-Factor Authentication mobile app has been downloaded and is installed, you can activate it for multiple accounts.
  3. Open an InPrivate browsing session and navigate to the Access Panel at https://account.activedirectory.windowsazure.com/profile.
  4. Sign-in with your organizational account, for example “ztestuser5@corpfabrikam.onmicrosoft.com” as illustrated here.


  5. Click ADDITIONAL SECURITY VERIFICATION.


  6. Check the box to enable Multi-Factor Authentication app.


  7. Click configure.


  8. Switch to your mobile device
  9. Open
    the Multi-Factor Authentication application.
  10. In the mobile app, click New (+).

Note: The interface will differ slightly between mobile OS apps.

  1. Either scan the barcode, or enter the information manually. Upon scanning the barcode or entering the information, you should then see a 6-digit authentication code for the directory.
  2. Switch back to the Access Panel.
  3. Click done.
  4. Notice the checking activation status message. Wait for this to read “Mobile app has been configured” before continuing.


Note: You have now activated your mobile application for Multi-Factor Authentication.

  1. Under what’s your preferred option? from the drop down, select Notify me through app.
  2. Click save.


Note: In order to use a new Multi-Factor Authentication process, you must first verify the process is working.

  1. Click verify preferred option.
  2. Switch to your mobile device. When prompted, click verify.


  3. Click close.
  4. Close your browsing session.

To login with the Multi-Factor Authentication mobile app, proceed with the following steps:

  1. Open an InPrivate browsing session and navigate to the Access Panel at https://account.activedirectory.windowsazure.com/profile.
  2. Sign-in with your organizational account, for example “JanetS@corpfabrikam.onmicrosoft.com” as illustrated here.


  3. When the Multi-Factor Authentication mobile app notifies you of the authentication attempt, click Verify from the mobile app.
  4. The sign in completes. Close the browsing session.

Managing the user settings

To manage the user settings, proceed with the following steps:

  1. Open an InPrivate browsing session and navigate to the Azure management portal at https://manage.windowsazure.com.
  2. Sign-in with your administrative credentials. To sign-in with your organizational account, select Sign in with your organizational account and logon and enter your credentials (username and password).
  3. On the left pane, click ACTIVE DIRECTORY.
  4. Under DIRECTORY, click the directory tenant for the user(s) you want to manage.
  5. At the top, click USERS.
  6. In the tray at the bottom, click MANAGE MULTI-FACTOR AUTH. A new tab opens up with the multi-factor authentication page.
  7. Find the user that you wish to manage and place a check in the box located next to the name. As before, you may need to change the view at the top.


    This will bring up two options on the right: Enable and Manage user settings.

  1. Click Manage User settings. This brings up an eponym pop-up that allows you to select the following user settings in the event a machine or device is lost or stolen:


  • Require selected users to provide contact methods again. This setting forces the user to complete the enrollment process again when they sign-in. Non-browser apps (such as Outlook, Lync, etc.) will continue to work if they have app passwords associated with them unless the setting below is also selected.
  • Delete all existing app passwords generated by the selected users. This setting deletes all of the app passwords that were created by the selected Office 365 users. Non-browser apps (such as Outlook, Lync, etc.) that were associated with these app passwords will cease to work until a new app password is created.

  1. Place a check in the desired boxes and click save.
  2. Close the browsing session

To manage the contact information and set preferred and backup contact methods from an end-user perspective, proceed with the following steps:

  1. Open a browser session and navigate to https://account.activedirectory.windowsazure.com/proofup.aspx.
  2. Sign-in with your organizational account, for example “JanetS@corpfabrikam.onmicrosoft.com” as illustrated here. This will take you directly to the additional security verification page.

You can add or update your contact information and set preferred and backup contact methods using this page.

Note:    You will only be able to edit your office phone number using this page if you are a global or user admin and your account is not being synchronized with the Azure AD directory tenant.

App Password for Non-browser based apps.

App passwords can initially be created when you complete the enrollment process. This said, and as previously mentioned, users can create app passwords later on if they have already completed the enrollment process but have not setup app passwords:

  • App passwords are 16-character randomly generated passwords that, once generated, allow users who are enabled for Multi-Factor Authentication to sign-in with non-browser apps like Outlook, Lync, etc. that are not yet modern authentication enabled.
  • App passwords are used in place of the regular user account password.
  • App passwords are system-generated, and cannot be manually entered by end-users. They will only be displayed once, upon creation.
  • App passwords do not automatically expire, but can be revoked anytime by end-users or an administrator.
  • A user can create up to 40 app passwords and can tag them with names indicating their use.

To add app passwords after having completed the enrollment process, proceed with the following steps:

  1. From the additional security verification page, click app passwords at the top.


  2. Click create. A Create app password dialog brings up.


  3. In Name, enter a name for the app password, for example “Office 365 ProPlus for my laptop” as illustrated here, and then click next.


  4. Click copy password to clipboard to copy the generated password, and then click close.


    You should see your app password on the app passwords page.

  5. Now, paste the app password that was copied to the clipboard into the non-browser app, such as Outlook to login.

Reference:

This Blog post was published by the authors
Lutz Seidemann (Architect) and Raymond Michael Sy Guan (Consultant). We both with Microsoft Consulting Services – Worldwide Enterprise Mobility Center of Excellence (CoE).

Disclaimer: The information on this site is provided “AS IS” with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.


Comments (1)

  1. New whitepaper: Controlling Access to Office 365 and Protecting Content on Devices with EMS https://www.microsoft.com/en-us/download/details.aspx?id=53317

Skip to main content