Over the last two blog posts, we went over some of the pre-requisites and configuration required to setup Microsoft Tunnel. In this post, we will show the solution in action.

The sequence of events will be as follows

• Launch of iOS App that is tied to the MS Tunnel VPN (Once it’s launched you will see the VPN icon show up on the top right side of the phone.)
• MS Tunnel established in the background
• Using iOS app to access resources on the corporate network or in my case, home network.
• Microsoft Tunnel is a separate app which is used as the interface to prompt for modern authentication. You will have to occasionally re-authenticate based on conditional access policies, timeout settings, etc.

In Part 1, we looked at some of the pre-requisites and installation of the Microsoft Tunnel. In this post, we will look at the Intune side. In part 3, we will go over the solution in action as well as ways to troubleshoot any issues.

Intune Server and Site Configuration

On the Intune side, you have to create a Server Configuration and Site Configuration.

Server Configuration - Defines DNS servers, split tunneling and server port information.

• IP Address Range - Defines the ip addresses reserved for clients when connecting to MS Tunnel VPN
• DNS Servers - Defines DNS servers to be used when connected to MS Tunnel VPN
• Split Tunneling - Defines subnets where the client will route traffic through MS Tunnel VPN
• Server Port - Defines port to connect to the server

• Public IP address or FQDN - Defines the public ip address or DNS name of the server.
• Server Configuration - Select a previously defined server configuration.

Site Configuration - Defines the public IP address as well as server configuration.

Server Configuration - Is where you go to download the installer script. Once the script is run, this section will highlight the servers that are configured.

The file is a bash script that runs a function to configure the server.

Run the tunnel setup

Before the setup can be run, the PFX file needs to be copied to MStunnel directory

1
2

wget https://aka.ms/microsofttunneldownload -O mstunnel-setup
sudo ./mstunnel-setup

Intune Client Configuration

Also on the Intune side, two configuration profiles were created to deploy the root and trusted CA certs to the mobile device.

A VPN profile was deployed as well with the Microsoft tunnel. The connection type was set to Microsoft Tunnel.

Lastly, the per-app VPN needs to be associated at the app deployment level. In my case, the app I wanted the on-demand VPN for was configured to use my MSTunnel configuration policy.

The Microsoft Tunnel App also needs to be deployed to the clients as well. This app is used to connect to the VPN and also to enforce conditional acccess rules (2FA for example). In the next and last part of this blog, we will go over the solution end to end.

#Troubleshooting
Initially when I had the solution installed and configured, I could never get the tunnel to connect because my certificate request did not contain the DNS name in the CN field. Instead, I accidentally placed it as an alternate name in the certificate. To troubleshoot this the following commands can be run diagnose any issues as well as keep an eye on the tunnel backend.

1
2
3

journalctl -t mstunnel_monitor -f
journalctl -t mstunnel-agent -f
journalctl -t ocserv -f

Microsoft Tunnel is a VPN solution provided by Microsoft that provides connectivity back to the datacenter or on-premises network from mobile devices. All of these features are deployed via Microsoft Intune (MDM).

This feature has always existed with Intune. VPN profiles can be configured in Intune which enables Always-On or per-app VPN connectivity with your firewall of choice. Microsoft Tunnel however makes it easier to configure and deploy a VPN solution as it does not depend on major changes to a companys networking/firewall/vpn solution. Customers moving from away from MobileIron and AirWatch have asked for this type of solution where they can open their mobile app and establish connectivity back home but it’s always been a challenge to get it working with enterprise network appliances.

The Microsoft solution is implemented on a Linux machine utilizing container technology. Looking under the covers, Microsoft is leveraging OpenVPN technology for the implementation. The approach is a bit confusing since Microsoft also has Always-On-VPN option using Windows Server which it touts as the modern way to use VPN and is compatible with conditional access policies.

As part of this blog post, I’ll explore the installation, configuration and troubleshooting steps. The problem that I’m trying to solve is to have my phone automatically connect to VPN when accessing my video camera application. This way, I don’t have to manually connect to VPN and access my cameras when I am outside of my home network.

To get started, run the install using the MS provided script. The only prequisite that I had to install was the following:
Install Docker CE

Since I didn’t want to pay for any certificates, I decided to use my internal Windows Certificate Authority.

On the Intune side, you willl have to create a server, site & server configuration. This will be covered in part two of the post

Create the CSR on the Server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

openssl req -new -sha256 -nodes -days 1095 -out \site.csr -newkey rsa:2048 -keyout \site.key -config <(

cat <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C=US
L=Texas
CN = mstunnel.jenujose.com
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
IP.1 = 99.76.16.241
EOF
)

Generate a Certificate from the issuing CA

This was a tricky one and had to do a bit of googling to remember the commands to issue a certiicate via certutil.

1
2
3

certutil -submit -attrib "CertificateTemplate:SSLWebServer"

**Note that the name of the certificate template needs to be typed in without any spaces. Client AUthentication key is what you will need for this to work.

Import the Cert into Linux box alongside bundle of certs

Since I have a two tier certificate authority, I had to bundle up the certificates into a CER file first.

1
2
3
4
5
6
7
8

cat rootcab.cer intermediatecab.cer > bundle1.cer

sudo openssl pkcs12 -export -out site.pfx -inkey site.key -in site.cer -certfile bundle1.cer

-out switch is the certificate bundle supported by MSTunnel.
-inkey switch is the private key that was generated when the  CSR was generatd
-in key.cer - Certificate
-certfile - Root & Intermediate CA

Copy cert to MStunnel directory

Before the setup can be run, the PFX file needs to be copied to MStunnel directory

1

sudo cp site.pfx /etc/mstunnel/private/site.pfx

In the next part of the blog post, I will go over the setup on the Intune side to be able to deploy the solution to mobile devices.

There’s not a good way to report on results of a report-only conditional access rule. As of writing this post, you have to look at the result of the rule by digging into each user which can be tedious.

There is a better way to report and it’s through Log Analytics via Kusto Query Language (KQL).

First, you will need to send your Azure AD data to Log Analytics. This requires setting up Azure AD Insights and sendings Azure AD sign in logs to Log Analytics.

After that, run the following KQL query to get a list of all singins that would be affected by the report-only conditional access policy. In this instance, we are looking for all sign-ins where the report-only conditional access was succesfullly applied.

1
2
3
4
5
6

SigninLogs
| project ConditionalAccessPolicies, UserDisplayName, AppDisplayName
| where ConditionalAccessPolicies != "[]"
| mv-expand ConditionalAccessPolicies
| extend result = ConditionalAccessPolicies["result"], CAName = ConditionalAccessPolicies["displayName"]| project-away ConditionalAccessPolicies
| where result ==  "reportOnlySuccess"

1. Do not turn on Multi-Factor Authentication from the legacy MFA console on a per-user basis. Use Conditional access to enforce MFA.
   • If you have both options turned on, then legacy MFA wins and will enforce the user for MFA every single time and irrespective of the conditions in your conditional access policies.
   • Legacy MFA uses App-Passwords which are a terrible user experience for users. This applies to client that don’t support Modern Authentication. They will have to append an app password to their password to login. Instead, consider blocking clients that don’t support MFA.
2. MFA will only work with conditional access if the client application supports Modern Authentication (ADAL Library).
   • That’s right, conditional access policies will not work if the client doesn’t support modern authentication. You can find out what clients are connecting to your organization using Azure AD sign-in logs.
3. MFA will not be prompted every time use logs in to a service. Azure AD Authentication uses Access Tokens and Refresh tokens to grant access to a service. The access token is valid for an hour at which point the refresh token is used to request another access token (refresh tokens have a longer lifetime than the access tokens). This cycle can continue up to 90 days. Keep in mind conditional access policies are evaluated everytime the service gives you a new access token. These default settings for token lifetimes are Microsoft’s recommendation as they have found no correlation between longer refresh token lifetime and account compromise.
4. Use Sign-Ins log in Azure Active Directory to troubleshoot issues/understand if/how MFA requirement was met.
   • Admins will bring up the fact that MFA is not prompted for users however by looking at the logs you will notice MFA did apply. However, other device claims satisfied the MFA requirement. In other words, it wasn’t a visible “MFA” prompt that the user experienced, however combination of other trust factors such as device compliance, hybrid-Azure AD joined status helped satisfy the MFA requirements.
5. “Hybrid Azure AD Joined” and “Device is Compliant” should be used with caution. Domain Joined devices need to be synced and registered with Azure AD before it can understand that it’s a domain joined device. There are some steps that need to be configured before this works. Device is compliant means that it’s an Intune joined device meeting compliance policies.
6. Block legacy authentication after MFA is deployed so that clients that do not support MFA are not allowed to connect to the organization.
7. Create breakglass accounts just in case you lock yourself out or Microsoft’s MFA service goes down. These accounts should be exempt from MFA and other conditional access policies.

You might see the dreadful error message when trying to open a Shared mailbox mapped to a user.

Usually it’s a case of incorrect permissions being applied. The weird thing was that the user had no problems accessing the shared mailbox via OWA.

Further looking into the mailbox, I found that MAPI was not enabled. When I tried to enable MAPI from the GUI, it would not make the change.

As a result, I moved onto enabling the change via Powershell which led me to the true error.

So although the user had no license (since it was a shared mailbox) it was showing it had the K1 license…which of course does not allow you access to Outlook. Essentially at one point, the mailbox licensed for K1 and although we removed that license, it never updated the properties on the Exchange side and this is why we couldn’t enable MAPI.

To resolve the issue, I went ahead and temporarily gave it an E3 license and then I had to wait around 30 minutes for that to take effect and then converted it to a shared mailbox.

During a recent EMS POC engagement, my customer asked if there was a way to bypass multi-factor authentication for mobile devices that were registered with Intune/managed by the company. In addition they wanted to be able to get device claims from Windows 10 devices as well so they can determine if the device was being managed by SCCM.

This seems like a pretty reasonable and simple ask until you actually realize the solution entails multiple components to get it properly working.

After some research, I realized I needed ADFS, Azure AD Connect, Azure Device Registration (For Windows devices) and Intune to get this working.

Now for some background..

• Azure Device Registration – As part of Intune enrollment devices are registered to Azure AD using the ADRS service. This allows a record for the device to be created which contains information about the device. ADRS also supports the registration of domain joined computers as well. We’ll be be using this service to register Windows 10 domain joined computers so that Azure AD knows about them.
• ADFS – Since ADFS is where the authentication for the user happens, we can get information about the device and the user. What we are interested in are device claims which give us more information about the device that’s being authenticated.
• Azure AD Connect – Azure AD Connect is a tool used to synchronized your Active Directory to the cloud. It also allows provides a very important feature called Device Write-back. This essentially brings down the objects that are registered to Azure AD to Active Directory so ADFS knows about them.

Azure Device Registration/Azure AD Connect

So how does devices get to Azure AD?

• Well, mobile devices are easy because part of the Intune enrollment process involved the registration of the device to Azure AD.
• Now what about Windows devices (7,8,10)? It turns out there’s a mechanism called Azure Device Registration for Windows domain joined devices. For Windows 8.0 and above, this process is built into the operating system and the feature that’s used is “WorkPlace Join”.

I won’t go into the details of setting this up but it’s outlined here in the following articles:

https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-devices-group-policy/

Jairo Cadena has the best article that I can find just in case you are interested in how the device registration works:

https://jairocadena.com/2016/01/18/how-domain-join-is-different-in-windows-10-with-azure-ad/

Device registration will work for BOTH customers that are federated (e.g using ADFS) or that’s just doing password synchronization. The caveat is that the computer object needs to be included in the scope of devices that you are syncing using Azure AD Connect or equivalent. **Update: Windows 7 Azure AD Registration will ONLY work with ADFS

Azure AD Connect is involved because there’s an option in the tool for device write-back. Since Azure AD registers mobile or Windows devices that are not part of the domain, there needs to be a mechanism that brings down the devices from Azure to Active Directory so that ADFS knows about these devices.

The command above will do the following:

1. Assigns the correct permissions for the Azure AD Connect tool to write back the devices in Azure to AD. In Active Directory, you will notice a “RegisteredDevices” OU in Active Directory.

In addition, for domain joined Windows 10 computers the following powershell command needs to be run as well after the Azure Active Directory installation is complete.

When you run this script the following happens:

1. Create an SCP (Service Connection Point)  record in Active Directory that allows Windows devices to know which Azure AD tenant to connect for the device registration to take place.

ADFS Configuration

On the ADFS front, for device registration to work quickly (instantly) you’ll have to configure ADFS so that necessary claims are passed to Azure AD for authentication. You can find more details by following the article I mentioned in the Azure Device Registration section.

More importantly, you will need to enable device authentication. With ADFS 2012, the setting is configured by checking the box below. Device authentication will help yield the device claims we are looking for.

With ADFS 2016, the configuration is moved to a different area and the process in setting this up is much simpler. Device authentication is also associated with device registration. This removes the need to run powershell commands to initialize device registration with ADFS 2012.

Client Testing

So after you get this setup Windows 10 devices that have the anniversary version will automatically register with Azure AD. For older versions of Windows 10, you will need to enable “WorkPlace Join” via group policy.

Windows 8/8.1 also need to have the “WorkPlace Join” GPO enabled.

Windows 7 clients do not have the capability natively however you can install this capability using the following tool:

https://connect.microsoft.com/site1164/program8374

For testing purposes, I setup a sample application that displays all claims. The sample application can be found in the Windows Identity Foundation framework and can be downloaded and setup using this article:

https://blogs.technet.microsoft.com/tangent_thoughts/2015/02/20/install-and-configure-a-simple-net-4-5-sample-federated-application-samapp/

Caveats: I spend countless of hours troubleshooting device authentication with Windows 10 and although there’s no article that says this but from testing it does not seem device claims is supported with ADFS 2012. In a ADFS 2016 environment, I was able to get device claims the way I expected.

Here are the results from a Windows 10 (Anniversary Update) machine logging into the sample claims aware applications:

Now we have information about the device itself such as “IsManaged”, “WorkPlace”, we can use these claims to make authentication decisions.

In terms of the device registration of the particular client in Azure AD, you will find the following:

Example of a Windows 10 device that’s domain joined:

Example of Intune joined device:

Now that we have all this information, we can use ADFS to ensure that domain joined devices and managed devices bypass multi-factor authentication

Making it Work

With ADFS 2016, we can do this with Access Control Policies. This is a simplified way of creating issuance rules without the need for the claims language.

For my Office 365 tenant, I’m going to create the following Access Control policy and then apply the policy to my Office 365 relying party trust.

So essentially any user that logs into Office 365 will get a multi-factor authentication prompt except for devices with the claim “Device Trust Level” being “Managed”.  In my next post, I’ll deep dive into some of the device claims available and what the different values mean.

Now you can take this a step further and use these device claims to enforce conditional access. For example, you can prevent non-managed devices from accessing company resources either in the cloud or on-premise!

ADFS 2016 changes the way Multi-Factor Authentication (MFA) is  configured and used. With previous versions of ADFS, MFA Server was downloaded and the ADFS adapter installed to provide MFA for users and applications. With Windows Server 2016, the architecture has changed so that ADFS 2016 is integrated with Azure MFA. This means that the IT admin does not need to install any special software or adapter to get MFA working. In addition, MFA now can be used as a primary method of authentication—users don’t need to enter in their password to get access to resources, they can verify their identity using their phone (call, text) or by using the Microsoft Authenticator app.

Before ADFS 2016 MFA can be used, MFA servers need to be registered on your Azure AD tenant: This following needs to be done for each ADFS server in the farm. There is good documentation on how to get this done here: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa

Background

In my lab environment, I installed ADFS 2016 and used the Export and Import scripts available in the Windows Server 2016 media to move over the settings from my 2012 R2 server. The scripts are located in the Support\ADFS folder of the OS media. The biggest key to making this work is to make sure you use the same service account.

FYI:You can easily add ADFS 2016 server into an existing 2012 farm seamlessly but I did not choose to go that route.

Configuration

A certificate needs to be generated on the ADFS server which will be used for authentication against Azure AD.

After a certificate is generated, a new service principal needs to created and the certificate information associated with the service principal. This allows the ADFS servers to authenticate/communicate with the Azure MFA client successfully.

When executing the command to create the service principal ID, you are met with an error saying the end date is an invalid parameter. This seems to be a bug and I was able to get around this by omitting the start and end date altogether.

Now that I have MFA service registered with Azure AD, I can go ahead and enable MFA as an authentication method.  MFA can be used  the primary method of authentication or secondary. Using MFA as a primary method of authentication is great news—this means you don’t have to use your password when logging on to company resources

For my test environment, I’ve setup ADFS with the following configuration:

One of the prerequisites to get Azure MFA to work on-premise is that the “proof-up” or the setup of MFA information needs to happen in Azure AD. This means that multi-factor authentication needs to be enabled for the user. I’ve raised this issue with MS because essentially to use ADFS based Azure MFA you need to turn on Azure AD MFA (more on this later)

Since we’ve enabled both ADFS based Azure MFA and Azure AD MFA, we need a way to prevent double  double MFA prompts (one from Azure and one from ADFS). You will need to change your domain federation settings to the following:

Set-MsolDomainFederationSettings –DomainName domainname.com -SupportsMFA $false

In addition, you will need to pass the MFA claim from ADFS to Azure AD so it will understand that you have already successfully authenticated via MFA on-premises. This should be added to the Office 365 Relying Party Trust (which is service I’m testing against)

(=> issue(Type = “http://schemas.microsoft.com/claims/authnmethodsreferences“, Value = “http://schemas.microsoft.com/claims/multipleauthn“);)

**After raising the proof-up question with MS they recommended to use the following for these scenarios:

1) Authenticating to Internal Applications – Internal applications will be able to leverage ADFS based Azure MFA for authentication. This assumes that the user has setup alternate authentication methods in Azure AD. You can send the user the link to set up MFA methods or if they use Office 365 or Microsoft cloud services, they will be forced to go through this setup.

2) Authenticating to Azure AD Applications – For Azure AD applications, Azure AD MFA will provide authentication. This is of course assuming Azure MFA is turned on for the user.

From testing, I was able to use ADFS based MFA for both scenarios and get it to work.  It worked because I went through the initial proof-up setup (Turning on MFA in Azure AD or Setting up alternate authentication methods by going to myapps.microsoft.com)

User Experience

When a user logs in for the first time to Office 365, they will be met with a prompt to setup MFA (I’ve set the SupportsMFA parameter to false and enabled MFA for the user in Azure AD)

.

I configured MFA for  my test account to use mobile app notifications. Once you click on “Set up” you will receive a QR code which you can scan using the Microsoft Authenticator app (Work Account). Now when I login to Office 365, I’m redirected to my ADFS server and you will notice an option at the bottom for MFA Authentication:

Once you click on Azure Multi-Factor Authentication, you will have to then use the verification code from the Microsoft Authenticator app to authenticate yourself to Office 365.

Recommendations/Thoughts:

1. MFA as a primary method of authentication helps prevent the use of passwords thereby reducing the chance that the password gets stolen & it improves the experience of users that are trying to login with mobile devices where there’s not much real estate on the keyboard to type in a complex password.
2. I suspect more documentation on this topic will be published before Windows Server 2016 is available to corporate customers which might explain some of the caveats I’ve run into.
3. The integration of the cloud services such as the MFA service with the Server OS is a great way to unify the setup and configuration process regardless of if you are hybrid or cloud organization.

Microsoft Intune currently offers support for per-app VPN on Android if used with Pulse Secure. This functionality has been available for a while on iOS devices where the VPN tunnel is initiated when a user launches an application or hits a URL that’s been defined by the IT Administrator. This is a great way to ensure that mobile applications tunnel back internally to get data.

Recently, while testing out per-app VPN on Android with the Pulse Secure client it appears as though this functionality although published here was not working.

It took a while to realize that the per-app VPN works very differently with Android devices. Here’s the response received from the developer that implemented the feature:

In Android, PerAppVpn works a little different than iOS. It does not launch the VPN automatically when the app is opened, so the customer has to go open the PulseSecure VPN client manually and start the connection first. PulseSecure will then only allow traffic from the specified app(s) in the VPN profile to go through the VPN tunnel.

I’m hoping that this functionality becomes more like the experience on iOS devices because the whole goal is for the device to auto-initiate the VPN without users having to do this. Hopefully this is something that Android for Work can help solve as MDM capabilities are standardized across Android phones.