Azure AD WAP: How to Set Up Secure Remote Access in Two Hours

Do you have remote users who need to access internal applications such as BI dashboards, intranet, HR or payroll? Do they need to use a VPN? Or maybe they don't have access to apps when they are outside of the office? Struggle no more – here is a one-stop guide to establishing remote access to web-based line of business applications. And you can have it up and running in less than two hours! Not kidding – we've done it before. Here we will cover a range of solutions to quickly enable remote access to applications and data using Microsoft cloud. Our goal here is to make it easier for you to select the right option for your needs and provide all the resources you need to start using it.

Microsoft services for remote access

There are different services, and there is no one-size-fits-all solution. But most importantly: you can mix different options. It is an excellent way to optimise cost and impact on your environment. Think about reducing the use of network bandwidth, minimising cost, or the ease of deployment.

What are the available options?

We'll skip Office 365 and Azure VPN for now and jump right to Azure AD Web Application Proxy (Azure AD WAP).

Why Azure AD WAP?

It is fast to deploy, cost-effective, and might work in many use cases. It is also very secure – you can apply all the Azure AD's security heavy weaponry to it – starting with MFA to complete Conditional Access. And the best thing? It doesn't require any changes in applications or the network on your end. You don't have to touch the application, and you can make it available to remote workers, reliably and in almost no time.

The business scenario

Your users are using aninternal web-based application. It might be one of (but not limited to) the following:

• SharePoint portal
• SQL Reporting Services / Power BI
• HR application (payroll, SAP, Oracle EBS)
• Web reporting solution
• Your internal app for – you name it.

It doesn't have to be a commercial product. It might be your own application developed in-house. Users need to go remote and access it from home. Of course, there is a VPN – but do we really need it to grant them access to a browser-based app? Here is a recipe for enabling VPN-free access to these apps in less than two hours.

Ingredients and flow

Azure AD Web Application Proxy is a PaaS service (Microsoft operates it, and there is no infrastructure at your end). This service is part of Azure AD functionality. The starting point is to have a license. You need Azure AD P1 or P2 license (P1 is enough – here is the license comparison). We assume you have done the legwork, and your users are already using Office 365 and Azure AD. If not – there are simple steps to enable it. You can always contact us, and we can help you. You need to download and install to your on-premises network a small component called Web Application Proxy connector. Deploy at least two of these to provide high-availability and load balancing. In a simple case – that is all. For a larger scale (thousands of users, complex network), you might need a bit of design for it. Here are the pre-requisites for publishing your first application in the form of a list:

• Azure AD tenant with at least P1 license (if you are using Office 365 you already have Azure AD, please check your licenses' option)
• Users synchronised to Azure AD (done if you have Office 365)
• Downloading and installing the Application Proxy Connector.

Time required, assuming you already have Office 365 tenant with users: 1 hour. All checked. Now, let's look at the app.

Applications

Azure AD Web Application Proxy works with browser-based applications using:

• Windows authentication (SSO based on Active Directory domain on-premises)
• SAML authentication
• other mechanisms for login (username and password), with the exception that the user does not have the full SSO experience (still requires to log in to an app).

You can publish an application in two modes:

• Pre-authenticated – the user gets the full SSO experience based on the fact they use Office 365
• Pass-through – the user gets securely to an application but must log in to it separately.

Your application is currently available on the internal network – for instance, Intranet on SharePoint can be available at https://intranet.<company domain>. You can publish it at the same name or using your commercial, external domain name. For the user, it is simple – they type https://app.domain.com in an app and get to it instantly. To make it all work, you'll need an SSL certificate. You can request one from a commercial provider like DigiCert or from Let's encrypt (non-commercial certificate authority). What you need in summary:

• Internal application URL: how users access it at the moment
• External application URL: how it is visible to the user
• SSL certificate: commercial or from a trusted authority.

Time required: 1-2 hours.

How does it work? Do I need any equipment?

Azure AD provides an entry point for your users. It publishes your external application URL to the Internet. On the other side, the Azure AD WAP connector creates an outgoing connection to this proxy. What's important – it is an outgoing connection. There are no incoming connections, and no ports open from your end. When a user accesses the external application URL, Azure will wake up your connector and send user traffic to it. The on-premises connector in your network forwards it to the internal application URL.

The inner workings

Here's the secret sauce. When the user connects to external application URL, Azure AD does some complicated stuff:

• User is authenticated with Azure AD (including MFA if it is in place – remember: with Security Defaults, it's free of charge).
• It applies conditional access rules (if in place) to make sure that the client connecting to the app is compliant and that access is secure.

If the application is based on Windows authentication, it also does a really clever thing, which is requesting a Kerberos ticket for the user (delegation) to access an app.