Access Management for Microsoft Tunnel

A few days ago I wrote a blog with my first experiences about Microsoft Tunnel.

In the first version of this blog I complained that I can’t assign the app to groups and therefore have to filter for a PoC via conditional access. I put this point also in an “Ask Microsoft Anything” and got a solution for this problem — thanks Alan Jowett !!!

I have now taken this opportunity to further explore the topic of Access Management for Microsoft Tunnel.

Who should get access?

I always try to separate between the WHO and the HOW. The control of who can access an (Enterprise) App is unfortunately a bit inconsistent in Azure AD, but is usually done via the Blade Users and Groups on the App in the Azure Portal.

To ensure that only the users defined in Users and Groups have access to the app, the User assignment required button in the app’s properties must be activated:

However, the fact that this switch cannot be configured in its usual place in the portal does not mean that it is not present. Even with Service Principals for Microsoft applications such as “Microsoft Tunnel Gateway” it is possible to implement the requirement for assignment — even if only via PowerShell using the AppRoleAssignmentRequired parameter.

To illustrate this, I would like to briefly run through the scenario and the necessary steps. I have two test users (Claire and Thor) and will only authorize Claire in the first step and then test with Thor. After Thor is not able to create a tunnel anymore I will authorize him and test again.

After adding Claire to the Blade Users and Groups we only need to execute the following command (after Connect-AzureAD as Global Admin)

Set-AzureADServicePrincipal -ObjectId (Get-AzureADServicePrincipal -Filter “AppID eq ‘3678c9e9–9681–447a-974d-d19f668fcd88'”).ObjectId -AppRoleAssignmentRequired $true

After a restart of Thor’s device an error message is displayed as expected and the logs show that the assignment is missing.
This means: our configuration works.

After Thor got an assignment to the app he can connect his tunnel again:

Now that we have the Microsoft Tunnel Gateway app in a state where we can control access via the Users and Groups Blade, we should start developing the solution further.

How should an access take place?

For the question of how access is to take place, conditional access is the method of choice. As described in the Microsoft Deployment Guide, the Microsoft Tunnel Gateway can be selected as an Enterprise App in any Conditional Access Policy.

The rule here is: MFA is good, device compliance is better!

Since the Tunnel app on the device is able to send the device ID, Azure AD can query the compliance status and only allow access to compliant devices. Device compliance is a dynamic state that depends on whether the device is currently compliant. Through the integration with Defender for Endpoints, the risk level of the device can (and should) also be taken into account, meaning: If there is an acute threat on the device, it is not possible to build the tunnel until it is eliminated — Zero Trust!

Static IP des Gateway -> Trusted Location Cloud Apps

How do I achieve (as admin) that I do not have to take care of every assignment myself?

I would not recommend to use the role Application Admin at this point, because a privilege escalation would be possible here. The key to delegating permissions to Microsoft Tunnel are security groups. The groups used here can also be the same as those used in the Endpoint Manager for assigning the app and the tunnel configuration.

The groups can either be administered by an owner or provided to users via Access Packages, but the use of Access Packages is clearly the better way here, as we use them to implement self-service for the user, an approval process and a recertification process.

For self-service, there are 2 ways: the MyAccess Portal or using direct links to the Access Package, e.g. on the intranet.

How do I ensure in the long run that only the right people have access?

Another advantage of using Access Packages is that two options are also included to allow the permissions to be checked regularly.

• Each group membership granted by Access Package can be directly provided with an expiration date and a mechanism for renewal can be defined.
• Access Reviews are already integrated in the Access Package but can also be used independently and offer a simple and automated way to check existing permissions and, for example, withdraw permissions that are no longer used.

Creating an Access Package for Microsoft Tunnel

To summarize what is described here, I will show an example of creating an Access Package for the use of Microsoft Tunnel (here the UCC Tunnel group) with the following parameters:

• included in a new catalog for traveling users
• for internal users only with an approval by the manager
• without expiration and with a self-review access review every 6 months