In this post we will empower users via the Azure AD Proxy by enabling them to obtain their BitLocker recovery key without calling IT for help.  We will also see how easy it is to protect access to the self-service site using Conditional Access and also how to publish the application to enrolled devices using Intune, which will make the self-service site very accessible and reduce helpdesk calls even further.

The Application Proxy is an excellent way to provide access to an internal resource from anywhere.  It’s very easy to set up and requires only two components – a connector and an endpoint (such as an external URL or access to MyApps)

I borrowed this image from the ebook “Defending the New Perimeter” which provides an overview of the App Proxy – notice that all connector traffic is outbound…

This post will provide a good example of a number of the Azure AD Premium features so even if you don’t use MBAM and the self-service website maybe you can envisage a service that would benefit from being published securely to your end users in the same way.

Paul Jones from Microsoft did create a great post on this topic back in 2015 but I would like to show the configuration using the Azure portal and also to go further and use AAD Conditional Access and Intune to protect and distribute the application to end users.

I am assuming at this point that you already have the self-service site for BitLocker created…you can read more on that here if you still need to do that part.

Summary

A summary of the steps:

1. Enable AAD Application Proxy and create an internal server as a connector
2. Create an Enterprise Application for the self-service website
3. Publish the self-service website using AAD Application proxy
4. Protect access to the site using Conditional Access
5. Test functionality
6. Publish to enrolled devices

Requirements:

1. Functioning BitLocker Self-Service website (or alternative web service you want to publish externally to your users)
2. Azure AD Premium Plan 1 & an Intune subscription (in my case this is EMS3)
3. Azure MFA is discussed and used later in the post but is not essential

Part 1 – Setting Up the AAD Application Proxy

Open the Azure Portal  and navigate to Application Proxy from the AAD node:

Enable Application Proxy

Download the connector and install it on an internal server that meets the requirements in the screenshot:

The installation requires Azure Global Admin credentials when prompted.  It’s also worth mentioning that some security hardening settings may cause the credential prompt to hang – in our case we find it easier to exclude the connector server from most of the domain GPO until after the connector has been installed and set up.

Once installed, refresh the Application Proxy page until the server you have configured appears in the list:

Creating the Enterprise Application

Back in the Azure portal open Enterprise Applications, click new application:

Choose to create an On-Premises application:

• Enter details for the Self-Service app – I went with:
  • Name: BitLocker Self-Service Portal
  • Internal URL: https://mymbamserver.myinternaldomain.com
  • External URL: https://BitlockerRecovery-mycompany-msapproxy.net (note: this can be improved by creating a CNAME  entry in DNS for your custom domain – see here for more information
  • Pre-Authentication: Azure Active Directory
  • Connector Group: Default (this is easy to change later if required and you can in the list of connectors above that I did create a dedicated connector group for this service)

After clicking “Add”….the subsequent page provides you with assignment options – because I want all of the users in my company to be able to use this application, assigning it to “All Intune Licensed Users” is fine for me because everyone here is given an Intune licence.  You may want to test this initially with a couple of users first however:

I also assigned a basic icon for the app but this is of course up to you

Server Delegation

1. In your on-premises environment launch AD Users and Computers
2. Search AD for the server you installed the Application Proxy connector role on earlier
3. View the properties of this computer object and then select the delegation tab
4. Select: “Trust this computer for delegation to specified services only”
5. Next select: “Use any authentication protocol”
6. Click on add and then select the SPN of the internal BitLocker Self-Service portal.

Creating a connector group

An optional but useful step is to create a connector group for the service you are providing.  This helps to organise connectors logically for each service, provide high-availability/resilience and also ensure any important services can have dedicated connector servers.

1. Click on add connector from the Application Proxy page in the Azure portal
2. Enter a name for the connector group and then select the server(s) you want to add to the group:

Part 2 – Securing with Conditional Access

Securing the application is straightforward.  Just open the Azure Portal and configure a CA policy that meets your specific requirements.

Personally I believe we should make access possible on any device as long as the user can satisfy at a minimum an MFA challenge.  It’s worth remembering that at the point your users need access to BitLocker Self-Service, they will likely be frustrated that they are currently unable to access their corporate device.  It will perhaps not help the situation if you put too many barriers in the way…to that end I want my users to be able to get to the site if any of the following conditions are true:

1.    Are using an enrolled and compliant device
2.    Using a corporate device that has been hybrid joined
3.    Can pass an MFA challenge

So with that in mind I recommend the following:

Create a new CA policy and from the available cloud apps find the enterprise app created earlier (in my case ‘BitLocker Self Service Portal’)

In the “Conditions > Device platforms” section apply the configuration to all supported platforms:

Next choose “Client Apps” and select Browser only:

In the “Access Controls > Grant section” ensure you have granted access to the app and have selected the conditions required for successful access.  Ensure that “Require one of the selected controls” is selected also.

Finally you will need to assign the CA policy to an appropriate group – again I can use “All Intune Users” but you might prefer to target just yourself and some colleagues initially 😉

Part 3 – Testing Functionality

Let’s now test the functionality out.  We can use pretty much anything that has access to the internet to test – here I have used FireFox from my test PC (which is unknown to my organisation) to show that I am indeed MFA challenged before I can access the self-service website:

Here I have navigated to myapps.micosoft.com

When I click on the BitLocker Ser-Service Portal app I am presented with an Azure MFA challenge:

Once I have satisfied the MFA challenge I’m taken to the Self-Service portal..

Access via my enrolled phone, or hybrid joined company computer is seamless, i.e. there is no MFA challenge as long as I meet one of the other CA conditions.

Part 4 – Publishing the App via Intune

We can expect that aside from a (currently un-bootable) corporate laptop or tablet,  most employees will also have a mobile phone with them.  To help them access the self-service portal we can provide them with a simple weblink that we can deploy via Intune.

Sign in to the Intune portal on Azure and then select Mobile apps >Apps>then Add

From the available application types choose “weblink”

Enter the relevant details for your app, the crucial part is obviously the App URL – this must point to the external address chosen when the enterprise application was setup in the Application Proxy (way back in ‘Creating the Enterprise Application‘ section):

Save the configuration and then choose the assignment group – again I have made this available to all users but I recommend you test the deployment first…perhaps you prefer to set a “required” deployment for your users but remember doing this means they cannot delete the weblink on their iOS device.

Finally we can see the app available in the Company Portal:

Upon installation I can click on the link, provide credentials and be taken to the internal web page via the Application Proxy.  If I’m not enrolled I get an MFA challenge.

One thing to note is weblinks are less convenient on Android…here you will need to add the Company Portal widget in order to see your weblink.

Summary

Although this appears to be a reasonably long post it’s really not difficult at all to set up the AAD Application Proxy and provide your users with a convenient and secure method to access your on-premises web services…I hope this post will help to get someone started with the excellent functionality the Azure Application Proxy offers.

Further reading:  Check out Oliver’s excellent post on the App Proxy, Conditional Access and the Managed browser for more insights.

Until next time…