Deep dive configuring Windows 10 ADMX-backed policies

A couple of weeks ago, I did a my blog post about configuring a Windows 10 ADMX-backed policy. That time I used a relatively easy setting to configure and I briefly mentioned how to configure a more advanced setting. That raised some questions, which triggered me to do a deep dive in configuring those more advanced settings. In this blog post I’ll show, in a step-by-step overview,  how to construct the OMA-URI setting and value for a more advanced setting.

Setting

I’ll use the ClientConnectionEncryptionLevel setting as an example again. A big difference with the previous time is that the docs are greatly improved. By default, the docs now already provide information about the corresponding Group Policy setting and the location of the Group Policy setting. The docs already provide the following information about the settings.

MDM CSP setting path/ name
RemoteDesktopServices\ClientConnectionEncryptionLevel
Group Policy English name
Set client connection encryption level
Group Policy English category path
Windows Components\Remote Desktop Services
Group Policy name
TS_ENCRYPTION_POLICY
Group Policy ADMX file name
terminalserver.admx

Value

The default information in the docs make it relatively easy to find the required setting and it’s basic values. Now let’s go through the steps to find all the required information for more advanced settings. A more advanced setting, to me, is a setting that must be enabled and requires additional data.

Step 1: Enable the setting

Let’s start with the first step, which is enabling the setting. The following steps will go through the steps to find the Group Policy setting and enabling it.

1 Open the Group Policy Management Editor and navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security;
2 Right-click the setting Set client connection encryption level and select Edit;
3

GPO_SetClientConnectionEncryptionLevel_1In the Set client connection encryption level dialog  box, it’s possible to enable and disable the setting. After enabling the setting it shows an advanced setting to configure, the Encryption Level. In this example I want to enable the setting. That means that I need to use <enabled/> as value for my OMA-URI setting. However, as the advanced setting needs an additional data element, I also need to find the appropriate data for that element.

Step 2: Configure the setting

The next step is the advanced configuration of the Group Policy setting. The following steps will go through finding the available values and how those values can be used in a OMA-URI setting.

1 Open TerminalServer.admx and navigate to the TS_ENCRYPTION_POLICY policy setting;
2

TerminalServerADMXThe <elements> section contains the configurable data elements and its possible values. As shown on the right, the configurable data element is named TS_ENCRYPTION_LEVEL and the configurable values are:

  • 1 = TS_ENCRYPTION_LOW_LEVEL;
  • 2 = TS_ENCRYPTION_CLIENT_COMPATIBLE;
  • 3 = TS_ENCRYPTION_HIGH_LEVEL.
3 Open TerminalServer.adml and navigate to the TS_ENCRYPTION_POLICY string;
4

TerminalServerADMLThe ADML contains the readable string of the display names mentioned in the ADMX. Around the TS_ENCRYPTION_POLICY string I can see the following display names for the previously mentioned values:

    • TS_ENCRYPTION_LOW_LEVEL =  Low Level;
    • TS_ENCRYPTION_CLIENT_COMPATIBLE = Client Compatible;
    • TS_ENCRYPTION_HIGH_LEVEL = High Level.
5

GPO_SetClientConnectionEncryptionLevel_2Back to the Set client connection encryption dialog box, I can now translate the available configuration options to values for my OMA-URI setting. When I compare the TerminalServer.admx (and TerminalServer.adml) with the available configuration options, I can translate them like this:

  • Client Compatible = 2;
  • High Level = 3;
  • Low Level = 1.
6 Putting the advanced setting and its available configurations together, gives me the following data element for configuring the Encryption Level to Low Level: <data id=”TS_ENCRYPTION_LEVEL” value=”1″/>;

Step 3: Complete setting

Now I can put step 1 and step 2 together and enable the setting and configure the required additional configuration. When I want to enable Set client connection encryption level and set the Encryption Level to Low Level, I can use the following value for the OMA-URI setting: <enabled/><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>.

Result

Let’s have a look at the result, when I’m configuring the following OMA-URI setting:

  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/ClientConnectionEncryptionLevel
  • Date type: String
  • Value: <enabled/><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>

As I’m basically configuring Group Policy settings, the best place to look for a successful configuration is the registry. Below on the left is another look at the TerminalServer.admx in which I show the registry key that will be configured. On the right I show the configured registry key and it’s value.

TerminalServerADMX_Reg TerminalServer_Reg
Share

Conditional access and named locations

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

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

Configuration

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

Named location

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

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

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

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

Conditional access policy

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

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

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

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

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

End-user experience

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

SP_AllowedAccess SP_BlockedAccess

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

More information

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

Share

Allow users to connect remotely to this computer via Windows 10 MDM (ADMX-style)

This week another blog post about new MDM capabilities that are introduced in Windows 10, version 1703. This post is focused on enabling the setting to allow users to connect remotely to this computer via Remote Desktop. To enable that specific setting, Windows 10, version 1703, introduced ADMX-backed policy via the Policy CSP. In this post I’ll provide a short introduction about ADMX-backed policies, which is actually a short summary of the Microsoft docs, and I’ll show a configuration example. I’ll end this post by showing the end-user experience.

Introduction

Starting with Windows 10, version 1703, the Policy CSP can now also handle ADMX-backed policies. In an ADMX-backed policy, an administrative template contains the metadata of a GPO. Each administrative template specifies the registry keys, and their values, that are associated with a GPO and defines the policy settings that can be managed. Each setting in an administrative template corresponds to a specific registry value. Windows maps the name and category path of a GPO to a MDM policy area, and policy name, by parsing the associated ADMX-file, finding the specified GPO, and storing the metadata in the Policy CSP. When the MDM policy is referenced, this metadata is referenced and determines which registry keys are set or removed.

Configuration

Now let’s have look at the configuration for enabling the setting to allow users to connect remotely to this computer. I’ll do that by first going through the available settings, related to Remote Desktop, and getting the required values. After that I’ll put those two together in a configuration example.

Available settings

As Windows 10, version 1703, introduced a few new settings to manage Remote Desktop, I thought it would be good to briefly go through these new settings. The root node for the Remote Desktop related settings is, in the Policy CSP, ./Vendor/MSFT/Policy. The Remote Desktop related settings are grouped below ./Vendor/MSFT/Policy/Config/RemoteDesktopServices and contains the following settings.

Setting Description
AllowUsersToConnectRemotely This setting allows the administrator to configure remote access to computers by using Remote Desktop Services.
ClientConnectionEncryptionLevel This setting allows the administrator to specify whether to require the use of a specific encryption level.
DoNotAllowDriveRedirection This setting allows the administrator to specify whether to prevent the mapping of client drives in a Remote Desktop Services session (drive redirection).
DoNotAllowPasswordSaving This setting allows the administrator to control whether passwords can be saved on this computer from Remote Desktop Connection.
PromptForPasswordUponConnection This setting allows the administrator to specify whether Remote Desktop Services always prompts the client for a password upon connection.
RequireSecureRPCCommunication This setting allows the administrator to specify whether a Remote Desktop Session Host server requires secure RPC communication with all clients.

Available values

Now that I’ve been through the available settings related to Remote Desktop, let’s have closer look at the setting that enables the administrator to allow users to connect remotely to this computer. That’s the setting AllowUsersToConnectRemotely.

To get the available values for the AllowUsersToConnectRemotely setting, it’s good to double-check the configuration options in the local Group Policy Editor. The related GPO setting is named Allow users to connect remotely by using Remote Desktop Services and can be found at Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections. That shows that the only available values are Not Configured, Enabled and Disabled. Related to ADMX-backed policies, this translates to a value of <enabled /> or <disabled />. AllowRDP_GPO

Note: When a setting contains more configuration options, like the ClientConnectionEncryptionLevel setting, which relates to the Set client connection encryption level setting, then it’s required to dive into the ADMX-file that contains the GPO setting. The ADMX-file contains the available elements that are required when the setting is enabled. In this case the TerminalServer.admx. Minor detail, this ADMX-file doesn’t contain readable information related to the required setting. To find the related setting in that AMDX-file, my advise is to first find the setting in the related AMDL-file. In this case the TerminalServer.adml. That file contains readable information and shows the name of the setting in the ADMX-file. In this case the setting is TS_ENCRYPTION_POLICY. The additional element for that setting is TS_ENCRYPTION_LEVEL and the available values for that element are 1, 2 and 3. Every element must show as data in the ADMX-backed policy. Related to ADMX-backed policies, this could translate to a value of <enabled /><data id=”TS_ENCRYPTION_LEVEL” value=”1″/>.

Together this means that to  enable the setting to allow users to connect remotely to this computer, the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/RemoteDesktopServices/AllowUsersToConnectRemotely
  • Date type: String
  • Value: <enabled />

Configure settings and values

Let’s put the setting and values together. Together this information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

AllowRDP_IntuneHybridThe 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.

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

Microsoft Intune standalone (Azure portal)

AllowRDP_IntuneStandaloneThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile, or add a row to an existing custom profile. With a 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.

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

End-user experience

Let’s end this post with the end-user experience. This time I’ll do that by showing the configuration in the user interface and in the registry. Like with configuring the setting to allow users to connect remotely  to the computer, via GPO, the Allow remote connections to the computer setting is enabled and grayed-out, as shown below on the right. This also corresponds to the registry setting fDenyTSConnections at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services, as shown below on the right. As these are ADMX-backed policies, the settings are configured in the registry.

AllowRDPReg_MDM AllowRDPScr_MDM

More information

For more information about ADMX-backed policy and the Policy CSP, please refer to:

Share

Quick tip: View device in Azure Active Directory

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

View device in Azure AD

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

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

Easily configure Start via Windows 10 MDM

This blog post is about the ability to configure Start on Windows 10 devices. Mainly focused on Windows 10 Desktop devices. Before Windows 10, version 1703, it was already possible to configure the layout of Start by using the StartLayout setting. Windows 10, version 1703, introduces many, many more settings related to configuring Start via Windows 10 MDM. All of these settings are available via the existing Policy CSP. These new settings range from configuring settings available in the Settings panel until configuring settings related to the Power button and the user tile.

In this post I’ll go through almost all newly introduced settings and I’ll briefly show how to configure these settings by using Microsoft Intune hybrid and standalone. I’ll end this post by showing the effect of the configured settings for the end-user.

Available settings

As Windows 10, version 1703, introduced many new settings to manage Start, I thought it would be good to briefly go through these new settings. The root node for the Start related settings is, in the Policy CSP, ./Vendor/MSFT/Policy. The Start related settings are grouped below ./Vendor/MSFT/Policy/Config/Start and contains the following settings.

Setting Value Description
ForceStartSize 0 – Do not force
1 – Force non-fullscreen
2 – Force fullscreen
This setting allows the administrator to force the Start screen size
HideAppList* 0 – None
1 – Hide all app list
2 – Hide and disable
3 – Hide, remove and disable
This setting allows the administrator to configure Start by collapsing or removing the all app list.
HideChangeAccountSettings 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Change account settings option from the user tile.
HideFrequentlyUsedApps* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the the most used apps.
HideHibernate 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Hibernate option from the Power button.
HideLock 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Lock option from the user tile.
HidePowerButton* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the the Power button.
HideRecentJumplists* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Recently used items option from the jumplists.
HideRecentlyAddedApps* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the recently added apps.
HideRestart 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Restart option from the Power button.
HideShutDown 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Shutdown option from the Power button.
HideSignOut 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Sign out option from the user tile.
HideSleep 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Sleep option from the Power button.
HideSwitchAccount 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the Switch account option from the user tile.
HideUserTile* 0 – Do not hide
1 – Hide
This setting allows the administrator to configure Start by hiding the user tile.
NoPinningToTaskbar 0 – Pinning enabled
1 – Pinning disabled
This setting allows the administrator to configure the taskbar by hiding the option to pin and unpin apps on the taskbar.

*Setting requires restart to take effect.

Configure settings

After going through the available settings in the Start node, of the Policy CSP, let’s have a closer look at the configuration of those settings. These available 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

Start_IntuneHybridThe 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.

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

Microsoft Intune standalone (Azure portal)

Start_IntuneStandAloneThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile, or add a row to an existing custom profile. With a 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.

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

Effective settings

Let’s end this post with the end-user experience. However, I’ll do that a bit different as I usually do. I’ll do that by showing the settings, and options, that are affected by the available settings.

Start_SettingsThe first section of configurable settings are all related to settings in the Settings panel. More specifically, Settings > Personalization > Start. In this section the following settings can be configured (as shown in the screenshot):

  • HideAppList;
  • HideRecentlyAddedApps;
  • HideFrequentlyUsedApps:
  • ForceStartSize;
  • HideRecentJumpLists.

Note: I’ve had some issues with configuring the HideAppList setting.

Start_PowerButtonThe second section of configurable settings are all related to the Power button. I’ll show these settings, by showing the available options of the Power button and the related setting. In this section the following settings can be configured (as shown in the screenshot):

  • HideSleep:
  • HideHibernate;
  • HideShutdown;
  • HideRestart;
  • HidePowerButton.

Start_UserTileThe third section of configurable settings are all related to the user tile. I’ll show these settings, by showing the available options of the user tile and the related setting. In this section the following settings can be configured (as shown in the screenshot):

  • HideChangeAccountSettings;
  • HideLock;
  • HideSignOut;
  • HideSwitchAccount;
  • HideUserTile.

More information

For more information about the Policy CSP, please refer to this article about the Policy CSP.

Share

Conditional access and Google Chrome on Windows 10

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

Win10AccountsExt

Introduction

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

End-user experience

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

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

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

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

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

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

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


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

Share

Conditional access and app enforced restrictions

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

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

Configuration

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

Important notes

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

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

Block access to mobile apps and desktop clients

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

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

Use app enforced restrictions for browsers

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

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

Allow limited access in SharePoint Online

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

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

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

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

End-user experience

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

Windows10_SPO Windows10_SPO_Doc
IMG_0102 IMG_0103
Screenshot_20170409-075823 Screenshot_20170409-081417

More information

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

Share

Easily configure desktop and lock screen image via Windows 10 MDM

This blog post uses the Personalization configuration service provider (CSP) to manage the desktop and lock screen image on Windows 10 devices. This CSP was added in Windows 10, version 1703, which is currently available as Insider Preview build.

This blog post is about the ability to easily configure separate images for the desktop and the lock screen on Windows 10 devices. Before Windows 10, version 1703, this was possible by using an MSI or by using the EnforceLockScreenAndLogonImage setting. However, the latter setting was only able to configure the lock screen image and not the desktop image. Windows 10, version 1703, introduces the Personalization CSP, which enables the administrator to manage the desktop and lock screen image. In this post I’ll briefly go through the available settings in the Personalization CSP and I’ll show how to configure the desktop and lock screen image via Microsoft Intune hybrid and Microsoft Intune standalone. I’ll end this post by showing the end-user experience.

Configuration

Now let’s start with the configuration. Like last week I’ll split the configuration in two sections. The first section is about the available settings in the Personalization CSP and the second section is about the configuration of the desktop and lock screen image.

Available settings

As the Personalization CSP is new in Windows 10, version 1703, I thought it would be good to briefly go through the available settings. The root node for the Personalization CSP is ./Vendor/MSFT/Personalization and it contains the following settings.

Setting Description
DesktopImageUrl This setting allows the administrator to specify an image to be used as desktop image.
DesktopImageStatus This setting allows the administrator to query the status of the desktop image.
LockScreenImageUrl This setting allows the administrator to specify an image to be used as lock screen image. 
LockScreenImageStatus This setting allows the administrator to query the status of the lock screen image.

Configure settings

After going through the available settings in the Personalization CSP, it’s good to know that only the DesktopImageUrl and the LockScreenImageUrl are configurable settings. The other two settings can only be used to query the status. To configure the desktop and lock screen image, the following OMA-URI configurations can be used (in both cases the data type and value are the same):

  • OMA-URI – Desktop image: ./Vendor/MSFT/Personalization/DesktopImageUrl
  • OMA-URI – Lock screen image: ./Vendor/MSFT/Personalization/LockScreenImageUrl
  • Data type: String
  • Value: [<PATH>\<FILE>]
    • In this value <PATH> can be a http(s) url, or a file url;
    • In this value <FILE> can be a jpg, jpeg or png image.

This configuration information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

Personalization_IntuneHybridThe 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.

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

Microsoft Intune standalone (Azure portal)

Personalization_IntuneStandaloneThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile, or add a row to an existing custom profile. With a 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.

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

End-user experience

As usual, let’s end this post with the end-user experience. Before really going to the end-user experience, it’s good to show an easy method to verify the configuration. The configuration can be verified In the registry, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP. At this location it shows the url and the status of the desktop and lock screen image. Even better, it also show the local path of both images. In other words, whether the image is local, or remote, it will always be cached and used from a local location, as shown below.

Registry_Personalization

The real end-user experience is, of course, not in the registry. The real en-user experience can be easily found when logging on to the configured Windows 10 device. The desktop image will be configured, as shown below on the right, and the lock screen image will be configured, as shown below on the left.

LogonScreen_Example Desktop_Example

More information

For more information about the Personalization CSP, please refer to this article about the Personalization CSP.

Share

Require BitLocker drive encryption via Windows 10 MDM

This blog post uses the BitLocker configuration service provider (CSP) to manage drive encryption on Windows 10 devices. This CSP was added in Windows 10, version 1703, which is currently available as Insider Preview build.

This blog post will be about requiring BitLocker drive encryption on Windows 10 devices. Until Windows 10, version 1703, this was not possible. It was only possible to create a compliance policy that would block access to Windows 10 devices without BitLocker enabled. Windows 10, version 1703, introduces the BitLocker CSP, which enables the administrator to manage BitLocker settings via Windows 10 MDM. In this post I’ll briefly go through the available settings in the BitLocker CSP and I’ll show how to require BitLocker drive encryption via Microsoft Intune hybrid and Microsoft Intune standalone. I’ll end this post by showing the end-user experience.

Configuration

I’ll split the configuration in two sections. The first section about the available settings in the BitLocker CSP and the second section about how to configure the BitLocker drive encryption requirement. As the BitLocker CSP is new in Windows 10, version 1703, I thought it would be good to briefly go through the available settings.

Available settings

Let’s start by going through the available settings in the BitLocker CSP. The root node for the BitLocker CSP is ./Device/Vendor/MSFT/BitLocker and it contains the following settings.

Setting Description
RequireStorageCardEncryption This setting allows the administrator to require storage card encryption on the device.
RequireDeviceEncryption This setting allows the administrator to require encryption to be turned on by using BitLocker.
EncryptionMethodByDriveType This setting allows the administrator to configure the algorithm and cipher strength used by BitLocker.
SystemDrivesRequireStartupAuthentication This setting allows the administrator to configure whether additional authentication is required each time the computer starts.
SystemDrivesMinimumPINLength This setting allows the administrator to configure a minimum length for a TPM startup PIN.
SystemDrivesRecoveryMessage This setting allows the administrator to configure the recovery message or replace the existing URL.
SystemDrivesRecoveryOptions This setting allows the administrator to control how operating system drives are recovered.
FixedDrivesRecoveryOptions This setting allows the administrator to control how fixed data drives are recovered.
FixedDrivesRequireEncryption This setting allows the administrator to require BitLocker for fixed data drives to be writable on a computer.
RemovableDrivesRequireEncryption This setting allows the administrator to require BitLocker for a removable drive to be able to write data.

Configure settings

Now that I’ve been through all the available settings in the BitLocker CSP, let’s have closer look at the setting that enables the administrator to require BitLocker drive encryption. That’s the setting RequireDeviceEncryption. However, keep in mind that this still does require an interaction with the end-user. The end-user has to provide information about the currently used drive encryption and the end-user has to start the BitLocker drive encryption process. More about that in the end-user experience section. To require BitLocker drive encryption the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption
  • Date type: Integer
  • Value: 1

This configuration information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

BitLocker_IntuneHybridThe 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.

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

Microsoft Intune standalone (Azure portal)

BitLocker_IntuneStandaloneThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device configuration. Create a new profile, or add a row to an existing custom profile. With a 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.

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

End-user experience

Let’s end this post with the end-user experience. As I mentioned earlier, the end-user must still interact with the messages generated by the configuration to require BitLocker drive encryption. Once the configuration arrives at the Windows 10 device, the end-user will receive a toast message stating that “Encryption is needed”, as shown below on the left. After selecting that notification, the end-user will receive a dialog box with the question “Are you ready to start encryption”, as shown below on the right.

BitLocker_ToastMessage BitLocker_DialogBox

After checking the applicable boxes and clicking Yes, the end-user will get the standard BitLocker Drive Encryption wizard. During that wizard the end-user must specify the location to back up the recovery key, choose the encryption method and the end-user can start the encryption.

More information

For more information about the BitLocker CSP, please refer to this article about the BitLocker CSP.

Share

Offboard Windows 10 devices of Windows Defender Advanced Threat Protection

This week a follow-up on my post of last week. Last week was about onboarding Windows 10 devices for Windows Defender Advanced Threat Protection (ATP) and this week will be about offboarding Windows 10 devices of Windows Defender ATP. For devices that are leaving the company, for whatever reason, it’s good to first offboard those devices of Windows Defender ATP. That will remove the Windows Defender ATP settings from the device and the device will stop collecting and sending data. In this post I’ll show how to offboard Windows 10 devices, via Configuration Manager and Microsoft Intune, and I’ll show the end result. The steps in this post will be similar to the steps in the post of last week.

Configuration

Just like last week, there are multiple methods available to offboard Windows 10 devices of Windows Defender ATP. Those methods are Group Policy, Configuration Manager, mobile device management (including Microsoft Intune) and a local script. I’ll have a closer look at the configurations for offboarding Windows 10 devices via Configuration Manager and Microsoft Intune.

Create offboarding configuration file

Before starting with the configuration, it’s required to create an offboarding configuration file. The process for this is fairly simple and straightforward. Logon to the Windows Defender Security Center and select Endpoint Management. Now select Endpoint offboarding, select the configuration method and download the required file, as shown below. After selecting download, an additional confirmation message will show, mentioning the expiration date of the offboarding package. For security reasons an offboarding package will always expire after 30 days.

System Center Configuration Manager Mobile Device Management
WDATP_SCCM_Offboarding WDATP_MDM_Offboarding

Configure endpoints using Configuration Manager

The first configuration method that I would like to show is using Configuration Manager, by creating and deploying a Windows Defender ATP Policy.  This configuration method is only supported on Windows 10 devices, version 1607 and later, running the Configuration Manager client. On-premises mobile device management and Microsoft Intune hybrid MDM-managed computers are not supported. The following 6 steps show how to create the Windows Defender ATP Policy. After that, simply deploy the created policy.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Endpoint Protection > Windows Defender ATP Policies;
2 On the Home tab, in the Create group, click Create Windows Defender ATP Policy to open the Create Windows Defender ATP Policy Wizard;
3

CWDATPPW_General_OffOn the General page, provide the following information and click Next;

  • Name: Provide a unique name for the Windows Defender ATP policy;
  • Description: (Optional) Provide a description about the Windows Defender ATP policy;
  • Select Offboarding – Remove devices from the online service (for example, when the device is no longer managed).
4

CWDATPPW_ConfigFile_OffOn the Configuration File page, Browse to the WindowsDefenderATP.offboarding file that is available in the downloaded WindowsDefenderATPOffboardingPackage.zip file and click Next;

Note: The default name of the offboarding package, also contains the expiration date of the offboarding package.

5 On the Summary page, click Next;
6 On the Completion page, click Close.

Note: Make sure that a device is not targeted with an onboarding and offboarding configuration at the same time. This might cause unpredictable behavior.

Configure endpoints using Microsoft Intune

The second configuration method that I would like to show is using Microsoft Intune hybrid and Microsoft Intune standalone, Windows Defender ATP supports Microsoft Intune by providing OMA-URI settings to create policies to manage endpoints. To achieve this the following OMA-URI configuration can be used:

  • OMA-URI: ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Offboarding
  • Date type: String
  • Value: [Content of the WindowsDefenderATP.offboarding file that is available in the downloaded WindowsDefenderATPOffboardingPackage_valid_until_yyyy-mm-dd.zip file]

Just to make sure that it’s absolutely clear, the value, of the OMA-URI configuration, is literally a copy-paste action of the content available in the WindowsDefenderATP.offboarding file. This information can be used in Microsoft Intune hybrid and Microsoft Intune standalone, by using the configuration guidelines shown below.

Environment Configuration guidelines
Microsoft Intune hybrid

CI_WindowsATP_OffboardingThe 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.

CIRule_WindowsATP_OffboardingIn this case, I also provide a screenshot of the configured rule. Again to make absolutely sure that it’s a lot of characters that the rule should comply to.

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

Microsoft Intune standalone

CP_WindowsATP_OffboardingThe configuration in Microsoft Intune standalone can be performed by starting the Create Policy for Custom Configuration (Windows 10 Desktop and Mobile and later) in the Microsoft Intune administration console. Navigate to the OMA-URI Settings section and the custom settings can be added by using the earlier mentioned OMA-URI settings.

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

Note: Make sure that a device is not targeted with an onboarding and offboarding configuration at the same time. This might cause unpredictable behavior.

End result

Let’s end this blog post by having a look at the end result. I’ll do that by showing that a successful offboarding can be verified in the registry of the Windows 10 device, as shown below. The OnboardingState should be set to 0.

WDATP_Registry_Offboarding

More information

For more information about Windows Defender ATP and the offboarding, please refer to the following articles:

Share