Enabling BitLocker on non-HSTI devices with Intune

BitLocker-DriveThis is a post about enabling BitLocker on non-HSTI devices with Windows 10 version 1809 and standard user permissions.

First of all a little background on HSTI. HSTI is a Hardware Security Testability Interface. It is an interface to report the results of security-related self-tests. Its purpose is to provide high assurance validation of proper security configuration.

The enhancement with Windows 10 version 1809 is that we are able to activate BitLocker with a MDM policy (Intune), even for non-HSTI devices and on Windows 10 Pro Edition. This was not working with Windows 10 version 1803 or lower and the community came up with custom solutions to handle this like custom PowerShell scripts deployed via Intune Management Extension. If we wanted to use Intune native MDM policies via the BitLocker CSP we needed HSTI compliant devices like the Surface devices or newer hardware devices which are mostly delivered as HSTI compliant devices now. To successful start the encryption as a standard user, a Windows 10 version 1803 was the minimum as the feature was introduced with this version.

The prerequisites for Intune BitLocker configuration are

  • Windows 10 version 1809
  • Microsoft Intune
  • non-HSTI device

Older devices can be protected by Intune BitLocker policy now?

Yes, as long as they are running Windows 10 version 1809. The most common problem is that we do not replace all devices in every Windows 10 project to have only latest HSTI compliant devices in the environment. We have to support older devices purchased maybe not long ago but not HSTI compliant. These devices can now be managed by an Intune device configuration policy to turn on BitLocker silently without administrative permissions as long as the device is a Windows 10 version 1809 device.

 

What do we need to do?

Currently at the time of writing we need two configuration policies. One endpoint protection profile and a custom profile.

The endpoint protection profile configures the silent BitLocker enforcement and other parameters like encryption strength. Go to Microsoft Intune > Device configuration – Profiles > yourpolicyname – Properties > Endpoint protection > Windows Encryption

Set Encrypt devices to Require
Set Warning for other disk encryption to Block

Sure you can set other parameters like encryption methods as well, but for a functional test this is enough.

These two settings make sure the encryption starts and it starts silently as we block the warning dialog for other disk encryption software.

Example shown below:

BitLockerIntuneEndpointProtection

The second profile is a custom profile (at time of writing it was not available in the UI) and it configures the ability to enforce the BitLocker encryption even when standard users are logging in. For example when the Windows 10 device is enrolled with an Autopilot profile where the user account type is set to standard user. AllowStandardUserEncryption is a new setting introduced with Windows 10 version 1809 BitLocker CSP and must be used in conjunction with the setting “Warning for other disk encryption set to Block” otherwise it is not functional!

The custom OMA-URI configuration must be configured like this:

OMA-URI: ./Vendor/MSFT/BitLocker/AllowStandardUserEncryption
Data type: integer
Value: 1

Example shown below:

BitLockerIntuneCustom

The two policies must be assigned to a user group or device group to test the new policies. To force the user type to a standard user after enrollment we need an Autopilot profile and assign it to our device.

AutopilotStandardUser

If we now enroll a new Windows 10 version 1809 non-HSTI device it must be encrypted silently and the recovery key must be backed up to Azure AD.

 

How can I easily verify this?

I used a Hyper-V VM Generation 2 with an enabled TPM module:

BitLockerHyperVVMTPM

To test if the VM is reporting as a non-HSTI compliant device I downloaded the Device Guard and Credential Guard hardware readiness tool and verified the HSTI status with the following PowerShell command:

.\DG_Readiness_Tool_v3.5.ps1 -Capable

The result is displayed like this:

HyperVVMHSTICheck

During my test I had to make sure that after the first restart, the Windows 10 version 1809 ISO is ejected, otherwise silent BitLocker encryption will fail. This is because the system does not have the normal start parameters during the BitLocker and TPM provisioning. The platform would take into account the additional media as the normal platform verification parameter. Which means after ejecting the ISO it would have prompted us for the recovery key. Microsoft takes care of this situation and does not start the BitLocker provisioning process at all. So, the generation of the platform default configuration parameters for later verification to unlock the TPM is prevented, as long as a removable media is inserted. See the failure event here:

BitLockerSilentEncryptionErrorIso

Without an ISO it will successfully starts the encryption and key backup to Azure AD. A success event is shown below:

BitLockerVMeventlog

The BitLocker state can be verified with the PowerShell command on the client:

Get-BitLockerVolume | fl

BitLockerVMPSStatus

In the Intune portal we can see the recovery key appended to the AAD device object:

BitLockerIntuneAADDeviceRK

 

Further information

What’s new in Windows 10, version 1809 for IT Pros
https://docs.microsoft.com/en-us/windows/whats-new/whats-new-windows-10-version-1809#bitlocker

Device Guard and Credential Guard hardware readiness tool
https://www.microsoft.com/en-us/download/details.aspx?id=53337

Hardware Security Testability Specification
https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/hardware-security-testability-specification

 

Go ahead and start encrypting all your Windows 10 devices to strengthen your security level 👍

Intune Managed Browser (MAM) with Azure AD Application Proxy and Conditional Access

Recently Microsoft enhanced the Intune Managed Browser experience with Mobile Application Management (MAM) and app-based Conditional Access (CA) a lot. It is integrated into the Conditional Access story as an approved app and supports the Azure AD Application Proxy very well now.

 

What does this allow us to do now?

We are now able to design a solution to publish our internal websites externally with minimal effort and then allow access to it from our mobile devices only by the Intune Managed Browser protected by Intune app protection policy. This ensures the information is safeguarded in our containerized Intune MAM solution. This gives most companies enough trust to actually do the publishing of internal resources for usage on mobile devices and support the bring your own device (BYOD) solution.

Please read the How does Application Proxy work? documentation from Microsoft to get a better understanding what we are going to do in the next section with the Azure AD Application Proxy. The Azure AD Application Proxy architecture is shown in the figure below:

ArchitectureAADAP

One of the nice things is it will not require us to open up any inbound firewall ports. As long as we are allowed to make outbound connections we can publish internal websites easily to external. The solution even supports various authentication scenarios inclusive Single Sign-On (SSO).

 

Here is a walkthrough of a demo setup to show it in action

The walkthrough of the demo scenario should get you a deeper understanding of the new possibility. Assuming we have some internal websites e.g. intranet and expenses and they are available in the internal network only. To simulate that, I have setup an IIS server hosting the two simple websites, intranet and expenses within a private network. They are reachable on the IIS server via http://localhost for intranet and http://localhost:81 for expenses. In addition I have a link from intranet pointing to expenses website (link target is: http://localhost:81, compare screenshot with html source code). I built the two demo sites to also demonstrate link translation with Azure AD Application Proxy later on.

AADAPIntranetSites

AADAPIntranetSitesHtml

 

How do we get the internal websites published now?

First of all we need to switch off the IE Enhanced Security Configuration on the Windows Server otherwise we are not able to complete the login prompt of the Azure AD Application Proxy during setup procedure. Then we are downloading the Azure AD Application Proxy on our demo IIS server and run the msi installer. It’s a very lightweight installer and the only thing we need to provide is the Global Administrator credential during setup to finish the process.

AzureADAppProxyDownload

The next step after installing the connector is to enable it by clicking Enable application proxy. After it is enabled the UI switches to “Disable application proxy” (shown in screenshot as step 3). Once enabled we have the Connector group default and our server listed there. It is possible to install more then one connector and build connector groups to support better reliability of the publishing (in fact this is recommended). The connector does not need to be installed on the IIS as I have done it in my demo setup, it should be on a dedicated Windows Server 2016 for example. I needed to run it on the IIS for simplicity of my setup and to use the internal address of http://localhost during publishing later on.

The official documentation for the Azure AD Application Proxy from Microsoft is found here https://docs.microsoft.com/en-us/azure/active-directory/active-directory-application-proxy-enable or you follow the link on the application proxy blade “Learn more about Application Proxy“.

With an up and running connector we can publish the websites now. It is the best to follow the detailed step-by-step guide from Microsoft https://docs.microsoft.com/en-us/azure/active-directory/application-proxy-publish-azure-portal and make both available. I published my both sites as an Enterprise Application as described and used no custom domain, but enabled link translation in the application body.

Published internal websites:

AzureADAppProxyPublishedWebsites

Details of the website intranet with internal URL http://localhost

AzureADAppProxyIntranet

Details of the website expenses with internal URL http://localhost:81

AzureADAppProxyExpenses

Now I can open up my published intranet from external and the intranet link originally pointing to http://localhost:81 was replaced by the application proxy because we enabled link translation on the application body (compare screenshot below). This works only if we publish both websites as the application proxy must find a published website for http://localhost:81 to do the translation.

AADAPIntranetSitesExternal

In a real world implementation I would recommend to use a custom domain for publishing to maintain your links. For example if we have mydomain.com as Active Directory (AD) and I publish via Azure AD Application Proxy with the custom domain mydomain.com I can reach the website internally and externally with the same URL. To set this up follow the instructions here:

Working with custom domains in Azure AD Application Proxy
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-application-proxy-custom-domains

 

Securing our Intune mobile apps with Intune application protection policies

Now we need to add a MAM policy – app protection policy to secure the Intune Managed Browser and Mobile Outlook. To do that we open Intune > Mobile apps > App protection policies > Add a policy

MAMPolicyAdd

After adding the policy we make sure Outlook and the Managed Browser is in the targeted apps and of course we adjust the individual Policy setting to meet our corporate standard and to realize the containerization (e.g. let apps only transfer data to other managed apps, encrypt data and so on…).

MAMPolicyTarget

For the policy setting we need to make sure the setting Restrict web content to display in the Managed Browser is set to Yes. This makes sure internal links in emails are opened in the Intune Managed Browser. Even better because of the Azure AD Application Proxy publishing we make sure that internal links get translated and opened successful in Intune Managed Browser. We will do that by assigning an additional app configuration policy in the next step.

MAMPolicySettings

As last configuration we assign the app protection policy to our AAD user group we want to target.

To configure the Intune Managed Browser to work hand in hand with the Azure AD Application Proxy and translate internal URLs to the published URLs we need to configure an app configuration policy for the managed browser.

AppConfigurationAppProxyRedirection

AppConfigurationAppProxyRedirectionTarget

Now the important piece of configuration is to configure:

Key: com.microsoft.intune.mam.managedbrowser.AppProxyRedirection
Value: true

The screenshot below does not display the complete string!

AppConfigurationAppProxyRedirectionSetting

Again as last configuration we assign the app configuration policy to our AAD user group we want to target.

 

Controlling access to the internal websites with app-based Conditional Access

Now we need to make sure our internal published website can only be accessed by Intune approved apps which are protected by app protection policy.

To do that we create the following Conditional Access policy in Intune or in the Azure AD portal. We assign our AAD user group, target All cloud apps, and include iOS and Android devices, and select Browser and Mobile apps desktop clients

CAMAMBrowserAndDesktopApps

As access control we grant access for approved client apps by choosing the option Require approved client app

CAMAMApprovedApps

 

How about the user experience?

Everything is in place and we assume someone in the company sent us an internal link to the new intranet site http://localhost. We open up mobile Outlook on iOS in this example:

OutlookIntranetMail

If we now click on the internal link, Outlook is configured to Restrict web content to display in the Managed Browser and will open the link in the Intune Managed Browser for us. The Intune Managed Browser is then instructed for AppProxyRedirection = true. This will redirect us to the external published URL instead of the internal URL as shown below and shows us the demo intranet site:

ManagedBrowserIntranet

Even the link within the demo intranet site is translated and will open the published demo expenses website:

ManagedBrowserExpenses

To make sure that the published intranet site is only accessible by the Intune Managed Browser we open up Safari and open the published intranet site by typing in the external URL and we will check if access if blocked:

SafariBlockInternalWebsite

As we see the access is blocked and we get a nice feedback to use the Intune Managed Browser instead and we can directly use the blue link button to open the Intune Managed Browser.

 

Summary

We have seen how to publish internal websites via Azure AD Application Proxy easily. Then we configured our mobile apps to use an Intune app protection policy and instructed the Intune Managed Browser to use Azure AD proxy redirection to translate internal links and open them successfully. We achieve protection of the published internal website to prevent data leakage.

 

Further information

The Intune Managed Browser now supports Azure AD SSO and Conditional Access!
https://cloudblogs.microsoft.com/enterprisemobility/2018/03/15/the-intune-managed-browser-now-supports-azure-ad-sso-and-conditional-access/

Better together: Intune and Azure Active Directory team up to improve user access
https://cloudblogs.microsoft.com/enterprisemobility/2017/07/06/better-together-intune-and-azure-active-directory-team-up-to-improve-user-access/

Manage Internet access using Managed Browser policies with Microsoft Intune
https://docs.microsoft.com/en-us/intune/app-configuration-managed-browser

How to create and assign app protection policies
https://docs.microsoft.com/en-us/intune/app-protection-policies

 

My advice to all, give it a try and start to play with MAM and app-based Conditional Access as it might be a quick win for your company and finally allow the usage of BYOD as company data can be protected very well in this scenario.

Happy publishing and protecting 🙂

Process automation for Intune and Azure AD with Azure Automation

IntuneAndAzureAutomationCloud managed environments benefit from the idea of software as a service, you don’t have to think about upgrading or maintenance of the infrastructure itself. But often we need to automate the tools itself. A very good example here is when an employee quits his job, than we need to trigger a lot of processes like disabling the account, retire of the device(s), wiping of the devices, sending some notes to various people and so on. Another example might be the cleanup of devices within Intune and Azure AD as they get stale over time and they are not used by users anymore.

 

Introduction

In the following blog post I like to show how to automate the process to delete old devices from Intune and Azure AD without the help of services from on-premises like servers running scheduled scripts. The established cloud workflow can be used by the service desk to quickly delete a device in both involved services Intune and AAD. After seeing a lot of environments where devices are being cleaned up in Intune and left in AAD, I thought its beneficial to show how to easily automate this with the Microsoft cloud solution Azure Automation. If the basics are built it’s just a matter of combining new tasks within a Runbook to build other workflows which are worthwhile in your environment.

I will show how to setup the Azure environment and create the first Runbook. A Runbook is the actual workflow which runs the PowerShell script. The Runbook will do an unattended authentication against the Inunte API via Microsoft Graph to manage Intune. We do not have a PowerShell module for Intune at the time of writing therefore we use the Intune API in Microsoft Graph. For the AAD operations we use the AzureAD module to perform the management tasks.

 

How to do unattended authentication with the Intune API?

The problem with the Intune API and Microsoft Graph is, that we can’t authenticate as an application as this is not supported at the time of writing. See section here Intune Device Management permissions > Application permissions: None.
https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference#intune-device-management-permissions.

We need to authenticate as an user (service account). This requires additional credentials and a secure storage of them to automate. Microsoft has a good guide how to set up an Azure application to support this scenario: How to use Azure AD to access the Intune APIs in Microsoft Graph. One aspect is that the Microsoft How-To guide will end up in a scenario which still prompts for credentials with a input form. This is because of the usage of:

AuthenticationContext.AcquireTokenAsync

For Azure Automation we need to change this behavior a bit to support credentials within our code:

AuthenticationContextIntegratedAuthExtensions.AcquireTokenAsync

We can use the How-To guide or the official GitHub Intune sample scripts which have the following lines of code:

$authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" -ArgumentList $authority
$platformParameters = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.PlatformParameters" -ArgumentList "Auto"
$userId = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.UserIdentifier" -ArgumentList ($User, "OptionalDisplayableId")
$authResult = $authContext.AcquireTokenAsync($resourceAppIdURI, $clientId, $redirectUri, $platformParameters, $userId).Result

they need to be changed to support our new AcquireTokenAsync call with support to specify UserPasswordCredentials as additional parameter:

$intuneAutomationCredential = Get-AutomationPSCredential -Name automation

$authContext = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext" -ArgumentList $authority
$platformParameters = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.PlatformParameters" -ArgumentList "Auto"
$userId = New-Object "Microsoft.IdentityModel.Clients.ActiveDirectory.UserIdentifier" -ArgumentList ($intuneAutomationCredential.Username, "OptionalDisplayableId")
$userCredentials = New-Object Microsoft.IdentityModel.Clients.ActiveDirectory.UserPasswordCredential -ArgumentList $intuneAutomationCredential.Username, $intuneAutomationCredential.Password
$authResult = [Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContextIntegratedAuthExtensions]::AcquireTokenAsync($authContext, $resourceAppIdURI, $intuneAutomationAppId, $userCredentials);

The credentials will be received from the Azure Automation account in PowerShell via Get-AutomationPSCredential. We will provision the service account credentials securely for the Azure Automation account via Credential assets.

 

Building the solution

The following steps must be followed to build the solution:

  1. Creation of a native application in Azure AD
  2. Assigning permissions to the registered application
  3. Grant permissions (administrator consent)
  4. Create Azure Automation Account
  5. Add Azure AD module to the Azure Automation Account
  6. Add credentials to the Azure Automation account
  7. Add variables to the Azure Automation account
  8. Add Runbook to the Azure Automation account
  9. Edit Runbook
  10. Start and test Runbook
  11. Add Automation Operator

 

1. Creation of a native application in Azure AD

The best description for a native application is found in the Intune documentation for the Intune API here: How to use Azure AD to access the Intune APIs in Microsoft Graph. I will outline the necessary steps to setup the environment.

New application registration

AddAppRegistration

fill out the details and give it a name, create a native application with redirect URI: urn:ietf:wg:oauth:2.0:oob

AppRegistration

in the end a new registered application is available. Important is to copy the application id as we need it in our PowerShell script Runbook later.

RegisteredApp

 

2. Assigning permissions to the registered application

The registered application must have AAD Read and Write permissions, and Intune Read and Write permissions.

RequiredPermissions

AddAPIAccess

AddApplicationPermissionAAD

ApplicationPermissionAAD

 

3. Grant permissions (administrator consent)

Finally we grant the selected permissions to the newly registered application.

GrantPermissions

ConfirmGrantPermissions

 

4. Create Azure Automation Account

Creation of the Azure Automation Account in a existing or new resource group.

AddAutomationAccount

AddAutomationAccountDetails

 

5. Add Azure AD module to the Azure Automation Account

To have access to AzuerAD module we add it via the Gallery, choose Browse Gallery

AzureAutomationAddModule

AzureAutomationBrowseGallery

 

6. Add credentials to the Azure Automation account

Go to Azure AD and create a new user, in my case user automation with Display Name Intune Automation and use a complex password for it.

IntuneAutomationUserRoles

At the moment we need to assign the Global Administrator role as we want to delete devices in Azure AD. This information is based on: https://docs.microsoft.com/en-us/azure/active-directory/device-management-azure-portal#delete-an-azure-ad-device

After user creation we add the credential to the Azure Automation account.

AddAzureAutomationCredential

AzureAutomationCredential

 

7. Add variables to the Azure Automation account

The following PowerShell needs the native registered application ID also called Client ID. Therefore we create a Azure Automation variable IntuneClientId and we need the tenant ID as a variable, we use Tenant as identifier.

AddAzureAutomationVariable

Below an example for IntuneClientId and add your Application ID from above, do the same for Tenant variable and add your tenant ID.

AddAzureAutomationVariableClientId

 

8. Add Runbook to the Azure Automation account

Adding a Runbook with the name Invoke-RetireDevice

AzureAutomationAddRunbook

AzureAutomationAddRunbookDetail

 

9. Edit Runbook

We verify if the Runbook sees all our important information like AzureAD module, Variables and Credentials. After adding the PowerShell script we need to publish it.

EditRunbookDetail

PowerShell script for the Runbook is based on the GitHub samples with the modification to allow non-interactive usage of credentials via Get-AutomationPSCredential and Get-AutomationVariable

$intuneAutomationCredential = Get-AutomationPSCredential -Name automation
$intuneAutomationAppId = Get-AutomationVariable -Name IntuneClientId
$tenant = Get-AutomationVariable -Name Tenant

Now follows the actual PowerShell script with the logic to get the device of the user and delete it form Intune with usage of the automation credentials and variables for client id and tenant. In the end it will use the same credentials to delete the device from AAD also.

 

10. Start and test Runbook

Everything is setup, now it’s time for the first run. Get a stale Intune device you like to retire and start the Runbook.

StartRunbook

The Runbook has two input parameters DeviceName and UserPrincipalName. This is needed to avoid getting duplicate entries for DeviceName. A user should only have a device once. If not we might rethink the PowerShell logic to address this.

StartRunbookDetail

After start of the job we can click on Output

StartRunbook-Output

and get details as defined in our PowerShell script. If everything runs fine you will get the following output:

StartRunbook-OutputDetail

 

11. Add Automation Operator

We add a different user (e.g. service desk operator) to our Runbook as an Automation Operator. This provides the user the possibility to log on to portal.azure.com and start the Runbook but it’s protected from modifications as shown below.

AzureAutomationAccessControl

AzureAutomationAccessControlDetail

AzureAutomationOperatorPermission

 

Recap what we achieved

We have setup Azure Automation to host our PowerShell script in a managed cloud environment which is able to run as job to delete an Intune device and AAD device. In addition we learned the basics of Azure Automation and how to add modules, work with credentials and variables. Usage of unattended authentication to the Intune API is the basis for Intune API usage in Azure Automation.

 

Enhancements

  1. Microsoft Flow
  2. Source Control

Microsoft Flow

I thought it would be nice to enhance the Runbook with a Microsoft Flow to trigger it from my mobile phone. I found the following article which is describing how to do that:

Azure Automation new Microsoft Flow Service
https://blogs.technet.microsoft.com/stefan_stranger/2017/03/30/azure-automation-new-microsoft-flow-service/

Unfortunately as soon as I tried to use it I found that Microsoft Flow does not provide any trigger at the moment for it. The manual trigger as shown in the blog post above is not available for me. Maybe we can provide a nice interface for the runbook in the future via Microsoft Flow.

Microsoft Flow – Azure Automation
https://flow.microsoft.com/en-us/connectors/shared_azureautomation/azure-automation/

Source Control

When working with code it’s important to have a good versioning and a code storage place. For this Azure Automation provides integration with GitHub to link your Runbook source code. How to setup this follow the guide below. I can really recommend it.

Source control integration in Azure Automation
https://docs.microsoft.com/en-us/azure/automation/automation-source-control-integration

 

Further information

Azure Automation User Documentation
https://docs.microsoft.com/en-us/azure/automation/

How to use Azure AD to access the Intune APIs in Microsoft Graph
https://docs.microsoft.com/en-us/intune/intune-graph-apis

Credential assets in Azure Automation
https://docs.microsoft.com/en-us/azure/automation/automation-credentials

Intune Device Management permissions
https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference#intune-device-management-permissions

Graph Explorer – Microsoft Graph
https://developer.microsoft.com/en-us/graph/graph-explorer

Another very good guide using Azure Automation with Intune and AAD is here:
Unattended authentication against the Microsoft Graph API from PowerShell
http://www.powershell.no/azure,graph,api/2017/10/30/unattended-ms-graph-api-authentication.html

You want to learn more about Intune Housekeeping with scheduled Azure Automation PowerShell scripts then visit Ronny’s blog:
https://ronnydejong.com/2018/04/11/keep-your-microsoft-intune-tenant-clean-and-tidy-w-azure-automation-graph-api

 

Have fun in automation. Feel free to post your process automation ideas in the comment area below! Thanks for reading!