Easily configuring the Microsoft Enterprise SSO plug-in for Apple devices

This week is all about the Microsoft Enterprise SSO plug-in for Apple devices. Both, iOS/iPadOS and macOS devices. That plug-in provides single sign-on (SSO) for Azure AD accounts across all apps that support the enterprise SSO feature of Apple. The plug-in is provided on iOS/iPadOS devices as an extension of the Microsoft Authenticator app and the plug-in is provided on macOS devices as an extension of the Company Portal app. The extensions can be enabled by using Microsoft Intune. In this post I’ll start with having a look at the configuration options, followed with the configuration steps. I’ll end this post by having a look at the end-user experience.

Important: Keep in mind that, at the moment of writing, this is still preview functionality.

Configuration options for the Microsoft Enterprise SSO plug-in

Let’s start by having a look at the configuration options for the Microsoft Enterprise SSO plug-in. The Microsoft Enterprise SSO plug-in, is a redirect-type SSO app extension. That plug-in provides SSO for Azure AD accounts across all apps that support the enterprise SSO feature of Apple and that authenticate via Azure AD. That includes accessing websites via supported browsers. In those cases, the SSO plug-in acts as an advanced authentication broker. The SSO plug-in is provided on iOS/iPadOS devices as an extension of the Microsoft Authenticator app and the SSO plug-in is provided on macOS devices as an extension of the Company Portal app. Configuring the SSO app extension will enable the SSO plug-in. The redirect SSO app extension configuration, for iOS/iPadOS and macOS devices, is provided in the table below.

PropertyiOS/iPadOSmacOS
TypeRedirectRedirect
Extension identifiercom.microsoft.azureauthenticator.ssoextensioncom.microsoft.CompanyPortalMac.ssoextension
Team identifierSGGM6D27TKUBF8T346G9
URLshttps://login.microsoftonline.comhttps://login.microsoftonline.com
https://login.microsoft.comhttps://login.microsoft.com
https://sts.windows.nethttps://sts.windows.net
https://login.partner.microsoftonline.cnhttps://login.partner.microsoftonline.cn
https://login.chinacloudapi.cnhttps://login.chinacloudapi.cn
https://login.microsoftonline.dehttps://login.microsoftonline.de
https://login.microsoftonline.ushttps://login.microsoftonline.us
https://login-us.microsoftonline.comhttps://login-us.microsoftonline.com

Note: The information in the table above is taken from a configured iPadOS device (Settings > General > Device Management > Management Profile > More Details > Authenticator) and a configured macOS device (System Preferences > Profiles > Extensible Single Sign On Profile – {GUID}). Those devices were configured by using the configuration steps provided in this post.

This all means that, to use the SSO app extension, an administrator should make sure that the correct app is installed and that the correct configuration is applied. That configuration can only be applied when the device is managed. Once the correct app is installed and the SSO app extension is configured, users can enter their credentials to sign in, and establish a session on their Apple device. That session is then used across the different supported apps, on their Apple device, without requiring users to authenticate again.

Note: Make sure to use the latest version of the Microsoft Authenticator app (iOS/iPadOS) and the latest version of the Company Portal app (macOS).

In addition to the default behavior, there are additional configuration options available to extend the SSO functionality to additional apps. Those settings are described in the table below and are recommended.

KeyTypeValueDescription
browser_sso_interaction_enabledInteger1This key and value enables non-MSAL apps and Safari browser to do the initial bootstrapping and get a shared credential.
disable_explicit_app_promptInteger1This key and value restricts ability of both native and web applications to force an end-user prompt on the protocol layer and bypass SSO.

Configuring the Microsoft Enterprise SSO plug-in

Once the configuration options and requirements are clear, it’s time to look at the configuration of the Microsoft Enterprise SSO plug-in. The configuration for iOS/iPadOS and macOS devices is identical. Only the platform is different. That platform difference will make sure that the correct configuration is applied to the correct app. The following eight steps walk through the steps to configure the Microsoft Enterprise SSO plug-in.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Configuration profiles to open the Devices | Configuration profiles blade
  2. On the Devices | Configuration profiles blade, select Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create
  • Platform: Depending on the platform of choice select iOS/iPadOS or macOS
  • Profile: Select Device features
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the device features profile
  • Description: (Optional) Provide a valid description for the device features profile
  1. On the Configuration settings page, configure at least the Single sign-on app extension section by providing the following information (see Figure 1 for an example configurations for iOS/iPadOS and see Figure 2 for an example configurations for and macOS) and click Next
  • SSO app extension type: Select Microsoft Azure AD
  • Enable shared device mode: Select Not configured
  • App bundle IDs: Add the bundle identifiers of any additional app that should use the Microsoft Azure AD single sign-on extension and that doesn’t use the (latest) Microsoft libraries
  • Additional configuration: Configure the earlier mentioned key-value pairs
    • Key: browser_sso_interaction_enabled; Type: Integer; Value: 1
    • Key: disable_explicit_app_prompt; Type: Integer; Value: 1

Note: When the earlier described configuration is not sufficient, because more URLs are required, configure a SSO app extension type of Redirect, start with providing the described configuration and add the additional URLs.

  1. On the Scope tags page, configure the required scope tags click Next
  2. On the Assignments page, configure the assignment to the required users and/or devices and click Next
  3. On the Review + create page, verify the configuration and click Create

End-user experience with the Microsoft Enterprise SSO plug-in

Now let’s end by having a look at the end-user experience with a configured Microsoft Enterprise SSO plug-in. To create the best picture, I’ve used a Safari browser on a macOS device and the experience was awesome. That experience is shown below, in Figure 3, by navigating to portal.office.com and simply picking the required account.

Note: The end-user experience is identical on iOS/iPadOS devices.

More information

For more information about the Microsoft Enterprise SSO plug-in and configuring device features on iOS/iPadOS and macOS devices, refer to the following docs.

Getting familiar with Microsoft Tunnel Gateway

This week is a follow-up on my post of a few weeks ago about getting started with Microsoft Tunnel Gateway. In that post I’ve showed how to get started with Microsoft Tunnel Gateway and in this post I want to show how to get more familiar with Microsoft Tunnel Gateway. Getting to know the installation location, getting to know the configuration files, getting to know the log files and getting to know a few important commands for more information. All of that will eventually help with getting more familiar with Microsoft Tunnel Gateway. In this post I’ll look a few directories, files, logs and commands. Also in that order.

Directories

Let’s start with a few directories. Actually, one directory and a few sub-directories. After the installation of Microsoft Tunnel Gateway, a few important directories become available. Below are the most important directories, including a short description.

DirectoryDirectory description
/etc/mstunnelThis is the root directory that contains the configuration.
/etc/mstunnel/certsThis is the directory that contains the TLS certificate.
/etc/mstunnel/privateThis is the directory that contains the Intune Agent certificate and the TLS private key.

Tip: When navigating to the root directory, a simple ls command will show all the available directories. Keep in mind that the permissions will be denied for a normal user and that the usage of sudo is required.

Files

Within the mentioned root directory, many files are added during the different stages of the installation of Microsoft Tunnel Gateway. Below are the most important files, including a short description and an example.

FileFile description
AgentSettings.jsonThis file contains the generic server configuration information (name, site, and more).
admin-settings.jsonThis file contains the configuration as configured in the Server configuration in Intune.
agent-info.jsonThis file contains the agent information (Intune tenant Id, Azure AD tenant Id, and more).
Images_configuredThis file contains the hash values of the current images.
ocserv-sec.jsonThis file contains the VPN server configuration information.
ocserv.confThis file contains the VPN server configuration.
oidc.jsonThis file contains the OpenID configuration.
version-info.jsonThis file contains the version information (configuration version, docker version, and more).
env.shThis file contains the environment variables (like the proxy addresses) when used.

Tip: When looking at the files in the directory, a simple cat command will print the content in the terminal. Keep in mind that the permissions will be denied for a normal user and that the usage of sudo is required.

Note: AgentLoggingInfo.json, AgentMonitorLoggingInfo.json, GeneralLoggingInfo.json, JournalLoggingInfo.json, OcservErrorLoggingInfo.json, OcservLoggingInfo.json and VpnLoggingInfo.json only contain the last processed logs date and mstunnel-agent-state and mstunnel-server-state only contains the status of the service.

AgentSetting.json

The AgentSettings.json shows the generic server properties. That includes the id of the site that the server belongs to, the name of the server, the id of the server and the id of the configurations that is applied to the server. Below is an example of an AgentSettings.json file.

{
	"SiteId":"n0tm1n3-da01-4633-9ad4-82bf34a93ab4",
	"ServerName":"cldmtg01",
	"ServerId":"n0tm1n3-3d69-4d8f-bdc0-e0c0e929bb6c",
	"ConfigId":"n0tm1n3-5c3c-43a9-8324-deb553da795b",
	"ServerImageTime":"2020-10-13T20:18:26.2199173+00:00",
	"AgentImageTime":"2020-10-13T20:18:26.1972649+00:00",
	"PatchExpirationDate":"0001-01-01T00:00:00+00:00"
}

admin-settings.json

The admin-settings.json shows the configured properties of the Server configuration. This file should only be adjusted by using Intune and not manually. Below is an example of an agent-settings.json file.

{
  "DisplayName": "Default server configuration",
  "Network": "192.168.50.1/24",
  "DNSServers": [
    "192.168.20.1"
  ],
  "DefaultDomainSuffix": "",
  "RoutesInclude": [],
  "RoutesExclude": [],
  "ListenPort": 443,
  "ConfigVersion": 637370578342241628,
  "SplitDNS": [],
  "AditionalSettings": []
}

agent-info.json

The agent-info.json shows the basic agent properties. That includes the id of the agent, the id of the Intune tenant that the server belongs to, the id of the Azure AD tenant that the server belongs to and the certificate information. Below is an example of an agent-info.json file.

{
  "AgentId": "n0tm1n3-09ff-4e0b-8c0b-0e1b7d6cb5fb",
  "IntuneTenantId": "n0tm1n3-8b8f-428c-a3f6-774ec1f94b6d",
  "AADTenantId": "n0tm1n3-1ce1-41db-8aff-4c59298d4ba9",
  "Type": 8,
  "Certificate": null,
  "RenewalDate": "2021-08-20T10:34:01+00:00"
}

Images_configured

The Images_configured show the hash values of the installed images. That information can be used to identify the version of the installed images. Below is an example of an Images_configured file.

mst_use_custom_image=""
agentImageDigest="sha256:3d888864ecafa1d8c05754e3059519a2cf0d4ca56a234e13f60431cff9ba152b"
serverImageDigest="sha256:525f329010088bd4a27e930e613635dc3cbcadd0611011c6d5d8f5e1d087cb41"

ocserv-sec.json

The ocserv-sec.json shows the VPN server properties. That includes the authentication configuration that is used and the certificate configuration that is used. Below is an example of an ocserv-sec.json file.

{
  "StatsReportTime": 60,
  "StatsResetTime": 3600,
  "MaxClients": 5500,
  "RateLimit": 100,
  "KeepAlive": 32400,
  "AuthTimeout": 40,
  "MinReauthTime": 300,
  "Auth": "oidc[config=/etc/ocserv/oidc.json]",
  "CertPath": "/etc/ocserv/certs/site.crt",
  "KeyPath": "/etc/ocserv/private/site.key",
  "PinPath": null,
  "UseOcctl": true,
  "Rekey": "ssl",
  "PidFile": "/var/run/ocserv.pid",
  "SockeFile": "/var/run/ocserv-socket",
  "RunAsUser": "nobody",
  "RunAsGroup": "nogroup",
  "IsolateWorkers": true,
  "Device": "ma-tun",
  "CookieTimeout": 300,
  "PersistentCookies": true,
  "MobileDpd": 1800,
  "Dpd": 240,
  "TryMtuDiscovery": true,
  "TlsPriorities": "Secure256:-CIPHER-ALL:\u002BAES-256-GCM:-KX-ALL:\u002BECDHE-RSA:-MAC-ALL:\u002BAEAD:-VERS-TLS-ALL:\u002BVERS-TLS1.3:\u002BVERS-TLS1.2:-COMP-ALL",
  "MatchTlsDtlsCiphers": true,
  "DtlsLegacy": false,
  "ConnectScript": "/usr/local/sbin/ocserv-telemetry.sh",
  "DisconnectScript": "/usr/local/sbin/ocserv-telemetry.sh",
  "ServerDrainMs": 15000
}

ocserv.conf

The ocserv.conf shows the VPN server configuration. That includes the network configuration, the authentication configuration and the certificates that are used. Below is an example of an ocserv.conf file.

ipv4-network = 192.168.50.1/24
dns = 192.168.20.1
route = default
tcp-port = 443
udp-port = 443
server-stats-reset-time = 3600
max-clients = 5500
rate-limit-ms = 100
auth = oidc[config=/etc/ocserv/oidc.json]
server-cert = /etc/ocserv/certs/site.crt
server-key = /etc/ocserv/private/site.key
use-occtl = True
rekey-method = ssl
pid-file = /var/run/ocserv.pid
socket-file = /var/run/ocserv-socket
run-as-user = nobody
run-as-group = nogroup
isolate-workers = True
device = ma-tun
cookie-timeout = 300
persistent-cookies = True
mobile-dpd = 1800
dpd = 240
try-mtu-discovery = True
tls-priorities = Secure256:-CIPHER-ALL:+AES-256-GCM:-KX-ALL:+ECDHE-RSA:-MAC-ALL:+AEAD:-VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2:-COMP-ALL
match-tls-dtls-ciphers = True
dtls-legacy = False
connect-script = /usr/local/sbin/ocserv-telemetry.sh
disconnect-script = /usr/local/sbin/ocserv-telemetry.sh
server-drain-ms = 15000

oidc.json

The oidc.json shows the OpenID properties. That includes the sts-url that is used and the issuer. Below is an example of the oidc.json file.

{
  "openid_configuration_url": "https://sts.windows.net/n0tm1n3-1ce1-41db-8aff-4c59298d4ba9/v2.0/.well-known/openid-configuration",
  "user_name_claim": "oid",
  "required_claims": {
    "aud": "n0tm1n3-9681-447a-974d-d19f668fcd88",
    "acct": 0,
    "iss": "https://sts.windows.net/n0tm1n3-1ce1-41db-8aff-4c59298d4ba9/"
  }
}

version-info.json

The version-info.json shows the version information of the different components. That includes, the version of the configuration, the version of Docker, the version of the different images and the version of the operating system. Below is an example of the version-info.json file.

{
    "ConfigVersion": 637370578342241628,
    "DockerVersion": "Docker version 19.03.13, build 4484c46d9d",
    "AgentImageHash": "sha256:3d888864ecafa1d8c05754e3059519a2cf0d4ca56a234e13f60431cff9ba152b",
    "AgentCreateDate": "2020-10-09T18:50:54.560584825Z",
    "ServerImageHash": "sha256:525f329010088bd4a27e930e613635dc3cbcadd0611011c6d5d8f5e1d087cb41",
    "ServerCreateDate": "2020-10-09T18:49:24.487117764Z",
    "HostOS": "Ubuntu 20.04.1 LTS",
    "HostKernel":"5.4.0-48-generic"
}

Commands

When looking at the different commands that are available for basic interaction with Microsoft Tunnel Gateway, locally on the Linux server, journalctl is important for querying the journal (the place for logs) and mst-cli is important for actually interacting with Microsoft Tunnel Gateway.

Logs

With the latest update of Microsoft Tunnel Gateway, the logs are logged in the Linux server logs in the syslog format. That also means that the standard journalctl command can be used view the journal (the logs) and that the -t parameter can be used for showing entries with only the specific identifier. When looking at the Microsoft Tunnel Gateway log entries, the identifiers in the table below are important.

IdentifierIdentifier description
ocservThis identifier only displays the VPN server logs.
mstunnel-agentThis identifier only displays the Intune agent logs.
mstunnel_monitorThis identifier only displays the monitoring task logs.

An example for using journalctl for displaying the Intune agent logs, can be found below.

journalctl -t mstunnel_monitor

Tip: When looking at the logs, the -f parameter will follow the log and display a rolling log. For more an overview of all the available parameters, use the -h parameter.

Interface

For local interaction with Microsoft Tunnel Gateway, Microsoft provides the mst-cli command-line tool. This command-line tool is available on the Linux server after the installation of Microsoft Tunnel Gateway and can be found at /usr/sbin/mst-cli. This command-line tool can be used to get some basic interaction with Microsoft Tunnel Gateway, like getting information, restarting the service and server and even uninstalling Microsoft Tunnel Gateway.

Note: Keep in mind that when running the mst-cli command-line tool, the usage of sudo is required.

When looking at the mst-cli command-line tool, the following commands are the first layer of local interaction capabilities with Microsoft Tunnel Gateway.

CommandCommand description
agentOperate commands on the agent component (use the -h command for more command options).
serverOperate commands on the server component (use the -h command for more command options).
uninstallUninstall Microsoft Tunnel Gateway.
eulaShow the EULA that was accepted during the installation of Microsoft Tunnel Gateway.
import_certImport the TLS certificate.

An example for using mst-cli, can be found below. This example will show the accepted EULA.

sudo /usr/sbin/mst-cli eula

Important: Be careful with the uninstall parameter of the mst-cli command-line tool, because at this moment the uninstall will start immediately without verification.

agent parameter

When looking at the agent command, the following commands are the options for interacting with the agent component.

CommandCommand description
statusShows the status of the agent component.
startStart the service of the agent component.
stopStop the service of the agent component.
restartRestart the service of the agent component.

An example for using mst-cli agent, can be found below. This example will show the status of the agent component.

sudo /usr/sbin/mst-cli agent status

server parameter

When looking at the server command, the following commands are options for interacting with the server component.

CommandCommand description
statusShows the status of the server component.
startStart the service of the server component.
stopStop the service of the server component.
restartRestart the service of the server component.
showShow various stats of the server component (use the -h command for more command options). This command can show a lot of stats, including the statistics of the server and the connected users.

An example for using mst-cli server, can be found below. This example will show the status of the server component.

sudo /usr/sbin/mst-cli server status

Tip: For an overview of all the available commands use sudo /usr/sbin/mst-cli -h. For an overview of the available commands for a specific component use something similar to sudo /usr/sbin/mst-cli server show -h.

More information

For more information about the further details about Microsoft Tunnel Gateway, refer to the following docs.

Easily exporting Intune reports using Microsoft Graph

This week a short blog post about Intune reports and more specifically about exporting Intune reports by using Microsoft Graph. Since recently, all reports that are available in the (new) Intune reporting infrastructure are available for export. That export can be achieved from a single top-level export API. Simply use Microsoft Graph API to make the required HTTP call(s). The result of the HTTP call(s) will be a downloadable ZIP-file that contains a CSV-file. That CSV-file contains an export of the latest real-time information and can be imported in EXCEL for some simple data analyses, or in Power BI for more advanced data analyses and visualizations. In this post I’ll show how to use Microsoft Graph to export Intune reports and I’ll show the results of the export.

Export Intune reports

Let’s start with the easiest part, which is knowing the correct Microsoft Graph API endpoint. That’s the endpoint below.

https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs

The more challenging part is the parameters that can be submitted in the request body. Basically there are the following three main parameters that can be submitted in the request body to define the export request:

  • reportName: This is a required parameter (type String) that contains the name of the report that should be exported.
  • filter: This is an optional parameter, for most reports, (type String) that can be used to filter the dataset.
  • select: This is an optional parameter (type String collection) that can be used to select specific columns of the dataset. When nothing is specified, a default set of columns, which for most reports is the entire dataset, is selected.

Note: The documentation about exporting reports provides information about the available reports, the name of the reports, the information that can be used to filter the data and the properties that can be used to select specific columns of the data.

Now when making the request, the reportName parameter must be provided as part of the request body. That parameter contains the name of the report that should be exported. Below is an example of an export request for the Devices report that filters on specific data and only selects specific columns. That example can be used in a HTTP POST method on the request. The HTTP POST method is used to perform an action to export the report. A simple method to perform this action is by using Microsoft Graph Explorer. In Graph Explorer, simply select POST, provide the mentioned endpoint as URL, provide the example below as request body and click Run query.

{
    "reportName": "Devices",
    "filter": "(ManagementAgents eq '2') and (OwnerType eq '1')",
    "select": [
        "DeviceName",
	"DeviceType",
	"Ownership",
        "ManagedBy",
        "managementState",
        "complianceState",
        "OS",
        "OSVersion",
        "LastContact",
        "UPN"
    ],
    "localization": "true",
    "ColumnName": "ui"
}

Note: In most cases I would suggest to not filter the data. I only used a filter to show how it works. A tool like Power BI can be used to actually filter the data and to create some nice data analyses and visualizations. Not filtering the data, when exporting the data, leaves more room for a good interpretation of the data.

After posting the provided HTTP POST method on the request, Microsoft Graph returns a response message. That response message contains the information that was provided in the request and the id and status of the request. Especially the id is important, as that id should be used to follow the status of the request.

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#deviceManagement/reports/exportJobs/$entity",
    "id": "Devices_115d909a-7574-4e94-b236-e6e082ab6788",
    "reportName": "Devices",
    "filter": "(ManagementAgents eq '2') and (OwnerType eq '1')",
    "select": [
        "DeviceName",
        "DeviceType",
        "Ownership",
        "ManagedBy",
        "managementState",
        "complianceState",
        "OS",
        "OSVersion",
        "LastContact",
        "UPN"
    ],
    "format": "csv",
    "snapshotId": null,
    "status": "notStarted",
    "url": null,
    "requestDateTime": "2020-10-07T09:42:06.388268Z",
    "expirationDateTime": "0001-01-01T00:00:00Z"
}

To follow the status of the export request, the id can be used to query for an updated status. In Graph Explorer, simply select Get, provide something similar to the example below (just adjust the provided id) as the URL and click Run query.

https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs('Devices_115d909a-7574-4e94-b236-e6e082ab6788')

Once the status of the export request changes to completed, the url in the response will contain a link to a downloadable ZIP-file in a storage blob.

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#deviceManagement/reports/exportJobs/$entity",
    "id": "Devices_115d909a-7574-4e94-b236-e6e082ab6788",
    "reportName": "Devices",
    "filter": "(ManagementAgents eq '2') and (OwnerType eq '1')",
    "select": [
        "DeviceName",
        "DeviceType",
        "Ownership",
        "ManagedBy",
        "managementState",
        "complianceState",
        "OS",
        "OSVersion",
        "LastContact",
        "UPN"
    ],
    "format": "csv",
    "snapshotId": null,
    "status": "completed",
    "url": "https://amsub0201repexpstorage.blob.core.windows.net/a3283525-8b8f-428c-a3f6-774ec1f94b6d/Devices_115d909a-7574-4e94-b236-e6e082ab6788.zip?sv=2019-02-02&sr=b&sig=Rm301BTLjYTEmTNl7WHk1UL2bu6TKYIhezlpH8lzveU%3D&skoid=1db6df02-4c8b-4cb3-8394-7ac2390642f8&sktid=72f988bf-86f1-41af-91ab-2d7cd011db47&skt=2020-10-07T09%3A43%3A10Z&ske=2020-10-07T15%3A42%3A52Z&sks=b&skv=2019-02-02&se=2020-10-07T15%3A42%3A52Z&sp=r",
    "requestDateTime": "2020-10-07T09:42:06.388268Z",
    "expirationDateTime": "2020-10-07T15:42:52.0376315Z"
}

Intune reports result

The downloaded ZIP-file has the name of the id of the generated report. That ZIP-file contains a CSV-file and that also has the name of the id of the generated report. After exporting the CSV-file, the data can be imported in anyone’s favorite tool. That can be as simple as EXCEL, or a bit more advanced as Power BI. Especially the latter provides some real (simple) capabilities to transform this data into a report. Below are some examples. Figure 1 provides a quick overview of the exported data in a table format.

Figure 2 also provides a quick overview of a similar exported dataset in a table format, but in this case without the filtering of the data. The main goal is to show my earlier note, which will be even clearer with the next figure.

Figure 3 provides an overview of a visualization of both datasets. The main goal is to show that the non-filtered dataset provides a lot more flexibility when analyzing the data. The totally green pie charts are the filtered dataset and the colored pie charts are the non-filtered datasets.

More information

For more information about exporting Intune reports by using Graph APIs, refer to the following docs:

Getting started with Microsoft Tunnel Gateway

This week is all about the just, during Microsoft Ignite 2020, released Microsoft Tunnel Gateway (often referred to as Microsoft Tunnel or Tunnel). Microsoft Tunnel Gateway is a new solution that can provide iOS and Android devices with access to on-premises resources. In other words, Microsoft Tunnel Gateway is a VPN solution. The best part of Microsoft Tunnel Gateway is that it fully integrates with a Microsoft 365 solution and that it’s included in the existing Microsoft Intune license. That integration is also one of the strongest points of Microsoft Tunnel Gateway, as it also provides single sign-on capabilities and even conditional access. All of that with a relatively simple deployment. Also, to work with Microsoft Tunnel Gateway, Microsoft released the Microsoft Tunnel app for iOS and Android. That app can be deployed to users and can be used to provide access via Microsoft Tunnel Gateway. That provides a truly great experience for the user. In this post I want to walk through the prerequisites for Microsoft Tunnel Gateway, followed with the different configurations to configure Microsoft Tunnel Gateway. I’ll end this post by distributing the app and configurations to the user and by looking at the user experience.

Important: At this moment, Microsoft Tunnel Gateway is a solution for iOS and Android only.

Prerequisites for Microsoft Tunnel Gateway

For this post it’s important to start with a list of prerequisites for Microsoft Tunnel Gateway. The main reason for that is that I’ll leave a few subjects out-of-scope for this post, but those subjects are important for getting started with Microsoft Tunnel Gateway. Make sure that the following is in place, before starting with Microsoft Tunnel Gateway.

  • a server with a supported Linux distribution that will be used for hosting Microsoft Tunnel Gateway
  • Docker is installed on the server to support containers on the Microsoft Tunnel Gateway server
  • a (preferably publicly) trusted TSL certificate, that contains the public FQDN of the Microsoft Tunnel Gateway server, is available for securing the connection between the devices and the Microsoft Tunnel Gateway server
  • inbound port 443 (UDP and TCP) is available on the server for a functioning Microsoft Tunnel Gateway
  • outbound port 80 (TCP) and 443 (TCP) is available on the server for interaction with Microsoft Intune
  • add Microsoft Tunnel Gateway as a cloud app to Azure AD to enable the use of Conditional Access

My setup

Also, I thought it would be a good idea for this post to provide some information about the starting point that I’ll use for the configurations that are provided throughout this post. That starting point is described below.

  • a virtual server that is running Ubuntu 20.04
  • Docker is installed on that virtual Ubuntu 20.04 server by using these configuration steps
  • a publicly trusted certificate for *.petervanderwoude.nl is available
  • an A-record is configured for vpn.petervanderwoude.nl
  • a gateway router is used to forward port 443 to the virtual Ubuntu 20.04 server

Create the server configuration

The first Microsoft Intune related configuration is the Server configuration. The Server configuration is used to create a configuration that can be applied to one or multiple Microsoft Tunnel Gateway servers. That contains the configuration that will be used for configuring the Microsoft Tunnel Gateway server. That contains information like the IP address range that is used for devices connecting to Microsoft Tunnel Gateway and the port that the Microsoft Tunnel Gateway server is listening to. This information can also be adjusted when Microsoft Tunnel Gateway is up-and-running, but that would require a restart of the server to apply the new configuration. The following five steps walk through creating the Server configuration.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Tenant administrationMicrosoft Tunnel Gateway (Preview) to open the Tenant admin | Microsoft Tunnel Gateway (Preview) blade
  2. On the Tenant admin | Microsoft Tunnel Gateway (Preview) blade, navigate to Server configurations and click Create new to open the Create server configuration wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the server configuration
  • Description: (Optional) Provide a valid description for the server configuration
  1. On the Settings page, provide the following information and click Next
  • IP address range: Provide an IP address range that is leased to devices that connect to Microsoft Tunnel Gateway
  • DNS servers: Provide DNS server addresses that are used for DNS request from devices that are connected to Microsoft Tunnel Gateway
  • DNS suffix search: (Optional) Provide a DNS suffix that is used as default domain for devices that are connected to Microsoft Tunnel Gateway
  • Split tunneling: (Optional) Provide addresses that are included or excluded from Microsoft Tunnel Gateway
  • Server port: Provide the port that Microsoft Tunnel Gateway listens to
  1. On the Review + create page, verify the information and click Create

Important: The server port will also be used for the configuration of the Microsoft Tunnel app.

Create the site

The second Microsoft Intune related configuration is creating a Site. A Site is used to create a logical group of servers that host Microsoft Tunnel Gateway. A Site contains two important configurations that are applied to all the Microsoft Tunnel Gateway servers in the site and that’s the public address and the Server configuration that should be applied. Make sure that the Site is configured correctly, as it can’t be adjusted afterwards. The following three steps walk through the creation of a Site.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Tenant administrationMicrosoft Tunnel Gateway (Preview) to open the Tenant admin | Microsoft Tunnel Gateway (Preview) blade
  2. On the Tenant admin | Microsoft Tunnel Gateway (Preview) blade, navigate to Sites and servers and click Create > New site to open the Create a site page
  3. On the Create a site page, provide the following information and click Create
  • Name: Provide a valid name for this site
  • Description: (Optional) Provide a valid description for this site
  • Public IP address or FQDN: Provide a public IP address or FQDN that is used by the devices as the connection point to to Microsoft Tunnel Gateway
  • Server configuration: Select the just created server configuration

Note: The IP address or FQDN can point to an individual server or to a load-balancing server. When there is a firewall in between, make sure to create the necessary network adjustments.

Important: The IP address must be publicly routable and the FQDN must be publicly resolvable.

Install Microsoft Tunnel Gateway

After creating the Site and the Server configuration that can be applied to a Microsoft Tunnel Gateway server, it’s time to start with the actual installation of Microsoft Tunnel Gateway on the created Linux server with Docker. The installation is performed by downloading and running the Microsoft Tunnel Gateway installation script on the Linux server with Docker installed. The Microsoft Tunnel Gateway installation script will walk through the different required actions that should be performed to get the Microsoft Tunnel Gateway server up-and-running and interacting with Microsoft Intune. The following seven steps walk through that process.

  1. Connect to the Linux server with Docker and logon
  2. Download the Microsoft Tunnel Gateway installation script by using a command like this
wget https://aka.ms/microsofttunneldownload -O mstunnel-setup
  1. Start the Microsoft Tunnel Gateway installation script by using a command like this
sudo bash mstunnel-setup
  1. When prompted by the Microsoft Tunnel Gateway installation script, accept the license agreement (EULA)
  2. When prompted by the Microsoft Tunnel Gateway installation script, copy the TLS certificate to the specified location

Important: The name of the certificate file(s) is mandatory for the Microsoft Tunnel Gateway installation script to detect the existence of the required certificate file(s).

  1. When prompted by the Microsoft Tunnel Gateway installation script, register Microsoft Tunnel Gateway with Microsoft Intune by opening a browser, navigating to https://microsoft.com/devicelogin and entering the code that was provided by the Microsoft Tunnel Gateway installation script

Tip: The browser action can be performed on a different device.

Note: The Microsoft Tunnel Gateway script will prompt to enter a GUID of the site that this Microsoft Tunnel Gateway server should join, when multiple sites are configuration in Microsoft Intune.

  1. After the Microsoft Tunnel Gateway installation script is finished, the server will show in the Microsoft Endpoint Manager admin center portal when navigating to Tenant administrationMicrosoft Tunnel Gateway (Preview) > Health status as shown below in Figure 3.

Tip: When the Microsoft Tunnel Gateway installation script is stopped, it can be restarted again by using the same installation command. The installation will continue were it was stopped.

Deploy Microsoft Tunnel app

Once Microsoft Tunnel Gateway is up-and-running and online, it’s time to look at the device configurations. The first thing of those configurations is distributing the Microsoft Tunnel app. The Microsoft Tunnel app is required for accessing resources via Microsoft Tunnel Gateway on a mobile device. As the steps differ per platform, the most common options for deploying the Microsoft Tunnel app are described below per platform.

Deploy Microsoft Tunnel app for Android

The following seven steps walk through the process of distributing the Microsoft Tunnel app to the different Android Enterprise managed devices. As this is focused on Android Enterprise, the focus is on the Managed Google Play store.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to AppsAll apps > Android to open the Android | Android apps blade
  2. On the Android | Android apps blade, click Add to open the Select app type blade
  3. On the Select app type blade, select Managed Google Play app as App type and click Select to open the Managed Google Play page
  4. On the Managed Google Play page, search for the Microsoft Tunnel app, select the app (as shown in Figure 4) and click Approve
  5. On the Approval settings dialog, select Keep approved when app requests new permissions click Done
  6. Click Sync to synchronize the approval to Microsoft Intune
  7. Assign the Microsoft Tunnel app to the required users and/or devices

Deploy Microsoft Tunnel app for iOS/iPadOS

The following seven steps walk through the process of distributing the Microsoft Tunnel app to iOS/iPadOS devices. As my lab doesn’t contain Apple Business Manager (ABM), the focus is on the normal App Store.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to AppsAll apps > iOS/iPadOS to open the iOS/iPadOS | iOS/iPadOS apps blade
  2. On the iOS/iPadOS | iOS/iPadOS apps blade, click Add to open the Select app type blade
  3. On the Select app type blade, select iOS store app as App type and click Select to open the Add app wizard
  4. On the App information page, click Search the App Store, select the Microsoft Tunnel app (as shown in Figure 5) and click Select and click Next
  1. On the Scope tags page, click Next
  2. On the Assignments page, configure the assignment to the required users and/or devices and click Next
  3. On the Review + create page, verify the configuration and click Create

Deploy VPN profile

Once Microsoft Tunnel Gateway is up-and-running and online and the Microsoft Tunnel app is deployed to the mobile devices, it’s time to configure and deploy the VPN profile. The VPN profile is used to apply the correct configuration to the Microsoft Tunnel app and to make sure that the device can connect via Microsoft Tunnel Gateway.

Deploy VPN profile on Android

The following eight steps walk through the process of creating a VPN profile for the different Android Enterprise managed devices. Even thought the corporate-owned device and personal device deployment scenarios require a separate VPN profile, the steps below are applicable for both deployment scenarios.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Android > Configuration profiles to open the Android | Configuration profiles blade
  2. On the Android | Configuration profiles blade, select Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create
  • Platform: Android Enteprise
  • Profile: Select Fully Managed, Dedicated, and Corporate-Owned Work Profile > VPN or select Work Profile > VPN, depending on the Android Enterprise deployment scenario to open the VPN wizard
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the VPN profile
  • Description: (Optional) Provide a valid description for the VPN profile
  1. On the Configuration settings page, provide the following information and click Next
  • Connection type: Select Microsoft Tunnel
  • Connection name: Provide a valid name for the VPN profile that will be shown to the user in the Microsoft Tunnel app
  • Microsoft Tunnel site: Select the Site that will be used by this VPN profile

Note: When selecting the Site, the configuration also shows the complete public address that will be used for the Microsoft Tunnel app configuration.

  • Select apps that would trigger this VPN on use: (Optional) Add apps that should use this VPN profile to send app traffic to the tunnel

Note: When adding apps to this VPN profile, this VPN profile will only be used as a per-app VPN.

  • Always-on VPN: (Optional) Select Enable to make sure that the VPN will automatically connect and reconnect
  • Automatic configuration script: (Optional) Configure the location of the automatic configuration script, when a proxy should be used
  • Address: (Optional) Configure the address of the proxy server, when a proxy should be used
  • Port number: (Optional) Configure the port number of the proxy server, when a proxy should be used
  1. On the Scope tags page, click Next
  2. On the Assignments page, configure the assignment to the required users and/or devices and click Next
  3. On the Review + create page, verify the configuration and click Create

Deploy VPN profile on iOS/iPadOS

The following eight steps walk through the process of creating a VPN profile for iOS and iPadOS devices. These steps are nearly identical to the steps for creating a VPN profile for Android Enterprise device, but only the available configurations for per-app VPN, in step 5, are slightly different.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices iOS/iPadOS > Configuration profiles to open the iOS/iPadOS | Configuration profiles blade
  2. On the iOS/iPadOS | Configuration profiles blade, select Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create
  • Platform: iOS/iPadOS
  • Profile: Select VPN to open the VPN wizard
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the VPN profile
  • Description: (Optional) Provide a valid description for the VPN profile
  1. On the Configuration settings page, provide the following information and click Next
  • Connection type: Select Microsoft Tunnel
  • Connection name: Provide a valid name for the VPN profile that will be shown to the user in the Microsoft Tunnel app
  • Microsoft Tunnel site: Select the Site that will be used by this VPN profile

Note: When selecting the Site, the configuration also shows the complete public address that will be used for the Microsoft Tunnel app configuration.

  • Per-app VPN: (Optional) Select Enable when this profile should be used for per-app VPN

Note: When enabling per-app VPN, an app should be specifically associated with the VPN profile.

  • Automatic configuration script: (Optional) Configure the location of the automatic configuration script, when a proxy should be used
  • Address: (Optional) Configure the address of the proxy server, when a proxy should be used
  • Port number: (Optional) Configure the port number of the proxy server, when a proxy should be used
  1. On the Scope tags page, click Next
  2. On the Assignments page, configure the assignment to the required users and/or devices and click Next
  3. On the Review + create page, verify the configuration and click Create

Conditional access reflections

As mentioned in the prerequisites, to facilitate a working Microsoft Tunnel Gateway in combination with Conditional Access, a Microsoft Tunnel Gateway cloud app should be registered in Azure AD. That cloud app can be used in the different Conditional Access rules within an organization. Without adding that cloud app to Azure AD, and assigning Conditional Access rules to all cloud apps, those Conditional Access rules will also be applicable to Microsoft Tunnel Gateway. Of course, that doesn’t have to be a bad thing. However, one scenario to keep in mind is with requiring an approved client app or a requiring an app protection policy. The problem is that the Microsoft Tunnel app is not yet on the list of approved client apps or on the list of app protection policy apps. That means that the Microsoft Tunnel app will be blocked when either one of those settings is applicable to Microsoft Tunnel Gateway. Requiring a compliant device is not a problem.

End-user experience

The best way to end this long post is by looking at the end-user experience. More specifically, a successful end-user experience. Below are three screenshots that are showing a working connection with Microsoft Tunnel Gateway. Figure 8 provides an example of the basic connection information. That contains information about the status. uptime, data sent and received and the name of the connection. The latter can be related to the name in the VPN profile. Figure 9 provides an example about the details of the connection. That contains information about the type of VPN (per-app versus device-wide), if always-on is enabled and also the name and status. All of that information can be related to the configured VPN profile. Figure 10 provides an example of a connection to an internal resource (with internal IP) within my environment. The icons on the top left of the screen show the successful VPN connection that is still on.

Note: An administrator can look at more details about the status of Microsoft Tunnel Gateway, by using the mst-cli command line tool on the Microsoft Tunnel Gateway server. That tool can be used to look at details, like the status, statistics, connected users and much more.

More information

For more information about Microsoft Tunnel Gateway, refer to the following docs

Remediating local administrators with proactive remediations

Like last week, this week is all about proactive remediations, a feature of Endpoint Analytics. As mentioned last week, proactive remediations are script packages that can detect common issues and remediate those issues if needed. All of that before the user even realizes that there is an issue. Those remediations can help with reducing support calls. The strength is that the remediations can be anything to address potential issues, as long as it can be addressed by using PowerShell. Each script package contains a detection script and a remediation script and that script package is deployed through Microsoft Intune. For deploying script packages, Microsoft Intune relies on the Intune Management Extension (IME).

To show the real power of proactive remediations, I’ll further develop the local administrators example of last week. Even in this modern world, local administrators are still a hot item. Last week the focus was on the detection part of proactive remediations and in this post I’ll focus on the remediation part of proactive remediations. I’ll start this post by constructing the remediation script, followed by creating the script package. I’ll end this post by verifying the results. Last week the focus for the results was locally on the device and in this post I’ll focus on the results in Microsoft Intune. This week I’ll skip the important requirements, as I’ve already documented them last week.

Constructing the remediation script

The first step is constructing the remediation script. That script should remediate the faulty configuration that was detected by the detection script. In this example, which is shown below, the remediation script is focused on a scenario in which the user of the device is a local administrator and should remain a local administrator. To fulfill that scenario the remediation script will remove all accounts, with exception of the default Administrator and the currently logged-on user, from the Administrators group. After removal of the accounts from the Administrators group, the script will add the correct accounts to the Administrators group. That will make sure that only the verified and correct accounts are members of the Administrators group and are configured on the local device. When the adjustment to the members of the Administrators group was successful, the script will return an exit code of 0 and when the adjustment to the members of the Administrators was a failure, the script will return an exit code of 1. The last line of output, before the exit code, will be displayed in the logs and can be useful information when verifying and troubleshooting the remediation script. Before using the script, make sure to adjust the array with administrator accounts to the correct list of administrators. That required adjustments is mentioned in the script example below.

#Define variables
$currentUser = (Get-CimInstance Win32_ComputerSystem).Username -replace '.*\\'
$localAdministrators = @("[YourGlobalAdminRoleSid]","[YourDeviceAdminRoleSid]") #Adjust to your local administrators
try {
$administratorsGroup = ([ADSI]"WinNT://$env:COMPUTERNAME").psbase.children.find("Administrators")
$administratorsGroupMembers = $administratorsGroup.psbase.invoke("Members")
foreach ($administratorsGroupMember in $administratorsGroupMembers) {
$administrator = $administratorsGroupMember.GetType().InvokeMember('Name','GetProperty',$null,$administratorsGroupMember,$null)
if (($administrator -ne "Administrator") -and ($administrator -ne $currentUser)) {
$administratorsGroup.Remove("WinNT://$administrator")
Write-Host "Successfully removed $administrator from Administrators group"
}
}
foreach ($localAdministrator in $localAdministrators) {
$administratorsGroup.Add("WinNT://$localAdministrator")
Write-Host "Successfully added $localAdministrator to Administrators group"
}
Write-Host "Successfully remediated the local administrators"
}
catch {
$errorMessage = $_.Exception.Message
Write-Error $errorMessage
exit 1
}

Note: Just like last week I’m relying on ADSI for making the required adjustments.

Creating the script package

The second step is creating the script package. The script package can be created by using the proactive remediations functionality of Endpoint Analytics. That functionality can be used to schedule scripts to detect specific configurations and when that configuration is faulty, it can run scripts to remediate the configuration. The following six steps walk through the process of creating a script package, with a detection script and a remediation script. That will create a script package to detect the currently configured accounts from the Administrators and to remediate any faulty configuration that is detected. That script package can be scheduled to either perform the detection and remediation only once, or on a recurring schedule. The latter will make sure that it can actually be used for creating some baseline configurations, which might sound familiar when previously, or still, using Configuration Manager. The idea is the same, just a bit more simplistic and easier to use.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Reports Endpoint analytics (Preview) > Proactive remediations to open the Endpoint analytics (Preview) | Proactive remediations blade
  2. On the Endpoint analytics (Preview) | Proactive remediations blade, click Create script package to open the Create custom script wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the custom script package
  • Description: (Optional) Provide a valid description for the custom script package
  • Publisher: Provide a valid publisher for the custom script package
  • Version: [Greyed out]
  1. On the Settings page, provide the following information and click Next
  • Detection script file: Select the previously week created detection script
  • Detection script: [Greyed out]
  • Remediation script file: Select the created remediation script
  • Remediation script: [Greyed out]
  • Run this script using the logged-on credentials: No
  • Enforce script signature check: No
  • Run script in 64-bit PowerShell: No

Important: This configuration will run these scripts with bypassing the execution policy. Together with the information of my previous post, this could enable an administrative user to edit the script before running (and without the script being checked before running).

  1. On the Assignments page, provide the following information and click Next
  • Assign to: Select the assigned group and when selecting multiple groups, multiple lines will appear with all separate schedule configurations
  • Schedule: Click on the three dots to open the schedule configuration. This enables the administrator to configure a recurrence frequency for the script package. This can be Once, Daily, or Hourly.
    • When selecting Once, a specific date and time should be configured
    • When selecting Daily, a frequency and daily time should be configured
    • When selecting Hourly, a frequency should be configured
  1. On the Review + create page, verify the information and click Create

Verifying the results

When verifying the results, in Microsoft Intune, the first place to look is the proactive remediations overview. That provides an overview of all the different script packages that are deployed within the organization. That overview provides an easy first method to monitor the detection and remediation results of all the different deployed script packages. That overview is shown below and is available via Reports > Endpoint analytics > Proactive remediations.

When more details are required about a specific script package, the script package overview is the best place to look. That provides an overview that is specifically related to the status of a specific script package. That overview provides a clear bar chart for the status of the detection and remediation script of the script package. Besides that it also shows a nice daily remediation trend. That daily trend provides an overview of how often that specific situation is remediated. That overview is shown below and is available via Reports > Endpoint analytics > Proactive remediations > [Specific script package] > Overview.

When even more details are required about a specific script package on a specific device, the script package device status overview is the best place to look. That provides a clear overview about status details of a script package on the different devices. That overview includes standard information about the device and the last sync time, but also includes useful information that was part of the output of the detection script. That overview is shown below and is available via Reports > Endpoint analytics > Proactive remediations > [Specific script package] > Device status.

More information

For more information about Endpoint Analytics and Proactive Remediations, refer to the following docs

Detecting local administrators with proactive remediations

This week is all about proactive remediations, which is a feature of Endpoint Analytics. Proactive remediations are script packages that can detect common issues and remediate those issues if needed. All of that before the user even realizes that there is an issue. Those remediations can help with reducing support calls. The strength is that the remediations can be anything to address potential issues, as long as it can be addressed by using PowerShell. Each script package contains a detection script and a remediation script and that script package is deployed through Microsoft Intune. For deploying script packages, Microsoft Intune relies on the Intune Management Extension (IME).

To show the power of proactive remediations, I’ll use local administrators as an example. I’ve did something similar a long time ago for Configuration Manager and I still get many questions around that subject on my post about managing local administrators. Even in this modern world, local administrators are still a hot item. In this post I’ll focus on the detection part of proactive remediations and the remediation part itself might only be a week away. I’ll start this post by constructing the detection script, followed by creating the script package. I’ll end this post by verifying the results locally on the device.

Important prerequisites

Before actually starting with Endpoint Analytics it’s important to have the different prerequisites in place. That means the correct licenses and the correct configuration.

  • The device must be running Windows 10 Enterprise, Professional, or Education
  • The devices must be enrolled into Endpoint Analytics
  • The devices must be Azure AD joined or hybrid Azure AD joined and meet one of the following conditions:
    • the device is managed by Intune.
    • the device is co-managed device and running Windows 10, version 1903 or later.
    • the device is co-managed device and running on pre-1903 versions of Windows 10 with the Client apps workload pointed to Intune
  • The user must be licensed for Endpoint Analytics, which is included in Enterprise Mobility + Security E3 or higher and Microsoft 365 Enterprise E3 or higher, and when not using the latter, additional licensing of the following:
    • Windows 10 Enterprise E3 or E5
    • Windows 10 Education A3 or A5
    • Windows Virtual Desktop Access E3 or E5

Constructing the detection script

The first step is constructing the detection script. That script should detect the correct situation. In this example, the detection script should detect the correct number of local administrators and also the correct local administrator users. For a successful detection of the correct (number of) local administrators, the script should return an exit code of 0 and for a failed detection of the (number of) local administrators, the script should return an exit code of 1. That failure will eventually trigger the remediation script. More about that, next week. Besides that, it’s good to know that the last line of output, before the exit code, will also be displayed in the logs. That can be helpful when verifying and troubleshooting the detection script. The following example detection script will verify the number of local administrators and once the number matches, it will actually verify the local administrator users with the configured list of local administrators. Make sure to adjust that list with the correct local administrators and make sure to adjust the number of local administrators. The required adjustments are mentioned in the script example below.

#Define variables
$localAdministrators = @()
$memberCount = 0
$numberLocalAdministrators = 4 #Adjust to your number of administrators
try {
$currentUser = (Get-CimInstance Win32_ComputerSystem).Username -replace '.*\\'
$administratorsGroup = ([ADSI]"WinNT://$env:COMPUTERNAME").psbase.children.find("Administrators")
$administratorsGroupMembers= $administratorsGroup.psbase.invoke("Members")
foreach ($administrator in $administratorsGroupMembers) {
$localAdministrators += $administrator.GetType().InvokeMember('Name','GetProperty',$null,$administrator,$null)
}
if ($localAdministrators.Count -eq $numberLocalAdministrators) {
foreach($localAdministrator in $localAdministrators) {
switch ($localAdministrator) {
#Adjust to your local administrators
"Administrator" { $memberCount = $memberCount + 1; break; }
"$currentUser" { $memberCount = $memberCount + 1; break; }
"[YourGlobalAdminRoleSid]" { $memberCount = $memberCount + 1; break; }
"[YourDeviceAdminRoleSid]" { $memberCount = $memberCount + 1; break; }
default {
Write-Host "The found local administrators are no match"
exit 1
}
}
}
if ($memberCount -eq $numberLocalAdministrators) {
Write-Host "The found local administrators are a match"
exit 0
}
}
else {
Write-Host "The number of local administrators doesn't match"
exit 1
}
}
catch {
$errorMessage = $_.Exception.Message
Write-Error $errorMessage
exit 1
}

Note: Compared to my previous post, I prefer to use ADSI above WMI and Get-LocalGroupMember. WMI was often too slow and the mentioned cmdlet doesn’t really like SIDs yet.

Creating the script package

The second step is creating the script package. The script package can be created by using the relatively new functionality of Endpoint Analytics, which is proactive remediations. That functionality can be used to basically schedule scripts to detect specific configurations and, if needed, remediate the configuration. The following six steps walk through the process of creating a script package, with a focus on the detection script. That will create a script package to detect the local administrators. That script package can be scheduled to either perform the detection (and remediation) only once, or on a recurring schedule. The latter will make sure that it can actually be used for creating some baseline configurations, which might sound familiar when previously, or still, using Configuration Manager. The idea is the same, just a bit more simplistic and easier to use.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Reports Endpoint analytics (Preview) > Proactive remediations to open the Endpoint analytics (Preview) | Proactive remediations blade
  2. On the Endpoint analytics (Preview) | Proactive remediations blade, click Create script package to open the Create custom script wizard
  3. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the custom script package
  • Description: (Optional) Provide a valid description for the custom script package
  • Publisher: Provide a valid publisher for the custom script package
  • Version: [Greyed out]
  1. On the Settings page, provide the following information and click Next
  • Detection script file: Select the created detection script
  • Detection script: [Greyed out]
  • Remediation script file: (Optional) More about the remediation script file next week
  • Remediation script: (Optional) More about the remediation script next week
  • Run this script using the logged-on credentials: No
  • Enforce script signature check: No
  • Run script in 64-bit PowerShell: No
  1. On the Assignments page, provide the following information and click Next
  • Assign to: Select the assigned group and when selecting multiple groups, multiple lines will appear with all separate schedule configurations
  • Schedule: Click on the three dots to open the schedule configuration. This enables the administrator to configure a recurrence frequency for the script package. This can be Once, Daily, or Hourly.
    • When selecting Once, a specific date and time should be configured
    • When selecting Daily, a frequency and daily time should be configured
    • When selecting Hourly, a frequency should be configured
  1. On the Review + create page, verify the information and click Create

Verifying the results

For the detection of the local administrators, I’ll focus mainly on the information locally on the device. Next week, when adding the remediation, the focus will be on Microsoft Intune when looking at the results. As it’s the IME that is addressing the execution of the script packages, the information related to the execution is also logged in the IME related logfiles. The most interesting information can be found in the IntuneManagementExtension.log. That logfile contains the execution information of the script packages and every related line in the log has a prefix of [HS]. That prefix is referring to HealthScripts, which is shown in the different logs and file locations. When looking at the [HS] prefix throughout the log, it’s divided into the following two categories:

  1. Scheduler – Looking at the log, the Scheduler is responsible for requesting and scheduling the script packages. Below, in Figure 3, is an example of the Scheduler that is scheduling the script package for detecting local administrators. The highlighted sections show information about the user, the policy and the schedule. All of that information is referenced below in more logs, file locations and the registry.
  1. Runner – Looking at the log, the Runner is responsible for executing and reporting about the script packages. Below, in Figure 4, is an example of the Runner that is actually executing the scheduled policy for detecting local administrators. The highlighted sections show information about the user, the policy, the schedule, the result and the output. All that information is referenced above in the script, and below in the file location and the registry.

The script package is store locally in the HealthScripts folder in the IMECache folder. That folder contains a folder, as shown below in Figure 5, that corresponds with the policy that was highlighted in the IntuneManagementExtension.log. That folder contains a script named detect and a script named remediate and both of those scripts correspond to the scripts of the script package. When the script package is only used for detection, the remediate script will be empty.

In the end all of the most important information is stored in the registry, in the Scrips key in HKLM\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies. That key contains a key with information about the execution of the script package and that information is stored below a key of the user and the policy. That key contains the latest execution information and is shown below in Figure 6.

The Scripts key also contains a key with information about the result of the script package and that information is store below a key of the user and the policy. That key contains the result information that is reported and is shown in Figure 7.

The actual content of the Result value is shown below. That information contains the policy, the user, that status and the output. All the information that was referenced earlier in the script, log, file location and registry.

{ 
    "PolicyId":"176b61ca-59e6-4af1-b852-13a3102c5578",
    "UserId":"dedbba8f-f4f1-475c-a30b-895d87d77e9b",
    "PolicyHash":null,
    "Result":3,
    "ResultDetails":null,
    "InternalVersion":1,
    "ErrorCode":0,
    "ResultType":1,
    "PreRemediationDetectScriptOutput":"The found local administrators are a match",
    "PreRemediationDetectScriptError":null,
    "RemediationScriptErrorDetails":null,
    "PostRemediationDetectScriptOutput":null,
    "PostRemediationDetectScriptError":null,
    "RemediationStatus":4,
    "Info": {
        "RemediationExitCode":0,
        "FirstDetectExitCode":0,
        "LastDetectExitCode":0,
        "ErrorDetails":null
    }
}

More information

For more information about Endpoint Analytics and Proactive Remediations, refer to the following docs

Supporting the unsupported platforms

This week is all about supporting the unsupported platforms. More specifically, working with the limitations of the platforms that are unsupported by (parts of) the Microsoft 365 solution. Those platforms are Chrome OS and the different Linux distributions. Often those platforms are around in an organization during the introduction of a Microsoft 365 solution. In many components of the Microsoft 365 solution, those platforms are currently not supported. Think about Microsoft 365 Apps for Enterprise, Microsoft Intune, Conditional Access and so on. Basically nothing is really working and/or supported on those platforms at this moment. From that perspective Chrome OS is maybe even worse than the different Linux distributions. That doesn’t mean that there is no story at all. In this post, I want to start with an introduction to the actual challenge, followed by going through the most common options that are available to address that challenge. The scope for this post is limited to Microsoft 365 E3 license functionalities.

An introduction

When introducing a Microsoft 365 solution, the strength is the completeness of the solutions and the security and management capabilities that it brings. Especially the security of the solution goes as far as to were it’s a closed solution. For that, think about Conditional Access, the front door protection towards the company apps and data. Basically the first line to protect the access to the company apps and data. However, that’s also were the first challenge is that arises. Conditional Access, the protection at the front door, doesn’t support Chrome OS and the different Linux distributions. That means that it’s still possible to protect at our front door, but it’s not possible to take everything into account. It’s not possible to require anything of those platforms, besides multi-factor authentication (MFA) for the user using that platform. That’s not always sufficient. In the ideal world an organization wants to make sure that either the app, or device, that is used to access the company apps and data, is managed. However, that’s simply currently not supported for all platforms. That’s also were the second challenge arises, as Chrome OS and the different Linux distributions are not supported by Microsoft Intune. So, it wouldn’t even be possible to get those platforms managed. And I could go on in that chain, by looking at the Microsoft 365 apps for Enterprise (with the exception of Chrome OS devices that are capable of using Android apps) and all the other different components of the Microsoft 365 solution, but the result would be the same for Chrome OS and the different Linux distributions. Of course there are small exceptions, like the Microsoft Teams app and Microsoft Defender ATP for specific Linux distributions (in that case an E3-license is not sufficient), but those platforms are simply currently not a good fit in a Microsoft 365 solution. Especially when focusing on functionalities that are available within a Microsoft 365 E3 license.

The options

However, that doesn’t mean that there is completely no place for Chrome OS and the different Linux distributions in a Microsoft 365 solution. It will just not be the complete experience as on Windows, Android, macOS and iOS devices. Let’s have a look at the most common options that are available for those platforms, within the Microsoft 365 E3 license functionalities, and let’s go high-over through those options.

  1. Block access for unsupported platforms
  2. Provide access based on the location of the devices
  3. Provide limited access to SharePoint Online and Exchange Online
  4. Provide access via Windows Virtual Desktop
  5. Provide access via a Virtual Machine

Option 1 – Block access for unsupported platforms

When an organization has strict requirements regarding the management of the device and/or app that the user is using for accessing company apps and data (for example to limit the possibility of loosing data, or having company data on personal devices), the Chrome OS devices and the different Linux distributions can’t be part of the Microsoft 365 solution. In that case the best option might be to completely block access to company apps and data, by using Conditional Access. Even though Conditional Access doesn’t support those platforms, Conditional Access can be used to block those platforms. The idea is similar to what I’ve described here, which is to create a Conditional Access policy that will block access to all cloud apps and is assigned to all platforms with the exception of the platforms that the organization does want to allow. The main difference is that the UI changed a little bit over the last year.

This option will completely block access to company apps and data on Chrome OS devices and on the different Linux distributions (see Figure 1 for an example).

Option 2 – Provide access based on the location of the devices

When an organization has separately managed Chrome OS devices and/or different managed Linux distributions and can pinpoint those devices to a specific location, it can be an option to exclude those devices based on their location. The idea is similar to what I’ve described here, just the UI and experience changed over the years. This option could be an addition to the Conditional Access policy described in the first option. In this case there will be an exclusion for unsupported platforms coming from a specific location. The only thing that should be kept in mind is that it’s not possible to control which devices will actually be used by the user when accessing company apps and data on that specific location. We simply can’t differentiate between a separately managed Chrome OS device and a personal Chrome OS device from that specific location. That risk should be assessed.

This option will provide the user with full access to company apps and data on Chrome OS devices and on the different Linux distributions (see Figure 2 for an example).

Option 3 – Provide limited access to SharePoint Online and Exchange Online

When an organization is trying to find a balance between security and usability, it might be an option to allow a limited experience via the browser. That limited experience is only be available for Exchange Online and SharePoint Online and provides the user with the ability to at least perform some basic activities on company apps and data, without the major risk of loosing data or getting data on personal devices. This experience can be created across all platforms, whether those platforms are supported by the different Microsoft 365 components, or not. The idea is similar to what I’ve described here, and something similar is also applicable to Exchange Online. If needed the limited experience can be further limited to a true read only experience. In addition, it’s even possible to differentiate the behavior between SharePoint sites as explained here.

This option will provide the user with limited access to company apps and data on Chrome OS devices and on the different Linux distributions (see Figure 3 for an example).

Option 4 – Provide access via Windows Virtual Desktop

When an organization has strict requirements regarding the management of the device and/or app that the user is using for accessing company apps and data (for example to limit the possibility of loosing data), Windows Virtual Desktop (WVD) might also be an option on basically any platform. WVD is the exception when talking about cross-platform availability. The web client should work with any HTML5-capable browser and is officially supported on the default browsers of Chrome OS (Google Chrome) and the different Linux distributions (Mozilla Firefox). The good thing is that it’s possible to make sure that WVD is part of the Conditional Access policy, by either making sure WVD is hybrid Azure AD joined or by excluding WVD based on their location. Those are both valid options, when configured correctly, for making sure that it can be safely said that only WVD can access company apps and data. For basic account protection it’s still possible to use Conditional Access to require MFA on any platform that is used by the user for accessing WVD.

This option would provide the user with full access to company apps and data within WVD on Chrome OS devices and on the different Linux distributions (see Figure 4 for an example).

Option 5 – Provide access via a Virtual Machine

When an organization has many more advanced users, a last resort could also be to use a Virtual Machine (VM). That VM can exist on the host, can enroll into Microsoft Intune and can be compliant with the company policy. That would enable the user to access company apps and data, without the need for the administrator to create holes in the Conditional Access policy. The VM will be managed and secured in a similar way as any other physical device. This option is mainly applicable to the different Linux distributions.

My conclusion

Even though there are some unsupported platforms within most of the components of a Microsoft 365 solution, that doesn’t mean that an organization can’t use those platforms at all. I wouldn’t advise an organization to choose Chrome OS devices and/or different Linux distributions, when choosing for a Microsoft 365 solution, simply because of the currently limited support within a Microsoft 365 solution. However, when devices with those platforms are already within the organization, there are still options to somehow provide some support for those platforms. That’s the main point of this post. It’s just not a perfect story, yet.

Deploy Microsoft Defender Application Control policies without forcing a reboot

This week is all about Microsoft Defender Application Control (MDAC). More specifically, about configuring MDAC policies on Windows 10 devices by using Microsoft Intune without forcing a reboot. MDAC, often still referred to as Windows Defender Application Control (WDAC), restricts application usage by using a feature that was previously already known as configurable Code Integrity (CI) policies. To make the history lesson complete, configurable CI policies was one of the two main components of Windows Defender Device Guard (WDDG). History aside, CI policies help with protecting Windows 10 devices by checking apps based on the attributes of the code signing certificates and the app binaries, the reputation of the app, the identity of the process that initiated the installation (managed installer) and the path from which the app is launched. In this post I won’t focus on how MDAC technically works, but I want to focus on creating a custom MDAC policy and deploying that policy by using Microsoft Intune, without triggering a reboot. The same steps are actually applicable to deploying any custom MDAC policy by using Microsoft Intune. I’ll end this post by having a look at the end-user experience.

Create Code Integrity policy

The first action is to create a custom MDAC policy, which was formerly known as a Code Integrity policy. However, as a lot in the configuration is still referring to Code Integrity, or CI, I’ll keep referring to it in this post as a Code Integrity policy. Luckily, Windows already contains a few examples that can be used as the starting point (in a folder named CodeIntegrity). As this post is not focussed on constructing a custom Code Integrity policy, I’ll use DefaultWindows_Enforced.xml as my custom Code Integrity policy. That policy enforces the rules that are necessary to ensure that Windows, 3rd party hardware and software kernel drivers, and Windows Store apps will run and is also used as the basis for all Microsoft Endpoint Manager (MEM) policies.

PowerShell can be used to make all kinds of adjustments to a Code Integrity policy (the .xml policy file), by using the ConfigCI module. From that module the Set-RuleOption cmdlet can be used to modify the rule options in a Code Integrity policy. The configured rule options appear under the Rules property in the .xml policy file. Currently there are 19 different rule options that can be configured and those rule options are documented here. For this post the most important rule option, is rule option 16. That rule option can be used to allow future updates to the Code Integrity policy without requiring a system reboot. Below is an example of how to add rule option 16 to the Code Integrity policy. Using that same example with the -Delete parameter, will remove the no reboot information again.

Set-RuleOption -FilePath .\DefaultWindows_Enforced.xml -Option 16

Below in Figure 1, with number 2, is an example of the information that will be added to the .xml policy file, after adding rule option 16 to the Code Integrity policy.

Note: The detailed reader might notice that I’ve removed some default rule options in Figure 1 that are normally already configured by default. That is correct, because I wanted Figure 1 to focus on the specific settings of this post.

Transform Code Integrity policy

The second action is to transform the Code Integrity policy, so it can be distributed by using Microsoft Intune. To distribute the Code Integrity policy, it must be converted from a .xml policy file to .bin file. From the earlier mentioned PowerShell module, the ConverFrom-CIPolicy cmdlet can be used to convert a Code Integrity policy into a binary format. That binary version of the policy can be installed on Windows 10 devices and can be distributed via Microsoft Intune. Below is an example of how to convert the .xml policy file.

ConvertFrom-CIPolicy -XmlFilePath ".\DefaultWindows_Enforced.xml" -BinaryFilePath "DefaultWindows.bin"

Distribute Code Integrity policy

The third action is to distribute the Code Integrity policy, by using Microsoft Intune. To distribute the binary version of the Code Integrity policy, a custom device configuration profile can be used to achieve that. That requires the correct OMA-URI.

Construct OMA-URI

To distribute a custom Code Integrity policy, the ApplicationControl CSP can be used. This CSP was added with Windows 10, version 1903, and provides extended diagnostics capabilities, support for multiple policies and it supports rebootless policy deployment. The latter is the main difference with the AppLocker CSP. Unlike the AppLocker CSP, the ApplicationControl CSP detects the presence of no-reboot option. The following OMA-URI can be used ./Vendor/MSFT/ApplicationControl/Policies/{PolicyID}/Policy. In that OMA-URI, the PolicyID should actually be an existing value and not a self-generated value, like with most other policies that are configured. In this case the PolicyID should be the PolicyID of the Code Integrity policy. That PolicyID can be found in the .xml policy file, as shown in Figure 1, with number 1, and should be used without the curly brackets. For this example that means that the following OMA-URI can be used ./Vendor/MSFT/ApplicationControl/Policies/A244370E-44C9-4C06-B551-F6016E563076/Policy.

Create custom device configuration policy

To actually distribute a custom Code Integrity policy, Microsoft Intune can be used to configure the constructed OMA-URI on Windows 10 devices. The following nine steps walk through the process of creating a new custom device configuration profile that configures a single OMA-URI setting.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Windows > Configuration profiles to open the Windows | Configuration profiles blade
  2. On the Windows | Configuration profiles blade, click Create profile to open the Create a profile page
  3. On the Create a profile page, provide the following information and click Create to open the Custom wizard
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Basics page, provide the following information and click Next
  • Name: Provide a valid name for the custom device configuration profile
  • Description: (Optional) Provide a valid description for the custom device configuration profile
  1. On the Configuration settings page, click Add to open the Add Row page. On the Add Row page, provide the following information and click Add (and click Next back on the Configuration settings page)
  • Name: Provide a valid name for the OMA-URI setting
  • Description: (Optional) Provide a valid description for the OMA-URI setting
  • OMA-URI: ./Vendor/MSFT/ApplicationControl/Policies/A244370E-44C9-4C06-B551-F6016E563076/Policy
  • Data type: Select Base64 (file)
  • Value: Select the created binary file
  1. On the Scope tags page, configure the applicable scopes and click Next
  2. On the Assignments page, configure the assignment and click Next
  3. On the Applicability rules page, configure the applicability rules (think about the existence of this CSP for version 1903 and later) and click Next
  4. On the Review + create page, verify the configuration and click Create

End-user experience

Now let’s end this post by having a look at the end-user experience, once the Code Integrity policy is distributed and applied to the Windows 10 device of the user. The first thing that the user might notice is that the device doesn’t request a reboot. When the user now wants to start an application that doesn’t comply with the configured Code Integrity policy, the user will be prevented from starting the application. Figure 3 shows an example of a user that wants to start an application that was manually installed and the user receives a clear message that the app is blocked by Windows Defender Application Control.

More information

For more information about deploying WDAC policies, refer to the docs about deploying Windows Defender Application Control policies by using Microsoft Intune.

Android Enterprise and Microsoft Intune: And the previously missing use case

This week is all about an addition to my previous post about the device management jungle of Android Enterprise. In that post I already did a brief look at the future and what Android 11 would bring to the table. At that time Microsoft Intune did not yet support a deployment scenario to address the Corporate-Owned, Personally Enabled (COPE) use case. The good news is: that has changed! Microsoft Intune now contains the deployment scenario Corporate-Owned Work Profile, which is currently still in preview, and that deployment scenario can address the COPE use case.

With this blog I want to provide a refreshed overview of the different deployment scenarios and the use cases that are addressed. However, the main focus of this post is the new Corporate-Owned Work Profile deployment scenario. I’ll start this post with the refreshed overview of the different Android Enterprise deployment scenarios in Microsoft Intune, followed with a summery of the main characteristics of the different deployment scenarios. I’ll end this post by focusing on the implementation of the new Corporate-Owned Work Profile deployment scenario.

Updated overview of the Android Enterprise deployment scenarios

Let’s start with a brief overview of the different Android Enterprise deployment scenarios that are available within Microsoft Intune. I’ve discussed these deployment scenarios before, but I thought it would be good to provide another quick overview to clearly differentiate between the deployment scenario and the use case and to address the main characteristics of the different deployment scenarios. Below in Figure 1 is an overview of the different deployment scenarios. As it’s mainly focused on the Android Enterprise capabilities, I’ve skipped the MAM-only scenario. For a first filtering the deployment scenarios are sorted based on the owner of the device and based on the type of workers for the device.

The next step in providing a clearer overview is the table below. That table describes the main characteristics of the different deployment scenarios. It shows important characteristics like the main use cases of a deployment scenario, if personal use is possible, if the privacy can be guaranteed, the management reach and more familiar characteristics.

Deployment scenarioUse casePersonal usePrivacy guaranteedEnrollment methodManagement reachReset requiredUser affinity
Work ProfileBring Your Own Device (BYOD)YesYesCompany Portal appProfile ownerNoYes
Corporate-Owned Work ProfileCorporate-Owned, Personally Enabled (COPE)YesYesNear Field Communication, Token entry, QR code scanning, or Zero touchProfile owner with device-level settingsYesYes
Fully ManagedCorporate-Owned, Business Only (COBO)YesNoNear Field Communication, Token entry, QR code scanning, or Zero touchDevice ownerYesYes
DedicatedCorporate-Owned, Single Use (COSU)NoNoNear Field Communication, Token entry, QR code scanning, or Zero touchDevice ownerYesNo

As a little bit of context with this table, the different collumns are used to provide the following information:

  • Deployment scenario – This column describes the name of the deployment scenario (or some times referred to as management scenario) in Microsoft Intune
  • Use case – This column describes the often used name of the most common use case
  • Personal use – This column describes if the deployment scenario can facilitate personal use (which can be as simple as the option for enabling a personal account for the Google Play store)
  • Privacy guaranteed – This column describes if the deployment scenario can guarantee the privacy of the user (which actually can only be the case when using a work profile)
  • Enrollment method – This column describes the different enrollment methods that are available for the deployment scenario
  • Management reach – This column describes the management reach of the deployment scenario on the device
  • Reset required – This column describes if the deployment scenario requires a reset of the device
  • User affinity – This column describes if the the deployment scenario facilitates user affinity

Android Enterprise Corporate-Owned Work Profile

Now let’s have a look at the previously missing use case, which was the actual trigger of this post, the COPE use case. That use case can now be addressed with the introduction of the Corporate-Owned Work Profile deployment scenario. A long time the public feeling was that Microsoft was missing a use case in Microsoft Intune. Even though the feeling was fair and actually not just a feeling but a simple fact, there was also a fair reason why the deployment scenario for that use case was not available. Microsoft was relying on the Android Management API (AMAPI) and support for the required deployment scenario was not available. That’s changing now.

However, before looking at that deployment scenario in a bit more detail, let’s start with stating that the previous deployment scenario in Android Enterprise, to address the COPE use case, often named Work Profile on Fully Managed Device (WPoFMD), is not going to happen in Microsoft Intune. The support that’s provided via Microsoft Intune by leveraging AMAPI, is focused on the changes coming with Android 11. With Android 11, Google wants to focus more on the privacy of the user. To achieve that, Google wants to further separate the work profile and the personal profile. With the previous implementation there would be two separate Device Policy Controller (DPC) instances running on the device. An instance running as device owner in the personal profile of the user and an instance running as profile owner in the work profile of the user. As you can imagine, that theoretically provides an organization with a lot of control over the personal profile of the user. Besides the level of control, the organization could also potentially see information from the personal profile of the user, like the installed apps. That will also be one of the biggest changes in the new implementation. There will no longer be a work profile on a fully managed device. Instead, the new Corporate-Owned Work Profile deployment scenario will be similar to a normal work profile, but on steroids. Starting with Android 11, there will be a single DPC instance running as profile owner on the corporate owned device of the user. That instance also has the capabilities to do a few device settings. However, there will be no insights in for example the installed apps, or data, in the personal profile on the device. There will be strict separation between the apps and data in the personal profile and the work profile. Similar to the work profile deployment on personal devices. The main difference between the two are the steroids of the DPC instance. On a personal device, the DPC instance is running as profile owner and only has permissions within the work profile. On a corporate device, the DPC instance is also running as profile owner, it has permissions within the work profile and it can manage a few device settings that also affect the personal profile.

When looking from a Microsoft Intune perspective, the nice thing is that the user will have the same usage experience on devices with Android 8 and later, and that the administrators will also have the same management experience for devices with Android 8 and later. That’s achieved by using AMAPI. That will make sure that with a single configuration performed by the administrator, the correct configuration will be applied to the Android device of the user. No matter the specific Android version. As long as it’s Android 8 or later.

More information

For more information regarding Android Enterprise and Android 11, refer to the following articles:

Getting started with Endpoint Data Loss Prevention

Completely fresh after my vacation I thought it would be awesome to have a look at Endpoint Data Loss Prevention (DLP), which was announced during Microsoft Inspire. Endpoint DLP extends the activity monitoring and protection capabilities of DLP to sensitive content on Windows 10 devices. The best part of it is that the actual functionality is built-in to Windows 10 (and the Edge Chromium browser). No additional agent is required, just the onboarding of the device. In this post I want to start with a short introduction about Endpoint DLP, followed by the actions to onboard devices and to configure DLP policies and settings. I want to end this post by having a quick look at the end-user experience.

Introduction to Endpoint DLP

Let’s start with a quick introduction about Endpoint DLP. Endpoint DLP is an extension on the activity monitoring and protection capabilities that are provided by DLP, for sensitive content that is used on Windows 10 devices. That can be content that is directly edited in SharePoint Online, or OneDrive, but also content that is only locally available on the Windows 10 devices. So no dependency on the location of the data, but only on the data itself (and of course the device that it’s used on). Really awesome!

At this moment Endpoint DLP enables organizations to audit and manage activities of users on sensitive items. Activities like created, renamed, printed and more. For a complete list, refer to the documentation. Besides that, Endpoint DLP monitors the activity based on MIME type, which means that an extension change doesn’t stop content from be monitored. At this moment the list of supported file extensions is documented here.

To enable Endpoint DLP, make sure that the following is in place:

  1. The user must have a Microsoft 365 E5/A5 subscription or Microsoft 365 E5/A5 compliance or information protection and governance add-on
  2. The device must be running Windows 10 build 1809 or later
  3. The device must be Azure Active Directory (AAD) joined, or Hybrid Azure AD joined
  4. The Chromium Edge browser must be used on the device for the cloud activity actions

Onboard devices into device management

The first action that should be performed is onboarding the devices into device management. After onboarding the devices, the activities of those devices can be reviewed in features like activity explorer, or can be monitored by compliance solutions such as insider risk management and data loss prevention (DLP). To enable the onboarding, simply follow the next three steps.

  1. Open the Microsoft 365 compliance portal and navigate to Settings > Device onboarding (preview) > Devices and click on Turn on device onboarding
  1. On the Turn on device onboarding dialog box, review the message about devices already onboarded via Microsoft Defender ATP and click OK
  1. On the Device monitoring is being turned on dialog box, review the message and click OK

After successfully performing the previous steps, the devices that are already onboarded via Microsoft Defender ATP will start appearing in the devices list. When not already using Microsoft Defender ATP, devices can be onboarded by using the same process as for onboarding devices for Microsoft Defender ATP. When using Microsoft Intune that means following the next 10 steps.

  1. In the Microsoft 365 compliance portal, navigate to Settings > Device onboarding (preview) > Onboarding
  2. Select with Mobile Device Management / Microsoft Intune as the Deployment method and click Download package to download the onboarding package
  3. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices  > Configuration profiles > Create a profile to open the Create a profile blade
  4. On the Create a profile blade, provide the following information and click Create to open the Microsoft Defender ATP (Windows 10 Desktop) wizard
  • Platform: Windows 10 and later
  • Profile: Microsoft Defender ATP (Windows 10 Desktop)
  1. On the Basics page, provide a valid name for the profile and click Next
  2. On the Configuration settings page, provide the following information and click Next
  • Microsoft Defender ATP client configuration package type: Select Onboard and add the downloaded package of Step 2 (this is not necessary when a Microsoft Defender ATP connection is established with Microsoft Intune)
  • Sample sharing for all files: Not applicable
  • Expedite telemetry reporting frequency: Not applicable
  1. On the Scope tags page, click Next
  2. On the Assignments page, assign the onboarding configuration to the required group and click Next
  3. On the Applicability Rules page, click Next
  4. On the Review + create page, click Create to create the profile

Configure Endpoint DLP settings

Once the devices are onboarded, the next step is to have a look at the Endpoint DLP settings. These settings apply to all new and existing DLP policies that protect content on Windows devices and these settings are divided into the following three categories.

  • File path exclusions – This category can be used to configure file path exclusion to make sure that files in the specified locations won’t be monitored by the DLP policies.
  • Unallowed apps – This category can be used to configure specific apps that are prevented from accessing files that are protected by the DLP policies.
  • Browser and domain restrictions to sensitive data – This category is divided into the following two subcategories.
    • Unallowed browsers – This subcategory can be used to configure specific browsers that will be blocked from accessing files that are protected by DLP policies. The end-user will be prompted to use Edge Chromium.
    • Service domains – This subcategory can be used to configure specific service domains – from Edge Chromium – that are either allowed or blocked from uploading files that are protected by DLP policies.

To optionally configure these settings simply open the Microsoft 365 compliance portal and navigate to Policies > Data loss prevention > Endpoint DLP settings (preview).

Configure Endpoint DLP policy

Once the generic Endpoint DLP settings are configured, the next step is to have a look at configuring an Endpoint DLP policy. That’s actually just configuring a normal DLP policy with a new endpoint specific section. Let’s walk through those configurations by configuring a DLP policy that is based on the defaults of the GDPR template. To achieve that, simply follow the 11 steps below.

  1. Open the Microsoft 365 compliance portal and navigate to Policies > Data loss prevention > Policies and click Create policy (preview) to open the Create policy wizard
  2. On the Choose the information to protect page, select the General Data Protection Regulation (GDPR) template and click Next
  3. On the Name your DLP policy page, verify the information – if needed adjust the name – and click Next
  4. On the Locations to apply the policy page, make sure to at least select Devices (preview), make sure to include a (test) user and/or group and click Next
  1. On the Define policy settings page, select Review and customize default settings from the template and click Next
  2. On the Info to protect page, verify the default configuration and click Next
  3. On the Protection actions page, verify the default configuration and click Next
  4. On the Customize access and override settings page, perform the following actions and click Next
  • Verify the default configuration of the Restrict access or encrypt the content in Microsoft 365 locations section
  • Enable the configuration of the Audit or restrict activities on Windows devices section and configure the different activities to Audit, Block or Block with override
  1. On the Test or turn on the policy page, configure to test or to turn on or off the policy and click Next
  2. On the Review your settings page, verify the configuration and click Submit
  3. On the New policy created message page, select Done to close the wizard

End-user experience

Now let’s end this post by having a look at the end-user experience. Based on the usage of the GDPR template, I can show some nice examples of the user experience when working with personal information (like drivers license numbers). To show some examples of the behavior I’ve created a document, named Document5.docx, and that document contains a drivers license number. When I now want to copy content from that document, I receive a notification as shown below in Figure 6 and when I now want to print that document, I receive a notification as shown in Figure 7. Both notifications show the override option for the end-user, via the Allow button, as configured in the DLP policy (see Figure 5).

More information

For more information about Microsoft Endpoint DLP, refer to the documentation that starts here with Learn about Microsoft 365 Endpoint data loss prevention (preview).