There is one problem which we are often asked to solve for our customers. This is – how to publish the application in a secure way to the external users? The answer is – Azure AD.
We have plenty of examples here. Let me give you the one with our customer operating several branches and stores. As a retail company, they have a lot of data stored in internal databases. And a common scenario to enable users to access the data is to use SQL reporting services or PowerBI.
This works fabulously when the user is part of the internal network. But what about mobile users, users working on the Internet? How will they get access to these reports?
Azure AD at Predica
That’s a typical problem that you may face when deploying new application or data access application for your users. So how to enable them to access to this application from anywhere? How to make it easy to use and secure from a company perspective? What businesses tend to use in the past was application firewalls and proxies deployed on-premises. Another solution was to require users to connect to company VPN before accessing these applications.
Now, Predica is a cloud-first company – we don’t have any on-premises infrastructure. With new services offered as part of Azure platform, we have introduced a simple solution you can use to publish such applications within minutes! And also get an additional level of security for it. Please pay attention to our scenario with this in mind and at the end I will have a question for you.
What is Azure Active Directory Web Application Proxy
OK, let’s start. First, let me introduce you to Azure Active Directory Web Application Proxy. It is a reverse proxy service hosted for you as part of Azure services by Microsoft. Let’s see the components one by one:
- First, we have existing on-premises network with Active Directory controlling access to resources through Kerberos authentication
- Next, we have application deployed on-premises, in our case SQL Server and SQL reporting services
- This is typical scenario where users authenticated against Active Directory are accessing on-premises application
Now, when our user is moving outside of their on-premises network, it can’t access same resources as Active Directory. Why? Since it was never built to extend an authentication to users over the Internet.
How Azure AD Web Application Proxy can help us
Our company has deployed Azure AD, and the Web Application Proxy is part of this service. To make it work, we need Azure AD WAP connector implemented within our on-premises network to publish the application.
You may ask now “is this secure? How come?” Well, the WAP connector is using outbound, secure connection to its service to publish our service. The last piece of the puzzle is the configuration to publish our service through Azure AD WAP. For this, we need an external name for it and SSL certificate.
What you need now is to map an external name to internal resources and provide information how to map incoming user tokens to Kerberos tickets. What Azure AD Web Application Proxy can do for us? Simple as that. It authenticates the user based on Azure AD and exchanges this to on-premises Kerberos ticket with constrained delegation.
Here the magic happens
This way we can authenticate the user against Azure Active Directory and access the resource published with WAP using Azure AD. When going to the on-premises resource, it will be automatically translated to Kerberos ticket. So here the magic happens!
We are accessing our on-premises application with user authentication and Single sign-on provided. It means our users don’t need to log on additionally to access published application from on-premises. You can do this not only with SQL reporting but with any application you are hosting internally.
As you can see, we use Azure AD provided service to replace typical solutions for application publishing. No firewalls or on-premises equipment has been abused during this video. It can be done within few minutes and remain secure with Azure AD authentication. There can be an additional level of protection with Azure AD conditional access and multi-factor authentication provided as well.
But wait, what if you don’t have Azure AD? It can also be done with on-premises Active Directory, AD FS and Web Application Proxy component of Windows Server. I will cover these additional scenarios in our next episode, so make sure you are following our social media.
Now, as you remember, I asked you to pay close attention to our situation in Predica, as a cloud-first company. How come are we using SQL Reporting Services and Active Directory without on-premises Active Directory? Please put your ideas in the comment underneath this blog entry. We will figure out a little gift for you – first correct answer wins. Thanks and see you in the next episode.