Device compliance based on custom configuration baselines

This week is all about the new feature to include a custom configuration baselines as part of a compliance policy assessment. That’s a new feature that is introduced in Configuration Manager, version 1910. That will also make this a followup on the post I did earlier this year about using the power of ConfigMgr together with Microsoft Intune to determine device compliance. This will be added functionality, as it’s now possible to make custom configuration baselines part of the device compliancy check. For both, Configuration Manager managed devices and co-managed devices. Even when the workload is switched to Microsoft Intune.

Introduction

This option that makes it possible to use a custom device configuration baseline part of a compliancy policy, opens up a whole new world of possibilities. Especially when knowing that this can also be used when co-managing devices. This enables organisations to create a custom device configuration baseline for specific business requirements that cannot be captured by using the default functionalities that are available for Configuration Manager and Microsoft Intune.

This provides a lot of flexibility for devices that are either managed by Configuration Manager, or that are co-managed by using a combination Configuration Manager and Microsoft Intune. In the latter scenario, that even still provides that flexibility when the compliance policies workload is switched to Microsoft Intune. In that case Microsoft Intune can be configured to take the ConfigMgr compliance assessment result as part of the overall compliance status. The info gets sent to Azure AD and can be used for conditional access. In this post I’ll show how to correctly configure the device compliance policy, the configuration baseline and (optionally) the Configuration Manager compliance.

Before starting with the different configurations it’s good to keep in mind that if the compliance policy evaluates a new baseline that has never been evaluated on the client before, it may report non-compliance at first. This occurs if the baseline evaluation is still running when the compliance is evaluated.

Configure device compliance policy

The first configuration that should be in place is the device compliance policy. The device compliance policy is used to determine the compliance status of the device. Within the device compliance policy, a new rule is available that will enable the evaluation of configuration baselines as part of the compliance of the device. The following steps walk through the creation of a new device compliance policy including the required rule. The device compliance policy can be deployed like any other device compliance policy.

  1. Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies
  2. Click Create Compliance Policy to open the Create Compliance Policy Wizard
  3. On the General page, provide the following information and click Next
  • Name: Provide a valid name for the compliance baseline
  • Description: (Optional) Provide a description for the compliance baseline
  • Select Compliance rules for devices managed with Configuration Manager client
  1. On the Supported Platforms page, select Windows 10 and click Next
  1. On the Rules page, perform the following actions and click Next
  • Click New to open the Add Rule dialog box
  • On the Add Rule dialog box, select Include configured baselines in compliance policy assessment and click OK
  1. On the Summary page, click Next
  2. On the Completion page, click Close

Configure configuration baseline policy

The second configuration that should be in place is the configuration baseline policy. The configuration baseline policy is used to configure, or verify, specific configuration on a device. Within a configuration a new settings is available that will make the evaluation of the configuration baseline a part of the compliance evaluation. The following steps will walk through the process of creating a new configuration baseline including the new setting. In my example I’m adding a configuration item that will verify if the local administrators comply the the organisation defaults. The configuration baseline can be deployed like any other configuration baseline.

  1. Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Baselines
  2. Click Create Configuration Baseline to open the Create Configuration Baseline dialog box
  1. On the Create Configuration Baseline dialog box, provide the following and click OK
  • Name: Provide a valid name for the configuration baseline
  • Description: (Optional) Provide a description for the configuration baseline
  • Configuration data: Select the required configuration items that should be part of this configuration baseline
  • Select Always apply the baseline even for co-managed devices
  • Select Evaluate the baseline as part of compliance policy assessment

The combination of these settings will make sure that the configuration baseline is applied to co-managed devices and that the configuration baseline will be evaluated as part of the compliance. Keep in mind that any baseline with the second option selected, that is deployed to the user, or to the user’s device, is evaluated for compliance.

(Optional) Configure Configuration Manager Compliance

An optional configuration is to configure Microsoft Intune to also look at information of Configuration Manager for determining the compliance. In my scenario that is a required configuration as I’m using it in combination with co-managed devices. Within a compliance policy a setting is available that will require compliance from Configuration Manager. The following steps walk through the configuration of that setting in a device compliance policy. Nothing more, nothing less. The device compliance policy can be assigned like any other device compliance policy.

  1. Open the Microsoft 365 Device Management portal and navigate to Devices Windows > Compliance policies to open the Windows – Compliance policies blade
  2. On the Windows – Compliance policies blade, click Create Policy to open the Create Policy blade
  3. On the Create Policy blade, provide the following information and click Create
  • Name: Provide a valid name for the compliance policy
  • Description: (Optional) Provide a description for the compliance policy
  • Platform: Select Windows 10 and later
  • Settings: See step 4 and 5
  • Actions for noncompliance: Leave default (for this post)
  • Scope (Tags): Leave default (for this post)
  1. On the Windows 10 compliance policy blade, select Configuration Manager Compliance to open the Configuration Manager Compliance blade
  2. On the Configuration Manager Compliance blade, select Require with Require device compliance from System Center Configuration Manager and click OK to return to the Windows 10 compliance policy blade and click OK

Experience

Now let’s end this post by having a look at the end-user experience. In my scenario I’ve created a custom configuration baseline that will verify the number of local administrators on the device. When it’s above a specific number of local administrators, the device is considered not compliant as the device might be compromised. In that case the end-user will receive a message in the Company Portal app as shown below. It explains the end-user that the security settings should be updated and to look for more information in Software Center.

When looking at Software Center it actually provides exactly the same message to the end-user. It provides the end-user with the message that the security settings should be updated. For more information the end-user should contact the support department. So make sure that the requirements are clear to the end-user.

More information

For more information see the Include custom configuration baselines as part of compliance policy assessment section of the Create configuration baselines doc.

Report-only mode for conditional access

This week is, like last week, about a awareness for new feature that is introduced with conditional access. Last week was all about the recently introduced Conditional Access Insights workbook. In that post I already mentioned the Report-only mode for conditional access policies. In this post I want to focus on that Report-only mode. Report-only mode is a new state of a conditional access policy state that allows IT administrators to evaluate the impact of conditional access policies before enabling them in their environment. That enables the IT administrators to anticipate on the number and names of users impacted by common deployment initiatives such as blocking legacy authentication, requiring multi-factor authentication, or implementing sign-in risk policies. A great step forward.

In this post I’ll walk through the steps of configuring Report-only mode for conditional access policies, followed by looking at the end-user experience. I’ll end this post by looking at the administrator experience.

Configure report-only mode

Let’s start by having a look at the steps to configure the Report-only mode for a conditional access policy. These steps will walk through the creation of a new conditional access policy, with a focus on configuring the Report-only mode. The exact configuration of the conditional access policy assignments and conditions are not part of that focus. The following three steps walk through that configuration.

  1. Open the Azure portal and navigate to Azure Active Directory  > Security > Conditional access (or open the Microsoft 365 Device Management portal and navigate to Endpoint security Conditional access) to open the Conditional access – Policies blade
  2. On the Conditional access – Policies blade, click New policy to open the New blade
  3. On the New blade, configure the assignment and conditions to filter the users and cloud apps that should be targeted by the conditional access policy. After configuring the conditions it’s time to look at the access controls. The access controls are the configuration that eventually might impact the end-user. In the access controls, the grant control determines that behavior. In the grant control the IT administrator can configure the requirements that should be met for accessing the cloud app for the end-user. Depending on the configured requirements, there might be a minimal impact for the end-user (see Figure 1 and and Figure 2 about the messages that are shown about the impact of the conditional access policy based on the configured requirements). After configuring the grant control, select Report-only with Enable policy (also shown in Figure 1) and click Create.

End-user experience

Depending on the configuration that is used in the grant control, of the conditional access policy, the end-user might have a slight impact when using the Report-only mode. The table below is a summary of the available requirements in combination with the potential impact. This table is based on the information as shown during the configuration of the conditional access (see Figure 2), as I haven’t been able to get the mentioned experience on my test devices. I’ve tested with a Samsung Galaxy 10, iPad 2018 and iPhone X.

RequirementPotential user impact
Require multi-factor authentication No impact
Require device to be marked as compliantMay prompt users on macOS, iOS and Android devices to select a device certificate
Require Hybrid Azure AD joined device No impact
Require approved client appMay prompt users on macOS, iOS and Android devices to select a device certificate
Require app protection policyMay prompt users on macOS, iOS and Android devices to select a device certificate

Administrator experience

An interesting part to look at is the experience of the IT administrator. That can be achieved by looking at the Conditional Access Insights workbook (as shown last week). The Conditional Access Insights workbook can be used to get the insights of the different Report-only mode conditional access policies. The data in the workbook can be filtered to only show information about Report-only mode conditional access policies, or even only data of a specific conditional access policy.

Besides that workbook, the Sign-ins monitoring of Azure AD also provides a new tab in the details of a sign-in. That tab is the Report-only (Preview) tab. As shown below that tab provides information about the different Report-only mode conditional access policies that were applicable to the sign-in. Per conditional access policy, the result is shown of the sign-in. That result will show what the effect would be of that conditional access policy and that information will help with determining the impact of enabling that conditional access policy.

Below is an overview of the different result states of a Report-only conditional access policy. Almost all of these results are shown in Figure 3 above (with the exception of the user action required result).

ResultExplanation
Report only: FailureThe configured conditional access policy conditions were satisfied, but not all the required (non-interactive) controls were satisfied.
Report only: SuccessThe configured conditional access policy conditions and required (non-interactive) controls were satisfied. 
Report only: Not appliedNot all configured conditional access policy conditions were satisfied.
Report only: User action requiredThe configured conditional policy conditions were satisfied, but a user action would be required to satisfy the required controls.

More information

For more information regarding report-only, please refer to the following documents:

Working with the restart behavior of Win32 apps

A long time ago, I did a post about Working with the restart behavior of Applications in ConfigMgr 2012. That post is still being read pretty well. Based on the interest of that post, and the introduction of nice new features to the Win32 apps, I thought it would be a good idea to redo that post for Microsoft Intune. Before an IT administrator had to be creative to work with, or work around, the restart behavior of Win32 apps. Either by wrapping installations and capturing the exit code, or by tuning the translation of an return code. With the latest adjustments to the Win32 apps, within Microsoft Intune, the IT administrator has more options to actually work with the return code of an Win32 app installation. These configuration options are similar to the configuration options within the app model of ConfigMgr. In this post I’ll discuss the 2 layers that together define the restart behavior after the installation of Win32 apps.

Return codes

When looking at the restart behavior after the installation of Win32 apps, the first thing that should be looked at is the return code after the installation. By default, when adding a Win32 app to Microsoft Intune, a list of standard return codes is added to indicate post-installation behavior (see figure below). These are often used return codes. When the Win32 app installation ends with a different return code, additional entries can be added. This configuration is available via [Win32 app] > Properties > Return codes.

Fore every return code a code type can be configured. The code configures the post-installation behavior of the Win32 app. The following code types are available and can be configured with the return code to apply the mentioned behavior:

  • Failed – The Failed return code indicates that the Win32 app installation failed.
  • Hard reboot – The Hard reboot return code indicates that the device is required to restart to complete the installation. Additional Win32 apps cannot be installed on the device without restart. The user will be notified about the required restart.
  • Soft reboot – The Soft reboot return code indicates that the next Win32 app is allowed to be installed without requiring a restart, but a restart is necessary to complete the installation of the installed Win32 app. The user will be notified about the restart.
  • Retry – The Retry return code indicates that the Win32 app installation is retried three times. The installation will wait for 5 minutes between each attempt.
  • Success – The Success return code indicates the Win32 app installation was successful.

Enforce device restart behavior

The second thing that should be looked at is how the device will react on the configured return code. By default, when adding a Win32 app to Microsoft Intune, the default device restart behavior is set to App install may force a device restart (see figure below). This configuration will make sure that the device will restart after the Win32 app installation, if needed, but still in an acceptable manner. The restart behavior can be configured to respond to return code differently. That configuration is available via [Win32 app] > Properties > Program.

Multiple device restart behavior configurations are available. And all these configuration options have their own effect on the return code of the Win32 app installation. The following device restart behaviors are available and can be configured to apply the mentioned behavior (including a short explanation about the expected behavior):

  • Determine behavior based on return codes: This option means that the device will restart based on the configured return code. With this configuration a Hard reboot return code will immediately trigger a restart of the device and a Soft reboot return code will notify the user that a restart is required to finish the installation.
  • No specific action: This option means that the installation will suppress device restarts during the Win32 app installation of MSI-based apps. Effectively that means that parameters are added to the installation command line of MSI-based apps to suppress device restart. With this configuration a Hard reboot return code will notify the user that a restart of the device will be triggered in 120 minutes and a Soft reboot return code will notify the user that a restart is required to finish the installation.
  • App install may force a device restart: This option means that the Win32 app installation is allowed to complete without suppressing restarts. With this configuration a Hard reboot return code will notify the user that a restart of the device will be triggered in 120 minutes and a Soft reboot return code will notify the user that a restart is required to finish the installation.
  • Intune will force a mandatory device restart: This option means that a successful Win32 app installation will always restart the device. With this configuration any successful return code will immediately trigger a restart of the device.

More information

For more information about the Win32 app functionality in Microsoft Intune, refer to the documentation about Intune Standalone – Win32 app management.