Intune and Zimperium – Part 1: Configure the integration

This week and next week I’ll be looking at integrating Microsoft Intune with Zimperium. Zimperium is one the available third-party Mobile Threat Defense connectors for Microsoft Intune. This enables organizations to add an additional layer of protection to their corporate resources. More specifically, prevent access from compromised mobile devices. In the first part of this week I’ll be providing a short introduction about the integration and I’ll show how to configure the integration. I’ll end this post with the configuration results.

Introduction

Let’s start with a little introduction. Organizations can control mobile device access to corporate resources by using conditional access based on a risk assessment conducted by Zimperium. For this, Zimperium must be integrated with Microsoft Intune. The risk is assessed based on telemetry collected from devices running the Zimperium app. This enables organizations to configure conditional access policies based on the Zimperium risk assessment. The conditional access policy requires compliant devices and the compliance policy requires a minimum Mobile Threat Defense level. That combination enables organizations to allow or block non-compliant devices to access corporate resources based on detected threats.

To visualize this a bit more, it could be summarized in the following flow.

  1. The Zimperium app, on an iOS 8+ device or an Android 4.1+ device, detects a threat and sends an alert to the Zimperium cloud;
  2. The Zimperium cloud determines, based on the Mobile Thread Response Policy, the severity of the alert and sends the threat severity level to Microsoft Intune;
  3. Microsoft Intune determines, based on the configured mobile threat level, in the Device Compliance Policy, the compliance of the device and writes the device compliance to Azure AD;
  4. Azure AD determines, based on the configured access controls, in the Conditional Access Policy, if the device is allowed access to the cloud app.
ZimperiumFlow

Configuration

Now let’s have a look at the actual configuration of the integration between Zimperium and Microsoft Intune. The connector. Before starting with the configuration make sure that the following is available:

  • Microsoft Intune subscription;
  • Azure Active Directory administrative credentials;
  • Zimperium zConsole administrative credentials.

Zimperium configuration

The actual configuration starts in the Zimperium zConsole and not in the Intune section of the Azure portal. The Intune section in the Azure portal will only refer to the Zimperium zConsole. The 6 steps below walk through the configuration in cloud version of Zimperium.

1 Open the Zimperium zConsole and navigate to MANAGEMENT > MDM Settings;
2

Click Edit to open the Edit MDM dialog box;

Note: This environment had a previous MDM configuration. A clean environment has an Add MDM option. In that case every screen will show Edit instead of Add.

3 EditMDM01At Step 1, select Microsoft Intune and click Next;.
4a

EditMDM02At Step 2, click Add to Azure Active Directory for the different components and click Next;

Note: Step 4b, 4c and 4d provide more details about the required permissions per component.

4b

EditMDM02_zConsoleZimperium zConsole needs the following permissions:

  • Send device threat information to Microsoft Intune;
  • Read directory data;
  • Sign in and read user profile;
  • Read directory data.

Note: This makes sure that Zimperium can synchronize user and devices from Microsoft Intune and that Zimperium can sent threat information to Microsoft Intune.

4c

EditMDM02_zIPSiOSZimperium zIPS iOS needs the following permissions:

  • Access Zimperium zConsole (Zimperium zConsole);
  • Sign in and read user profile.

Note: This makes sure that the Zimperium zIPS iOS app can use the auto sign-in functionality by using the Microsoft Intune enrollment user information.

4d

EditMDM02_zIPSAndroidZimperium zIPS Android needs the following permissions:

  • Access Zimperium zConsole (Zimperium zConsole);
  • Sign in and read user profile.

Note: This makes sure that the Zimperium zIPS Android app can use the auto sign-in functionality by using the Microsoft Intune enrollment user information.

5

EditMDM03At Step 3, verify the information and click Next;

6

EditMDM04At Step 4, select the MDM group(s) that should be synchronized and used for the integration between Microsoft Intune and Zimperium and click Finish.

Note: The users in this group, and their devices, are synchronized to Zimperium.

Note: The connector between Zimperium and Intune automatically  synchronizes once every 4 hours. This synchronization can also be manually triggered (see the Results section).

Microsoft Intune configuration

After performing the configuration in the Zimperium zConsole, the connector will be created in Microsoft Intune. This enables a few tuning options from Microsoft Intune perspective. The following 3 steps walk through the configuration options.

1 Open the Azure portal and navigate to Intune > Device compliance > Mobile Threat Defense;
2 On the Device compliance – Mobile Threat Defense blade, select the automatically created MTD CONNECTOR Zimperium;
3

IntuneZimperiumConnectorOn the Edit Connector blade, configure the connected devices and click Save.

Note: This enables the administrator to differentiate between the available platforms.

Results

When the configurations are completed, a successful configuration can be verified in the Zimperium zConsole (below on the right) and in the Azure portal (below on the left). Both will show the same synchronization time.

MDMSettings_Results01 MDMSettings_Results02

More information

For more information about Mobile Treat Defense, Zimperium and Microsoft Intune, please refer to the following articles:

MDM Migration Analysis Tool

This week something completely different compared to the last few weeks, maybe even months. This week is all about creating awareness for the MDM Migration Analysis Tool (MMAT). MMAT is created to make the transition to MDM easier. At Ignite it also got some attention and I thought it would be good to add some more attention to it. Even though it already exists for a while. I’ll start this post with an introduction to MMAT, followed by the usage of MMAT. I’ll end this post with example results of MMAT.

Introduction to MMAT

Before looking at the technical transition to MDM policies, via Microsoft Intune (hybrid or standalone), or any third-party MDM, start with MMAT. MMAT is a tool created by Microsoft to help with the technical transition from Group Policies to MDM policies. It’s mainly created to save administrators time, as there is not a one-on-one mapping available for MDM policies with Group Policies. MMAT will determine which Group Policies have been set for a targeted user/computer and cross-reference against its built-in list of supported MDM policies. MMAT will then generate both XML and HTML reports indicating the level of support for each Group Policy in terms of MDM equivalents. In a bit more detail MMAT basically works in the following three stages:

  1. In the first stage it determines which GPOs have been applied to the targeted user/computer, by using RSOP (via WMI). After that It will filter out GPOs that are marked as not enabled, or with access denied;
  2. In the second stage it uses PowerShell, for each GPO, from the first stage, to get the GPO XML from the server. It will store that information in GPOReport-{GPOGuid}.txt files, which are stored in, by default, the current directory;
  3. In the third stage it invokes MdmMigrationAnalysisTool.exe. That consumes the
    GPOReport-* files and compares them against MDMPolicyMapping.xml. At the end it generates the final XML and HTML reports.

Note: MMAT only does a best-effort analysis.

Using MMAT

Now let’s have a look at how easy it is to use MMAT. However, before doing that let’s first have a look at the prerequisites. The Remote Server Administration Tools (RSAT) must be installed on the device running MMAT. RSAT is available via the following URLs:

After installing RSAT, use the following steps to “install” and run MMAT.

1 Download MMAT as ZIP from: https://github.com/WindowsDeviceManagement/MMAT;
2 Unzip MMAT to C:\Temp (example location);
3 Open Windows PowerShell and use Run as administrator;.
4 Adjust the directory: Set-Location C:\Temp\MMAT-master;
5 Adjust the execution policy: Set-ExecutionPolicy Unrestricted -Scope Process;
6 Adjust the verbose preference: $VerbosePreference=”Continue”;
7a Run MMAT:  .\Invoke-MdmMigrationAnalysisTool.ps1 -collectGPOReports -runAnalysisTool;
7b

Additional parameters for running MMAT:

  • gpoReportOutputDirectory: Directory to store the intermediate GPOReport-*.xml;
  • analysisToolOutputDirectory: Directory to store the generated reports and logs;
  • targetUser: Name of the user to target;
  • targetComputer: Name of the computer to target;
  • targetDomain: Fully Qualified Domain Name of domain to query.

Results of MMAT

After running MMAT it’s time to have a look at the results. By default the reports and logs are stored in the same directory as MMAT. The actual readable results are available in MDMMigrationAnalysis.html. Below on the left is an example of the high-over policies listed in MDMMigrationAnalysis.html for the computer and the user. Below on the right is an example of some more details about, in this example, supported and not supported security account polices. Especially the example on the right clearly shows that these results are only an initial check to see which Group Policies can be configurable via MDM policies. Nothing more.

MMAT_Overview MMAT_Results

Note: Before interpreting the results, make sure to be fully aware of the documented caveats and warnings.

More information

For more information about MMAT, please refer to the documentation about MMAT on GitHub.

Conditional access and terms of use

This week more about conditional access. More specifically, the ability to require end-users to consent to a terms of use, which is currently still in preview and was also highlighted during a couple of sessions on Microsoft Ignite. In this post, I’ll provide more information about the terms of use requirement and I’ll show how to configure that requirement. I’ll end this post with the end-user experience.

Introduction

It’s now possible to require an end-user in a tenant to consent to a terms of use before being granted access to a resource. Something like this was already possible for Microsoft Intune hybrid enrollment and Microsoft Intune standalone enrollment. However, that is Microsoft Intune only. This new requirement can be applied to any configurable Cloud app within a conditional access policy. Including Microsoft Intune enrollment. As an administrator, it’s now possible to configure and customize a terms of use by uploading a PDF document. If an end-user falls in scope of this control they will only be given access to the Cloud app if they agree, or have previously agreed, to the terms presented.

Configuration

Now let’s have a look at the configuration of a terms of use requirement in a conditional access policy. To configure a terms of use requirement in a conditional access policy. it actually requires two configurations 1) the actual terms of use and 2) the conditional access policy. The two configurations can be configured together at the same time, as shown below, or in two separate actions. To configure them together, follow the next 6 steps (of which the last 2 actually simply provide some overviews).

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Terms of use;
2 On the Conditional access – Terms of use blade, click New to open the New terms of use blade;
3 NewTouOn the New terms of use blade, provide the following information and click Create;

  • Name: Provide a name for the policy;
  • Display name: Provide a display name for the policy. This is shown to the end-user;
  • Upload document: Upload a PDF document that contains the terms of use,of the organization, for the applicable cloud apps;
  • Select Create a policy, to automatically create a conditional access policy based on the selected Policy template.
4 NewTouCA01Navigate to Azure Active Directory > Conditional access > Policies and select the just created conditional access policy. Based on the Access to cloud apps template a conditional access policy will be created as shown on the right. This policy might need some tuning as it applies to All users and All cloud apps. At least the All users assignment needs some adjustments. With the default configuration it will also be applicable to the account used by Azure AD Connect during the directory synchronization. Either change the included group, or exclude the account that is used by Azure AD Connect.

Note: This is the error that will be generated by the directory synchronization, GetADALToken: interactive authentication error [unspecified] – Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application.

5 NewTouCA02The just created conditional access policy contains the ability to select created terms of use in the Grant control.

Note: Every created terms of use will be selectable in the Grant control of the conditional access policy. An additional terms of use, will be an additional line like the one shown on the right.

6 NewTouCA03Navigate back to Azure Active Directory > Conditional access > Terms of use and select the just created terms of use. That provides an overview of the terms of use, the users that accepted and declined and the ability to preview the uploaded PDF.

Note: Specifically related to Microsoft Intune enrollment, think about which configuration to use. Both, the Microsoft Intune specific configuration and the Azure AD conditional access configuration, can be applied during Microsoft Intune enrollment.

End-user experience

Like last week, let’s end this post with the end-user experience. The first time the end-user falls within the assignment of the conditional access policy, the end-user will be prompted to accept the terms of use. Below are examples of an iOS device. On the left is an iOS device using the browser and on the right is an iOS device using a mobile app.

IMG_0115 IMG_0116

More information

For more information about conditional access and requiring end-users to consent to a terms of use, please refer to this article about Controls in Azure Active Directory conditional access.

Conditional access and approved client apps

This week back in conditional access. More specifically, the recently introduced requirement, in the grant control, to Require approved client apps, which is currently still in preview. That requirement feels a bit like MAM CA, but more about that later in this post. In this post, I’ll provide more information about the Require approved client apps requirements and I’ll show how to configure that requirement. I’ll end this post with the end-user experience.

Introduction

When configuring a conditional access policy, it’s now possible to configure the requirement to grant access only if a connection attempt was made by an approved client app. That’s done by using the Require approved client apps requirement. This requirement could be described as something similar as MAM CA, but with less options and straight from Azure AD. The main difference, from a configuration perspective, is that MAM CA provides more granular control over the client apps that can be used to access a specific cloud app, while this requirement in conditional access is simply on or off. On the other hand, this requirement in conditional access can be used with every cloud app, while MAM CA is only available for Exchange Online and SharePoint Online.

The approved client apps for the Require approved client apps requirement are the following apps (that all support Intune MAM):

  • Microsoft Excel
  • Microsoft OneDrive
  • Microsoft Outlook
  • Microsoft OneNote
  • Microsoft PowerPoint
  • Microsoft SharePoint
  • Microsoft Skype for Business
  • Microsoft Teams
  • Microsoft Visio
  • Microsoft Word

Keep in mind that the Require approved client apps requirement:

  • only supports iOS and Android as selected device platforms condition;
  • does not support Browser as selected client app condition;
  • supersedes the Mobile apps and desktop clients client app condition.

Configuration

Now let’s have a look at the required configuration of a conditional access policy in the Azure portal. To be able to use the Require approved client apps requirement, create a conditional access policy as shown below. The following 7 steps walk through the minimal configuration for, for example, Exchange Online.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 RACA_01On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 RACA_02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 Exchange Online and click Done;
5

RACA_03On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access and select at least Require approved client app (preview) and click Select.

Note: This configuration will make sure that only the mentioned approved client apps can access Exchange Online.

End-user experience

As usual with this type of posts, I’ll end this post with the end-user experience. On the left is an example of the iOS 11 default mail app that is trying to connect with Exchange Online. This provides a clear message that the app can’t be used, as it’s not approved. On the right is an example of the iOS default browser that is trying to connect with outlook.office365.com. This provides a less clear message and refers to the Intune Managed browser, which is currently not on the approved apps list. This is very likely the reason why the browser functionality is currently not yet supported, but it’s very good to see that the access is blocked. That removes a big potential backdoor of a great feature!

IMG_0113 IMG_0114

More information

For more information about conditional access and requiring approved client apps, please refer to this article about Azure Active Directory Conditional Access technical reference | Approved client app requirement.

Managing User Account Control settings via Windows 10 MDM

This blog post uses the LocalPoliciesSecurityOptions area of the Policy configuration service provider (CSP), to manage User Account Control (UAC) settings on Windows 10 devices. This area was added in Windows 10, version 1709, which is currently available as Insider Preview build.

This week a blog post about managing User Account Control (UAC) settings via Windows 10 MDM. The ability to manage UAC-settings is new in Windows 10 MDM. Windows 10, version 1709, introduces the LocalPoliciesSecurityOptions area in the Policy CSP, which also contains settings to manage UAC. This is the same area, in the Policy CSP, as my last post, but this time a different group of settings. The frequent readers of my blog might recognize some bits and pieces, but that’s simply because I liked the subjects used in my previous post. That also enables me to provide more details in this post. In this post I’ll look at the available UAC-settings, in the Policy CSP, and I’ll provide information about how those settings relate to actual local group policy settings. I’ll also provide some configuration guidelines for Microsoft Intune hybrid and Microsoft Intune standalone and I’ll end this post with 4 different locations that show the actual device configuration.

Available settings

Let’s start by looking at the available UAC-settings. Windows 10, version 1709, introduces the LocalPoliciesSecurityOptions area in the Policy CSP. That area contains 20+ settings. Those settings are related to accounts, interactive logon, network security, recovery console, shutdown and UAC. In this post I’m specifically looking at the settings related to UAC. The table below show the available UAC-settings, the available values and a short description. For even more information about the UAC-settings, please refer to the articles in the More information section of this post.

Setting Value Description
UserAccountControl_ AllowUIAccessApplicationsToPromptForElevation 0 – Disabled

1 – Enabled

This setting allows the administrator to control whether User Interface Accessibility (UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user.
UserAccountControl_ BehaviorOfTheElevationPromptForAdministrators 0 – Elevate without prompting
1 – Prompt for credentials on the secure desktop
2 – Prompt for consent on the secure desktop
3 – Prompt for credentials
4 – Prompt for consent
5 – Prompt for consent for non-Windows binaries
This setting allows the administrator to control the behavior of the elevation prompt for administrators.
UserAccountControl_ BehaviorOfTheElevationPromptForStandardUsers 0 – Automatically deny elevation requests
1 – Prompt for credentials on the secure desktop
3 – Prompt for credentials
This setting allows the administrator to control the behavior of the elevation prompt for standard users.
UserAccountControl_ DetectApplicationInstallationsAndPrompt ForElevation 0 – Disabled

1 – Enabled

This setting allows the administrator to control the behavior of application installation detection for the computer.
UserAccountControl_ OnlyElevateExecutableFilesThatAreSigned AndValidated 0 – Disabled

1 – Enabled

This setting allows the administrator to enforce public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege.
UserAccountControl_ OnlyElevateUIAccessApplicationsThatAreInstalled InSecureLocations 0 – Disabled

1 – Enabled

This setting allows the administrator to control whether applications that request to run with a User Interface Accessibility (UIAccess) integrity level must reside in a secure location in the file system
UserAccountControl_ RunAllAdministratorsInAdminApprovalMode 0 – Disabled

1 – Enabled

This setting allows the administrator to control the behavior of all User Account Control (UAC) policy settings for the computer.
UserAccountControl_ SwitchToTheSecureDesktopWhenPrompting ForElevation 0 – Disabled

1 – Enabled

This setting allows the administrator to control whether the elevation request prompt is displayed on the interactive user’s desktop or the secure desktop.
UserAccountControl_UseAdminApprovalMode 0 – Disabled

1 – Enabled

This setting allows the administrator to control the behavior of Admin Approval Mode for the built-in Administrator account..
UserAccountControl_ VirtualizeFileAndRegistryWriteFailuresToPer UserLocations 0 – Disabled

1 – Enabled

This setting allows the administrator to control whether application write failures are redirected to defined registry and file system locations.

Note: Keep in mind that every mentioned settings starts with ./Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions and that any spaces used within the setting, show in the table above, should be removed.

Local group policy settings

The nice thing is that the mentioned UAC-settings, in the LocalPoliciesSecurityOptions area of the Policy CSP (./Vendor/MSFT/Policy/Config), are all related to actual local group policy settings. Those local group policy settings can be found at Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. The name of the area, in the Policy CSP, simply translates to the location in the local group policies. Nice and easy. The table below shows how the available UAC-settings, actually translate to local group policy settings.

Policy CSP Local group policy setting
UserAccountControl_ AllowUIAccessApplicationsToPromptForElevation User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop
UserAccountControl_ BehaviorOfTheElevationPromptForAdministrators User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
UserAccountControl_ BehaviorOfTheElevationPromptForStandardUsers User Account Control: Behavior of the elevation prompt for standard users
UserAccountControl_ DetectApplicationInstallationsAndPrompt ForElevation User Account Control: Detect application installations and prompt for elevation
UserAccountControl_ OnlyElevateExecutableFilesThatAreSigned AndValidated User Account Control: Only elevate executables that are signed and validated
UserAccountControl_ OnlyElevateUIAccessApplicationsThatAreInstalled InSecureLocations User Account Control: Only elevate UIAccess applications that are installed in secure locations
UserAccountControl_ RunAllAdministratorsInAdminApprovalMode User Account Control: Run all administrators in Admin Approval Mode
UserAccountControl_ SwitchToTheSecureDesktopWhenPrompting ForElevation User Account Control: Switch to the secure desktop when prompting for elevation
UserAccountControl_UseAdminApprovalMode User Account Control: Admin Approval Mode for the built-in Administrator account
UserAccountControl_ VirtualizeFileAndRegistryWriteFailuresToPer UserLocations User Account Control: Virtualize file and registry write failures to per-user locations

Configure settings

After getting to know the available settings, let’s have a closer look at the configuration of the settings. The settings can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below. Within the configuration guidelines, I’m using the UAC-setting to enable the behavior of Admin Approval Mode for the built-in Administrator account as an example. That requires the following OMA-URI setting and value:

OMA-URI setting: ./Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/UserAccountControl_UseAdminApprovalMode
OMA-URI value: 1

Environment Configuration guidelines
Microsoft Intune hybrid IntuneH_UACSettingThe configuration in Microsoft Intune hybrid can be performed by starting the Create Configuration Item Wizard in the Configuration Manager administration console. Make sure to select Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 on the Supported Platforms page. Now select Configure additional settings that are not in the default setting groups on the Device Settings page and the configuration can begin by using the earlier mentioned OMA-URI setting and value.

Once the configurations are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices/ users.

Microsoft Intune standalone (Azure portal) IntuneS_UACSettingThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile and within the new profile, make sure to select Windows 10 and later as Platform and Custom as Profile type. In the Custom OMA-URI Settings blade, add the custom settings by using the earlier mentioned OMA-URI setting and value.

Once the configurations are finished, the profile can be saved and can be deployed to Windows 10 devices/ users.

Note: This post is based on the custom OMA-URI settings configuration. At some point in time this configuration can become available via the UI of Microsoft Intune standalone and/or hybrid.

Device configuration

Like last week I’ll end this post by simply looking at the device configuration. However, this week I’ll take it one step further. This time I’ll also add some WMI and registry information. Now let’s start with, below on the left, an export of the MDM Diagnostics Information, which clearly shows the default configuration and the new configurations via MDM. Below on the right is an overview of the Local Group Policy Editor, which clearly shows the actual configuration of the new configurations via MDM. In both cases the example UAC-setting, to control the behavior of Admin Approval Mode for the built-in Administrator account, is shown in the small red circle.

UAC_MDMDiagReport_Settings UAC_LGPO_Settings

Now let’s also have a look at the information in WMI and the registry. Below on the left is an overview of the policy result node in WMI Explorer, which clearly shows the results of the configurations via MDM. Below on the right is an overview of the local group policy settings in the Registry Editor, which clearly shows the local group policy settings configured via MDM. Also, like before, in both cases the example UAC-setting, to control the behavior of Admin Approval Mode for the built-in Administrator account, is shown in the small red circle.

UAC_WMI_Settings UAC_Registry_Settings

More information

For more information about the LocalPoliciesSecurityOptions area of the Policy CSP, and about the available UAC-settings,please refer to the following articles:

Managing local policies security options for accounts via Windows 10 MDM

This blog post uses the LocalPoliciesSecurityOptions area of the Policy configuration service provider (CSP) to manage local policies security options on Windows 10 devices. This area was added in Windows 10, version 1709, which is currently available as Insider Preview build.

This week a blog post about managing local policies security options via Windows 10 MDM. More specifically, local policies security options settings related to accounts. For example, to block the usage of Microsoft accounts. I might address the other areas of the local policies security options in later blog posts, but that will be more of the same. The ability to manage local policies security options is something new in Windows 10 MDM. Windows 10, version 1709, introduces the LocalPoliciesSecurityOptions area in the Policy CSP. In this post I’ll look at the available settings in the Policy CSP and I’ll provide information about how those settings related to actual local policies security options. I’ll also provide some configuration guidelines for Microsoft Intune hybrid and Microsoft Intune standalone and I’ll end this post with the some examples of the actual device configuration.

Available settings

Now let’s start by having a look at the available settings. Windows 10, version 1709, introduces the LocalPoliciesSecurityOptions area in the Policy CSP. That area contains 20+ settings. Those settings are related to accounts, interactive logon, network security, recovery console, shutdown and user account control. In this post I’m specifically looking at the settings related to accounts. The table below show the available settings related to accounts and the available values.

Setting Value Description
Accounts_BlockMicrosoftAccounts 0 – Disabled
1 – Enabled
This setting allows the administrator to prevent users from adding new Microsoft accounts on this computer.
Accounts_EnableAdministratorAccountStatus 0 – Disabled
1 – Enabled
This setting allows the administrator to enable the local Administrator account.
Accounts_EnableGuestAccountStatus 0 – Disabled
1 – Enabled
This setting allows the administrator to enable the Guest account.
Accounts_LimitLocalAccountUseOfBlank PasswordsToConsoleLogonOnly 0 – Disabled
1 – Enabled
This setting allows the administrator to configure whether local accounts that are not password protected can be used to log on from locations other than the physical computer console.
Accounts_RenameAdministratorAccount <string> This setting allows the administrator to configure whether a different account name is associated with the security identifier (SID) for the account Administrator.
Accounts_RenameGuestAccount <string> This setting allows the administrator to configure whether a different account name is associated with the security identifier (SID) for the account Guest.

Local group policy setting

The nice thing is that the mentioned account related settings, in the LocalPoliciesSecurityOptions area of the Policy CSP (./Vendor/MSFT/Policy/Config), are all related to actual local group policy settings. Those settings can be found at Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. The name of the area, in the Policy CSP, simply translates to the location in the local group policies. Nice and easy. The table below shows how the available settings, related to accounts, actually translate to local group policy settings.

Local group policy setting Policy CSP
Accounts: Block Microsoft accounts Accounts_BlockMicrosoftAccounts
Accounts: Administrator account status Accounts_EnableAdministratorAccountStatus
Accounts: Guest account status Accounts_EnableGuestAccountStatus
Accounts: Limit local account use of blank password to console logon only Accounts_LimitLocalAccountUseOfBlank PasswordsToConsoleLogonOnly
Accounts: Rename administrator account Accounts_RenameAdministratorAccount
Accounts: Rename guest account Accounts_RenameGuestAccount

Configure settings

After getting to know the available settings, let’s have a closer look at the configuration of the settings. The settings can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

IntuneH_BlockMSAccount The configuration in Microsoft Intune hybrid can be performed by starting the Create Configuration Item Wizard in the Configuration Manager administration console. Make sure to select Windows 8.1 and Windows 10 (below Settings for devices managed without the Configuration Manager client) on the General page and to select Windows 10 on the Supported Platforms page. Now select Configure additional settings that are not in the default setting groups on the Device Settings page and the configuration can begin by using the earlier mentioned OMA-URI settings and values.

Once the configurations are finished, the created configuration items can be added to a configuration baseline and can be deployed to Windows 10 devices/ users.

Microsoft Intune standalone (Azure portal)

IntuneS_BlockMSAccountThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile and within the new profile, make sure to select Windows 10 and later as Platform and Custom as Profile type. In the Custom OMA-URI Settings blade, add the custom settings by using the earlier mentioned OMA-URI settings and values.

Once the configurations are finished, the profile can be saved and can be deployed to Windows 10 devices/ users.

Note: This post is based on the custom OMA-URI settings configuration. At some point in time this configuration can become available via the UI of Microsoft Intune standalone and/or hybrid.

Device configuration

Usually I’ll end these type of posts with the end-user experience. However, in this case it’s better to simply look at the device configuration instead. On the left is an export of the MDM Diagnostics Information, which clearly shows the default configuration and the new configurations via MDM. On the right is an overview of the Local Group Policy Editor, which clearly shows the new actual configuration of the new configuration via MDM.

MDMDiagReport_Settings LGPO_Settings

More information

For more information about the LocalPoliciesSecurityOptions area of the Policy CSP, please refer to this article about Policy CSP – LocalPoliciesSecurityOptions.

More differentiation options for device health attestation

This week a short blog post, as it’s written during my vacation, about the new differentiation options in device health attestation for compliance policies. This post is basically an addition to my post about conditional access and health attestation. Back then, a compliance policy could only check for the overall health status reported by the Health Attestation Service. That is changed now. Now it’s possible to differentiate between the different data points of the Health Attestation Service. In this post I’ll briefly go through these new configuration options for Microsoft Intune hybrid and Microsoft Intune standalone.

Configuration

Now let’s have a look at the new configuration options for the differentiation between the different data points of the Health Attestation Service. Below are the configuration guidelines for Microsoft Intune hybrid and Microsoft Intune standalone. The guidelines for Microsoft Intune hybrid require Configuration Manager 1706, or later, and both guidelines also contain the configurable data points.

Environment Configuration guidelines
Microsoft Intune hybrid HAS_HybridThe configuration in Microsoft Intune hybrid can be performed by starting the Create Compliance Policy Wizard in the Configuration Manager administration console. Make sure to select Compliance rules for devices managed without Configuration Manager client on the General page and to select Windows 10 on the Supported Platforms page. Now select New on the Rules page and the condition Reported as healthy by Health Attestation Service can be added. After selecting the condition it’s possible to configure the required status per data point. This includes BitLocker, Secure Boot, Code Integrity and Early Launch Anti-Malware (ELAM).

Microsoft Intune standalone (Azure portal)

HAS_StandaloneThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device compliance policy. Create a new policy, select Windows 10 and later as Platform and select Settings > Device Health. This enables the configuration of the the required status per data point of the Health Attestation Service. This includes BitLocker, Secure Boot and Code Integrity.

Note: This enables new scenarios in which it’s possible to not require BitLocker on VMs, or in which it’s possible to not require ELAM due to it’s quirks with hibernation.

Block personally-owned devices

My last blog post just before a short vacation, is about using the differentiation between corporate-owned devices and personally-owned devices. The best scenario for this differentiation is preventing the MDM enrollment of personally-owned devices. In that scenario it’s still possible to use MAM-WE with personally-owned devices, as only the MDM enrollment will be blocked. In other words, it’s still possible to enable the end-users to securely access their corporate data on their personally-owned device. The ability to block personally-owned devices is introduced with Configuration Manager 1706 and was already available for a while in Microsoft Intune standalone. In this post I’ll walk through the configuration steps for Microsoft Intune hybrid and standalone. I’ll end this post with the end-user experience.

Configuration

Before starting with the configuration, it’s good to mention that Microsoft Intune hybrid and standalone classifies devices as personally-owned by default.

Microsoft Intune hybrid

The configuration for Microsoft Intune hybrid must be done by using the Configuration Manager administration console. At this moment Microsoft Intune hybrid only supports the restriction on personally-owned devices for Android and iOS. This can be configured by simply following the next steps.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Cloud Services > Configure Platforms;
2 On the Home tab, click Configure Platforms > Android (3a) or iOS (3b) to open the Microsoft Intune Subscription Properties;
3a BlockPersonal_Android_HybridOn the General tab, select Block personally owned devices and click OK;
3b BlockPersonal_iOS_HybridOn the Enrollment Restrictions tab, select Block personally owned devices and click OK.

Note: To specify that a device is company-owned, add the IMEI or serial number to the Predeclared Devices list (as shown here), or enroll it using Apple DEP (iOS only).

Microsoft Intune standalone

The configuration for Microsoft Intune standalone must be done by using the Azure portal. At this moment Microsoft Intune standalone supports the restriction on personally-owned devices for Android, iOS and macOS. This can be configured by simply following the next steps.

1 Open the Azure portal and navigate to Intune > Device enrollment > Enrollment restrictions to open the Device enrollment – Enrollment restrictions blade;
2 On the Device enrollment – Enrollment restrictions blade, select Default in the Device Type Restrictions section, to open the All Users blade;
3 On the All Users blade, select Platform Configurations to open the All Users – Platform Configurations blade;
4

BlockPersonal_StandaloneOn the All Users – Platform Configurations blade, select Block, in the PERSONALLY OWNED column, for the platforms of which personal-owned devices must be blocked and click Save.

Note: To specify that a device is company-owned, ad the IMEI or serial number to the Predeclared Devices list (as shown here), or enroll it using Apple DEP (iOS only)..

End-user experience

Now let’s end this post by looking at the end-user experience for Android and iOS devices.

Screenshot_20170816-201942Android: Let’s walk through the steps, on an Android device, that the end-user needs to perform before the end-user will actually be told that it’s not allowed.

  • Open the Microsoft Intune Company Portal app and sign in;
  • On the Company Access Setup page, tap Begin;
  • On the Why enroll your device? page, tap Continue;
  • On the We care about your privacy page, tap Continue;
  • On the What comes next page, tap Enroll;
  • On the Activate device administrator? page, tap Activate;

Now a clear Couldn’t enroll your device message will show (as shown on the right). That message clearly mentions that the end-user is not authorized to enroll this device.

IMG_0112iOS: Let’s walk through the steps, on an iOS device, that the end-user needs to perform before the end-user will actually notice that it’s not allowed.

  • Open the Microsoft Intune Company Portal app and sign in;
  • On the Company Access Setup page, tap Begin;
  • On the Why enroll your device? page, tap Continue;
  • On the We care about your privacy page, tap Continue;
  • On the What comes next page, tap Enroll;
  • On the Install Profile page, tap Install;
  • On the dialog box, tap Install;

Now a terrible Profile Installation Failed message will show (as shown on the right). That message mentions that a connection to the server could not be established. This is ugly, but is currently the expected behavior.

More information

For more information about blocking personally-owned devices and how it can be configured via Microsoft Intune hybrid and standalone, please refer to the following articles:

Easily configuring Windows Update for Business via Windows 10 MDM

This week a blog post about easily configuring Windows Update for Business (WUfB). I call it easily, as I did a post about something similar about a year ago. That time It was required to configure everything with custom OMA-URI settings. Starting with Configuration Manager 1706, an easier configuration option is available for the most important settings, by using the Configuration Manager administration console. For Microsoft Intune standalone this was already available for a while. In this post I’ll walk through the easy configuration options for Microsoft Intune hybrid and standalone and I’ll end this post with the end-user experience.

Configuration

Now let’s start by walking through the configuration steps for Microsoft Intune hybrid and standalone. However, before doing that it’s good to mention that at this moment Microsoft Intune hybrid and standalone still use the “old” branch names and are not yet updated to the “new” channel name(s). Also, keep in mind that currently not all the WUfB-settings are easily configurable. There are even differences between Microsoft Intune hybrid and standalone. Having mentioned that, every WUfB-setting, available in the Policy CSP, can also still be configured via custom OMA-URI settings.

Microsoft Intune hybrid

The configuration for Microsoft Intune hybrid must be done by using the Configuration Manager console. Simply walking through the wizard as shown below, will create the required policy. The policy can be deployed like a configuration baseline. The nice thing about the created policy is that it can be applied to devices managed via MDM and devices managed with the Configuration Manager client. The focus of this post is the devices managed via MDM.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Windows 10 Servicing > Windows Update for Business Policies;
2 On the Home tab, click Create Windows Update to Business Policy to open the Create Windows Update to Business Policy Wizard;
3 On the General page, provide unique name (max 200 characters) and click Next;
4

CWUfBPW_DefPolOn the Deferral Policies page, configure the following settings and click Next.

  • Defer Feature Updates
    • Branch readiness level: Select Current Branch or Current Branch for Business;
    • Deferral period (days): Select a value between 0 and 180;
    • Select Pause Feature Updates starting to prevent feature updates from being received on their schedule;
  • Defer Quality Updates
    • Deferral period (days): Select a value between 0 and 30;
    • Select Pause Quality Updates starting to prevent quality updates from being received on their schedule;
  • Select Install updates from other products to make the deferral settings applicable to Microsoft Update as well as Windows Updates;
  • Select Include drivers from Windows updates to also update drivers from Windows Updates.
5 On the Summary page, click Next;
6 On the Completion page, click Close;

Note: At this moment the policy can only be deployed to devices.

Microsoft Intune standalone

The configuration for Microsoft Intune standalone must be done by using the Azure portal. Simply walking through the blades, as shown below, will create the required update ring. The update ring can be assigned, after the creation, like anything else created in the Azure portal.

1 Open the Azure portal and navigate to Intune > Software Updates > Windows 10 Update Rings;
2 On the Windows 10 Update Rings blade, select Create to open the Create Update Ring blade;
3 On the Create Update Ring blade, provide unique name and select Settings to open the Settings blade;
4

W10UR_SettingsOn the Deferral Policies page, configure the following settings and select OK to return to the Create Update Ring blade.

  • Servicing branch: Select CB or CBB;
  • Microsoft product updates: Select Allow or Block;
  • Windows drivers: Select Allow or Block;
  • Automatic update behavior: Select Notify download, Auto install at maintenance time, Auto install and restart at maintenance time, Auto install and restart at a scheduled time or Auto install and reboot without end-user control;
  • Active hours start: Choose a time between 12 AM and 11 PM;
  • Active hours end: Choose a time between 12 AM and 11 PM;
  • Quality update deferral period (days); Provide a value between 0 and 30;
  • Feature update deferral period (days): Provide a value between 0 and 180;
  • Delivery optimization: Select HTTP only, no peering, HTTP blended with peering behind same NAT, HTTP blended with peering across private group, HTTP blended with internet peering, Simple download mode with no peering or Bypass mode.

Note: Depending on the choice made with Automatic update behavior, Active hours start and Active hours end can change to Scheduled install day and Scheduled install time.

5 Back on the Create Update Ring blade, select Create;

Note: It’s good to mention that it’s also possible to use the pause functionality for quality and feature updates without using custom URI settings. That can be achieved by selecting the created update ring and choosing Pause Quality or Pause Feature.

End-user experience

Important: The end-user experience is based on the current experience on Windows 10, version 1709 (RS3), which is currently available as Insider Preview build (build 16251).

I used Windows 10, version 1709 (RS3), for the end-user experience as it provides a clear view on the applied update policies. The examples below are based on the available settings in the different consoles. Below on the left is of a Microsoft Intune hybrid environment and below on the right is of a Microsoft Intune standalone environment. The show overview is available by navigating to Settings > Update & security > Windows Update > View configured update policy.

Configured_Hybrid Configured_Standalone

Another interesting place to look, is the registry. This is on the end-user device, but is more of interest for administrators. Starting with Windows 10, version 1607, the WUfB-configuration, configured via MDM, is available in the registry via HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\current\device\Update. The examples below are based on the available settings in the different consoles. Below on the left is of a Microsoft Intune hybrid environment and below on the right is of a Microsoft Intune standalone environment.

Registry_Hybrid Registry_Standalone

More information

For more information about Windows Update for Business  and how it can be configured via Microsoft Intune hybrid and standalone, please refer to the following articles:

A new discovery method: Meet the Azure Active Directory User Discovery!

This week a blog post about the addition of a new discovery method, as Configuration Manager 1706 introduces the Azure Active Directory User Discovery. This discovery method enables organizations to search Azure AD for user information. It adds the cloud-only users to the Configuration Manager environment and it adds additional attributes to the existing on-premises user objects. The attributes that are discovered are objectId, displayName, mail, mailNickname, onPremisesSecurityIdentifier, userPrincipalName and AAD tenantID. In this post I’ll show how to configure the Azure Active Directory User Discovery and I’ll show a couple of challenges that I faced during the configuration. I’ll end this post with the administrator experience. The configuration options for the administrator and the important places for the administrator to look for the additional information.

Configuration

Let’s start with the configuration, which actually can be as simple as walking through a wizard. During the steps shown below, I’ll show the required steps for the initial cloud services configuration. Some screenshots will indicate that I’ve got multiple cloud services configured already. Before starting with the configuration, it’s good to mention that I always create a separate web app for every cloud service. By doing that I make sure that every web app only has the required permissions for it’s specific use case. Having said that, follow the next steps to configure the Azure Active Directory User Discovery by creating new web apps.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services;
2 On the Home tab, click Configure Azure Services to open the Azure Services Wizard;
3

ASW_AzureServiceOn the Azure Services page, select Cloud Management and click Next;

Note: When this is the first cloud services that is configured, this page also contains the option to select OMS Connector, Upgrade Readiness Connector and Windows Store for Business.

4 On the App Properties page, click Browse with Web app to open the Server App dialog box;
5 On the Server App dialog box, click Create to open the Create Server Application dialog box;
6

On the Create Server Application dialog box, provide the following information and click OK to return to the Server App dialog box;

  • ASW_CreateServerAppApplication Name: Provide a friendly name for the app (max 200 characters);
  • HomePage URL: Provide the homepage URL for the app (max 200 characters);
  • App ID URI: Provide the identifier URL for the app (max 200 characters);
  • Secret key validity period: Select 1 Year or 2 Years for the key validity period;
  • Azure AD Admin Account: Sign in with the tenant administrator account;
  • Azure AD Tenant Name: Automatically populated after signing in;

Note: Once a web app is already created for the cloud management service, pressing OK will result in an informational message stating “An Azure AD Web App already exists for this Tenant. Use the pre-existing app and then click OK

7 ASW_ServerApp2Back on the Server App dialog box, select the just created web app and click OK to return to the App Properties page.
8 Back on the App Properties page, click Browse with Native Client app to open the Client App dialog box;
9 On the Client App dialog box, click Create to open the Create Client Application dialog box;
10

On the Create Client Application dialog box, provide the following information and click OK to return to the Client App dialog box;

  • ASW_CreateClientAppApplication Name: Provide a friendly name for the app (max 200 characters);
  • Reply URL: Provide the reply URL for the app (max 200 characters);
  • Azure AD Admin Account: Sign in with the tenant
    administrator account;
  • Azure AD Tenant Name: Automatically populated after signing
    in;
11 ASW_ClientApp2Back on the Client App dialog, select the just created native app and click OK to return to the App Properties page;
12 ASW_AppBack on the App Properties page, verify the created and selected apps and click Next;
13

ASW_DiscoveryOn the Configure Discovery Settings page, select Enable Azure Active Directory User Discovery and click Next;

Note: Click Settings to configure the full discovery polling schedule and the delta discovery. The default schedule for the full discovery is once every 7 days and the default interval for the delta discovery is an interval of every 5 minutes.

14 On the Confirm the settings page, click Next;
15 On the Completion page, verify the results and close the wizard.

Challenges

During my initial configuration of the Azure Active Directory User Discovery , I encountered a few challenges. The most important challenges that I faced, are the following.

1 AzureReqPermUnauthorized error: After the Azure Active Directory User Discovery started, it immediately failed with an unauthorized error message. This was related to the permissions of the just created web and native app. The permissions were set correctly. However, it needed a trigger, by clicking Grant Permissions, to grant the permissions for all the accounts in the directory.
2 Unknown error: After the Azure Active Directory User Discovery started with a successful authentication, it failed again. This time with an unknown error message. This was related to an orphaned user account in Azure AD. For some reason Azure AD still contained an user account that was already removed from the on-premises AD, a long time ago. Removing the orphaned user account from Azure AD solved this challenge.

Administrator experience

Now let’s end this post with the most interesting part, the administrator experience. From an administrative perspective, this configuration introduces at least the following new items.

1 CloudManPropDiscover method: One of the most interesting items is the new Azure Active Directory User Discovery. After the configuration is finished the discovery method can be found by navigating to Administration > Overview > Cloud Services > Azure Services. Selecting the cloud management Azure service, provides the option Run Full Discovery Now. The properties of the cloud management Azure service, provide the option to reconfigure the discovery configuration of the Azure Active Directory User Discovery (as shown on the right).
2 AzureADDiscoverAgentLog file: One of the most important items is the new log file SMS_AZUREAD_DISCOVERY_AGENT.log. This log files provides the information about the full and delta discoveries of the Azure Active Directory User Discovery (as shown on the right). The nice part is that the log files also provides information about the Microsoft Graph requests that it uses for the discovery.
3 CloudOnlyUserCloud-only users: The most useful item is the availability of the cloud-only users in the on-premises environment. These users can be recognized by only having the Agent Name of SMS_AZUREAD_USER_DISCOVERY_AGENT (as shown on the right). The availability of the cloud-only users in the Configuration Manager environment, and the availability of the new attributes for existing users, enables a whole lot of new scenarios. Most of these scenarios are related to managing Windows 10 Azure AD joined devices with an Configuration Manager client.
4

SQL_svUserUser properties: The overall most interesting, most important and most useful item is by far the information in the database. The main user tables and views now contain additional fields for cloud-related information. Some nice information can be found on the right, were I used a simple query to get information about user that contain attributes from the Azure Active Directory User Discovery. The query I used here was:

SELECT Unique_User_Name0,User_Principal_Name0,AADTenantID,AADUserID,CloudUserId
FROM v_R_User
WHERE AADTenantID IS NOT NULL

More information

For more information about the Azure AD user discovery and how to use and configure it, please refer to the following articles: