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 🙂

How to disable SMBv1 with Intune [deep dive analysis]

I recently got motivated to research a bit about new MDM settings available in the latest Windows 10 Insider Build (17074) and how to configure them. Settings available in preview Windows 10 versions normally do not have a lot of technical documentation for it or there is even no documentation for a particular feature and corresponding setting at preview release time.

In this post I would like to show how to get the right pieces of information to configure an ADMX-backed policy setting in Windows 10 via Intune OMA-URIs with no technical documentation for it. We need to get all implementation details by our self. My goal is to show some of the inner workings how parts of the MDM policies are implemented and how we can get a deeper understanding of them.

I’ll demonstrate my analysis with some new Windows 10 latest Insider build settings (at time of writing build version 17074) derived from MSSecurityGuide to control SMBv1 on the device. The two settings are:

  • ConfigureSMBV1ClientDriver
  • ConfigureSMBV1Server

These settings control the SMB 1.0/CIFS File Sharing Support

Optional Feature SMBv1

 

How do we get to know this new available settings?

First we have a look at the registry. There is a new place where you can find MDM Policy CSP settings. Group Policy settings are stored in the Policies registry key and MDM Policy CSP settings can be found in the PolicyManager key here:

HKLM\SOFTWARE\Mircosoft\PolicyManager

As we see in the screenshot below there are two different sub keys. One current key and a default key.

Within the current key we find all settings configured for this device by Policy CSP via MDM like Intune. Within the default key we find all available settings for the particular Windows 10 release.

RegistryPolicyManagerDefault

As mentioned the latest Windows 10 version (at time of writing build version 17074) has a sub key for MSSecurityGuide with additional sub keys for ConfigureSMBV1ClientDriver and ConfigureSMBV1Server.

RegistryPolicyManagerSMBv1

If we have a look at the details, for example of ConfigureSMBV1ClientDriver we see the value name admxMetadataDevice. This gives us a hint that this particular policy is an ADMX-backed policy.

SMBv1ADMXHint

 

How do we configure it if we don’t know the input values for it?

The way Microsoft implemented the feature ADMX-backed policies is as follows:

A defined set of the default policies which come with the OS in the path C:\Windows\PolicyDefinitions are parsed at OS build time and stored in the MDM store as converted MDM policies. The second way is to ingest custom ADMX files after OS shipment which are then also parsed and stored in the MDM store as MDM policies. I wrote an ADMX file ingestion article for a custom OneDrive ADMX file here: Deep dive ADMX ingestion to configure SilentAccountConfig with OneDrive.

For a thorough understanding everyone should read the Background section of the Microsoft docs article Understanding ADMX-backed policies.

With all that in mind we need to find the original ADMX file for the policy and then we can derive the actual values for configuration because ADMX-backed policies are configured by a schema derived from the ADMX xml file structure.

Luckily I know that the MSSecurityGuide is provided by Microsoft through the Microsoft Security Compliance Toolkit 1.0 and within that package is the Windows 10 Version 1709 Security Baseline.zip. This includes the SecGuide.admx in the subfolder Templates.

SecGuideAdmx

Due to public knowledge how to configure ADMX-backed policies we can derive the configuration input values from the SecGuide.admx file. To derive the input values we need to study the article Understanding ADMX-backed policies especially the sections ADMX-backed policy examples and Sample SyncML for various ADMX elements.

To create the OMA-URI we append the registry key MSSecurityGuide and the sub key ConfigureSMBV1ClientDriver to ./Vendor/MSFT/Policy/Config/

./Vendor/MSFT/Policy/Config/MSSecurityGuide/ConfigureSMBV1ClientDriver

Now we need to follow the Sample SyncML for various ADMX elements for proper Enum usage as input value to disable the SMBv1 Client driver

  1. find enum
  2. get name from id attribute
  3. choose value for disable

SecGuideAdmxXml

construct the xml data element with derived values for id and value:

<data id="Pol_SecGuide_SMB1ClientDriver" value="4"/>

The result is the following custom OMA-URI setting:

Name: ConfigureSMBV1ClientDriver
OMA-URI: ./Vendor/MSFT/Policy/Config/MSSecurityGuide/ConfigureSMBV1ClientDriver
Data type: string 
Value:
<enabled/>
<data id="Pol_SecGuide_SMB1ClientDriver" value="4"/>

 

According to How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server the SMBv1 Server can be controlled by this registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry entry: SMB1 REG_DWORD: 0 = Disabled

To disable the SMBv1 Server we need to set the registry value SMB10 and this is the disabled value in the SecGuide.admx xml file.

SecGuideAdmxXml2

The result is the following custom OMA-URI setting:

Name: ConfigureSMBV1Server
OMA-URI: ./Vendor/MSFT/Policy/Config/MSSecurityGuide/ConfigureSMBV1Server
Data type: string 
Value: <disabled/>

Now we configure this as a custom OMA-URI in Intune and target it to our user group with Windows 10 Insider builds

SMBv1MDMOMAURI

 

How to verify if the settings are correctly deployed?

First of all we can generate a MDM Advanced Diagnostics Report:

Open Settings > Accounts > Access work or school > Connected to TenantName’s Azure AD > Info > scroll down to the bottom and click “Create report”

AdvancedDiagnosticsReport

open the Report MDMDiagReport.html it in Edge and look for:

MDMReport

Second we can check the registry for MDM applied settings:

SMBv1MDMSetting

Third we can verify the SMBv1 LanmanServer > Parameters > SMB1 = 0:

SMBv1ServerSetting

We can query the Windows feature if not enabled via PowerShell:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

SMBv1WindowsFeature

We can verify the SMBv1 Client and Server component via PowerShell:

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

SMBv1ServerConfig

sc.exe query MRXSMB10

SMBv1ClientConfig

Congratulations you successfully disabled the SMBv1 protocol as recommended in the Security Baseline for Windows 10!

Important note

SMBv1 is not installed by default in Windows 10 Fall Creators Update and Windows Server, version 1709
https://support.microsoft.com/en-us/help/4034314/smbv1-is-not-installed-windows-10-and-windows-server-version-1709

If a Windows 10 Version was upgraded from an earlier edition like RS2 to RS3, SMBv1 is not deactivated, the install state is migrated. SMBv1 will not be installed for fresh RS3 installations. The setting above would enforce uninstall of SMBv1 for migrated devices.

Further information

Configuring Windows Defender Credential Guard with Intune

The Windows Defender Credential Guard is a feature to protect NTLM, Kerberos and Sign-on credentials. Windows 10 Enterprise provides the capability to isolate certain Operating System (OS) pieces via so called virtualization-based security (VBS). NTLM and Kerberos credentials are normally stored in the Local Security Authority (LSA). Once VBS is enabled the LSASS process will be split into an isolated process (protected by virtualization based security)  called LSAiso and the LSASS process. The LSAiso process can not be accessed by other OS components than the LSASS. This approach protects credentials from malicious tools which gained system context access. A well known tool to accomplish extraction of credentials from LSASS in system context is Mimikatz. This will not work after enabling Windows Defender Credential Guard as the only process validated to gain access to LSAiso process is LSASS.

With that in mind Credential Guard can protect an attack vector used by a lot of bad guys trying to steal sensitive information. It’s really worth considering to turn this protection on for Windows 10 Enterprise x64 (no support for x86) devices.

CredentialGuardDesign

Further information of Credential Guard:
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-how-it-works

 

How do we configure this via Modern Management in Intune?

Since Windows 10 Version 1709 Microsoft provides Policy CSP support to configure Credential Guard via custom OMA-URIs. We can create a custom device profile:

CreateDeviceProfile

and then choose Profile type: custom

CredentialGuardDeviceProfile

Here we add the following OMA-URIs to configure Credential Guard with default settings and additional DMA Protection:

Name: DeviceGuard/EnableVirtualizationBasedSecurity
OMA-URI: ./Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity
Data type: integer
Value: 1 (enable virtualization based security)

Name: DeviceGuard/LsaCfgFlags
OMA-URI: ./Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags
Data type: integer
Value: 1 (Enabled with UEFI lock)

Name: DeviceGuard/RequirePlatformSecurityFeatures
OMA-URI: ./Vendor/MSFT/Policy/Config/DeviceGuard/RequirePlatformSecurityFeatures
Data type: integer
Value: 3 (Turns on VBS with Secure Boot and direct memory access (DMA). DMA requires hardware support.)

Further information regarding Policy CSP values:
https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-deviceguard

As a last step we assign the new device configuration profile to our user group we want to provide the additional Credential Guard protection.

 

How to verify successful configuration?

First of all we verify if Intune applied the configuration successfully:

CredentialGuardDeploymentStatus

Then you can verify the applied registry settings on the target device of the user:

CredentialGuardRegistrySettings

Further information regarding registry settings:
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-manage

Make sure the device was restarted after successful configuration! This is needed as Credential Guard relies on Hyper-V technology for virtualization-based security and therefore it will enable the feature Hyper-V Hypervisor component.

We can have a look for the LsaIso.exe process in task manager:

CredentialGuardProcess

Finally we open up msinfo32.exe and verify if virtualization-based security is running and Credential Guard is activated:

CredentialGuardMsinfo32

If everything went well your machine is now protected against stealing of password secrets (hashes) which can be used by attackers for Pass-The-Hash (PTH) attacks. Keep in mind that this will not protect against attacks like key loggers. The solution is an effective way to protect credential stealing from memory.

 

How to test this in a Hyper-V Virtual Machine?

When using Microsoft Hyper-V you can enable nested virtualization on the VM and enable the Trusted Platform Module. Now you can test Credential Guard in your Hyper-V VM.

Enabling nested virtualization on Hyper-V VM:

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

Further information on nested virtualization:
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Enabling the TPM on Hyper-V VM:

HyperVTPM

 

Additional things to consider?

The target hardware must support Credential Guard
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-requirements

Compatibility problems
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-considerations

Limitation in protection
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-protection-limits

 

UPDATE

Virtualization based security (VBS) will be available for non-Enterprise SKUs and starting with RS4+ VBS will be automatically enabled for clean installs!

 

If you are using Windows 10 please try Credential Guard in your environment as it is a really big security enhancement of Windows 10 Enterprise.