What is locked by someone else’s key? Exceptions to BYOK in Power BI
Data governance is one of the hot topics right now. Especially if you’re in a regulated industry like finance or insur...
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.
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.
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.
|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).
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.
Your users are using an internal web-based application. It might be one of (but not limited to) the following:
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.
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:
Time required, assuming you already have Office 365 tenant with users: 1 hour.
All checked. Now, let’s look at the app.
Azure AD Web Application Proxy works with browser-based applications using:
You can publish an application in two modes:
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.
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:
Time required: 1-2 hours.
I have explained the entire concept in two articles before, so you can get all the information in detail here:
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!
Here‘s the secret sauce. When the user connects to external application URL, Azure AD does some complicated stuff:
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.
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.
|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.
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).
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?
Read similar articles