Item: Predica
Author: Tomasz Onyszko

Blog

8 MIN READ MARCH 19, 2020

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! I‘m not kidding – I‘ve done it before.

KEY TAKEAWAYS:

What tools are available for setting up remote access?
What is Azure AD WAP?
How to configure this service?

This is a part of an article series we created to help you implement a remote-first work environment with the help of MS Teams and Azure. Here you’ll find valuable tips to keep your business secure and efficient. See the additional articles at:

This is the first in a series of articles where I cover a range of solutions to quickly enable remote access to applications and data using Microsoft cloud.

My 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 optimize cost and impact on your environment. Think about reducing the use of network bandwidth, minimizing cost, or the ease of deployment.

What are the available options?

	Ease of deployment	Solution type	Best suitable for	Application type	Access layer	Time required to start
Microsoft Teams / Office 365	Easy	SaaS	Productivity and collaboration	Office suite, Microsoft Teams – web or client based	Web or client based	Hours
Azure VPN	Medium	Network	Remote work with full network access	Workstation connected to the network	Encrypted network connection	Day(s)
Azure AD Web Application Proxy	Easy	Application reverse proxy	Access to web based applications	Browser based applications	HTTPS	Hours
Remote Desktop Services on Azure IaaS	Complex	Remote desktop infrastructure	Remote access to desktop applications	Desktop, fat client	Terminal session (RDP)	Days (to weeks)
Azure Windows Virtual Desktop	Complex	Remote desktop as a Service	Remote access to desktop applications	Desktop, fat client	Terminal session (RDP)	Days

I’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.

Ensure your business stays productive with a remote work environment. See how we can help Check out

The business scenario

Your users are using an internal 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?

How to establish a safe remote connection?

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).

I 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 – here is a link to essential information. 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 synchronized 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.

Check out our smart remote workplace technology cheat sheet

Download now

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.

A real-life use case architecture explained

Watch a short video demonstrating an example architecture set up in one of our past projects.

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.

Stay safe and productive, wherever you are. Check out our rescue kit

Download

How does it work? Do I need any equipment?

I have explained the entire concept in two articles before, so you can get all the information in detail here:

Let Them Work! Application Access Made Easy. Case Study And Lessons Learned

Guests In The Cloud – How To Safely Manage External Users Using Azure AD B2B

And to make things easier, here is a summary.

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.

It’s that simple!

A diagram for an Azure AD WAP-facilitated connection

A remote connection established via Azure AD WAP service.

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. Effectively, it is exchanging Azure AD authentication token to internal network Kerberos authentication token.

(For my tech-savvy geeks – I know I simplified it a bit 😉 ).

In effect, the user from the Internet, authenticated with Azure AD, can access the internal application.

Done. Dusted. Delivered.

Deployment strategy

Finally, let‘s talk about the deployment strategy. Azure AD Web Application proxy does all the heavy lifting – for example, it does not provide the full desktop access. It works with browser apps (mostly – we can do some complicated stuff with it as well).

Where does it fit into your remote access strategy? This table provides a quick cheat sheet.

Solution	Access requirement
Azure VPN	Full network access from the workstation (desktop)
Azure AD Web Application Proxy	Remote access to Line-of-Business (LOB), browser-based applications
Azure Windows Virtual Desktop	Remote access to full desktop

It is quick, simple, and easy to deploy solutions for scalable application access.

Combining different solutions

Azure AD WAP can be deployed side-by-side with solutions like VPN and Remote Desktop access. What is the benefit?

You can move employees who work mostly with the Office suite and LOB web-based applications to Office 365 and Azure AD Web Application Proxy. It saves your VPN bandwidth and remote desktop resources for more demanding users.

The best part – there is no additional or hidden cost. Aside from the license, there are no bandwidth or traffic costs. You off-load your users to Azure AD proxy service free of charge (still, license for Azure AD has to be there).

Frequently Answered Questions

Q: What license do I need for Azure AD WAP?

A: You need at least the Azure AD P1 license, which is included in license bundles like EMS or Microsoft 365.

Q: Do I need any additional hardware or network equipment?

A: No, you don‘t. There are no network equipment changes. You need some server availability to install the proxy connector component. If you don‘t have free servers, you can do it based on Azure IaaS.

Q: Do I have to open some ports to the public network?

A: No, you don‘t open any incoming connections. All traffic is outgoing between your network (connector) and the Azure AD proxy service.

Q: Is this service secure?

A: Yes, it is very secure. I know how it sounds, but really – you can limit app access to users with MFA only, check the status of the operating system and other elements. Check out the topics on Conditional Access in Microsoft documentation.

Q: Is there a place where I can read more about this service?

A: Here is extensive Microsoft documentation. You can always reach out to our experts and we’ll help you work out how you can use this service.

Subscribe to our newsletter to get more tips on setting up a remote work environment and more! Sign up

Key takeaways

Azure offers a range of services enabling remote access, from Office 365 functionalities, through VPN, to Virtual Desktop.
Azure AD Web Application Proxy lets your users connect to your web apps from anywhere with minimal configuration required.
The key pre-requisites are an Azure license and an SSL certificate.

Tomasz Onyszko CTO

My name is Tom and I’m really happy to see you on Predica Blog. This is the place where IT professionals meet to not only deepen their knowledge in Microsoft technologies… but also to find innovative IT solutions.

Read similar articles