Easy Setup for Azure AD Application Proxy: A Beginner’s Guide

successful azure ad application proxy

Azure AD Application proxy is probably not typical for what I write about, but I recently had to figure out how to get this working, so I wanted to document a couple key steps. Plus, there were a few areas of documentation that were just lacking to me and I couldn’t for the life of me find where to find the information. The plan is to put it here, and I will at least have an idea where to search in the future.

Azure AD Application Proxy is a ‘reverse proxy’ offering from Microsoft, that installs a “connector” inside your network, allowing it to proxy traffic through your firewall and provide access to on-premises resources or non-internet facing applications. This solution does not require additional modifications to your firewall, typically. With the AAD App Proxy, you can pass tunneled traffic over port 443 to your resources behind the firewall, without requiring several firewall exceptions. This is a huge advantage because you can avoid making internal web applications internet facing and instead run them behind the AAD App Proxy.

In truth, this technology is not new. Reverse proxies have existed for quite some time. If you are reading this, chances are it is new to you. That’s great because I can help save you the hours of research, I spent trying to find answers. Let me give you the basics so you can get up and running faster.


Please understand that the content herein is for informational purposes only. This existence and contents shall not create an obligation, liability or suggest a consultancy relationship. In further, such shall be considered as is without any express or implied warranties including, but not limited to express and implied warranties of merchantability, fitness for a particular purpose and non-infringement. There is no commitment about the content within the services that the specific functions of the services or its reliability, applicability or ability to meet your needs, whether unique or standard. Please be sure to test this process fully before deploying in ANY production capacity, and ensure you understand that you are doing so at your own risk.

Table of Contents

How it Works & Basic Setup
Custom Domain, SSL Certs and DNS Changes


There are only a few prerequisites to consider before deploying Azure AD Application Proxy.

First, is the fact that Azure AD Application proxy is limited to Azure AD P1 and P2 customers. This is probably not ideal for a Home Lab setup (I’ll be checking out Cloudflare Tunnels as an alternative there), but if you were a business customer, you may have an Azure AD P1 or P2 license already. If this it you, feel free to continue on.

Second, the AAD App Proxy gateway application will have to live on a server somewhere. Acting as the gateway is the entire purpose, so you will need some level of on-premises “hardware” to run the proxy service. A Windows Server in a VM environment is sufficient, so long as you give it enough resources to support the expected demand. It is also recommended to have at least two connectors in a group, for load balancing and redundancy.

Finally, you must know of what kind of authentication you want to have present in your application. If you’re exposing an internal application with its own form of local authentication or no authentication at all, the recommended option is to use Azure AD authentication. This approach ensures that you’re leveraging the full power and security of Azure AD to verify identity before granting access from the outside.

Spend some time reading through Microsoft’s documentation around planning an Azure AD Application proxy deployment. Check this link out as well. All the information you need for deployment and planning are available and are well organized.

How it Works & Basic Setup

Security is the name of the game with Azure AD Application proxy. This tool uses existing architecture to ensure that remote access to apps behind a firewall can be done without exposing more than is necessary. The connector that is installed on-premises connects to the Azure Application proxy service. These connectors are the key setup piece for this to work so let’s take a look at that first.

Install Azure AD App Proxy Connector

  1. First, login to Portal.Azure.com and search for Azure Active Directory. From there, click on “Application Proxy” to get started.
  2. First, hit the button to “Enable application Proxy”. This will enable it for the entire tenant.
  3. Hit the button to ‘Download Connector Service’. We will need to install this on our proxy server on premises.
  1. Once you have the connector software downloaded, login to your Windows server that will be acting as your connector on-premises. This server should be joined to the local domain for easiest setup, though it is not required.
  2. Run the installer, signing in with the appropriate account (Global Administrator), and continuing through the prompts until finished. Once finished, return to the Azure Portal, and confirm you now see a connector in the Application proxy page.

Configure Enterprise Application

*NOTE* – If you are tying this into an application that has an existing Enterprise Application in Azure, you CAN use that Enterprise Application. However, I recommend creating a new one instead. This will make it easier if you need to remove it later, as you will be able to delete the alternate Enterprise Application without having to alter the original.

  1. Now, Navigate to Azure Active Directory –> Enterprise Applications.
  2. Next, hit the button to create a New Application. Choose “Add an On-premises Application”.
apping on premises application for azure ad application proxy
  1. Update the details of your web app so that it matches the internal hostname of the application you want to make public facing. In this case, I’m using my Patch Manager page. Don’t worry it will be deleted before this goes live.
Settings for the azure ad application proxy enterprise application
  1. Once you are finished, hit Create to create your application. Hit the ‘Copy’ button at the end of the external URL to grab that link and test it out. You should see an error message at this point. We need to give ourselves access.
error because we didn't assign permissions to the application yet
  1. Click back on ‘Enterprise Applications’ at the top and go back into the app we just created. Click on the ‘Users and Groups’ button. Choose ‘Add User/Group’ button and add yourself for now (we can add others later). Once added, try the link again.
successful connection to azure ad application proxy

Success! We should now be able to access our site from the App proxy link. (With one exception, see below)

SSL Error – Bad Gateway

ERROR: BadGateway:
This Corporate app can’t be accessed. One or more errors were found in the Secure Sockets Layer (SSL) certificate sent by the server.

BadGateway: This Corporate app can't be accessed.

One or more errors were found in the Secure Sockets Layer (SSL) certificate sent by the server.

You may run into a situation where you get this error above. if you see this, this happens because the SSL cert for HTTPS on the site you are trying to access isn’t issued from a CA in the trust chain of the App Proxy server. There are two ways to fix this:

  1. First, you can change your Enterprise App to ignore certificate validation. (Not Recommended)
    • Open your Enterprise Application
    • Click on Application Proxy
    • Clicked Advanced
    • Uncheck ‘Validate Backend SSL certificate’
    • Test again – Error should be gone.

This is fine for testing, but it is highly recommended to leave this box checked for security reasons.

  1. Second, you can (and should) import a third-party certificate and ensure it is validated correctly. We will cover the steps for this later, but you could do this with an Enterprise Windows PKI certificate as well if you wanted. The important thing you have to ensure, is that every device connecting to this service will need the domain certificate chain on it, or you will get the error above. I won’t cover that process here, but that is well-documented in many other parts of the internet.

We’re going to look at third-party certificates instead.

Custom Domain, SSL Certs and DNS Changes

Here are two more reasons the Azure AD Application Proxy isn’t ‘Home Lab’ friendly.

  1. Certificates from most third-party providers cost money.
  2. Azure AD Application Proxy doesn’t have native integration with Let’s Encrypt, so you would need to build it yourself.

In this case it basically mean’s I’m not going to have a bunch of screenshots in this section. 🙂

DNS Considerations

Microsoft has some excellent guidance on how and when you should configure your domain for your custom-built app. I would recommend, if at all possible, to keep the same external and internal DNS address. This will mean that name resolution should be easier for anyone accessing the site, and consistent whether they are inside or outside the network.

  • Internal Address for my site: DesktopCentral.SeeSmitty.net
  • External Address for my site: DesktopCentral.SeeSmitty.net

This FQDN will be what we are going to use as our domain for the certificate below.

Example: GoDaddy SSL Certificate

GoDaddy SSL certificates aren’t cheap unfortunately. I’m confident that a quick web search will reveal alternative sites for purchasing an SSL certificate, but since I’m not going to purchase one for this project, I’m going to stick with what I know.

  1. First, you have to get your certificate. Head out to GoDaddy and purchase a certificate for the time you wish. Then follow these instructions up until the ‘Install my SSL’ step. Your domain will be the custom FQDN we mentioned above.
    • Be 100% sure to download the Private Key, as it is critical to later steps in this process.
  2. Once you have your Private Key and the SSL certificate zip file downloaded, we are ready for the next steps.

Install OpenSSL

We will be using OpenSSL to combine the .crt file and the private key into a .pem file, which we will use to generate a .pfx file. This is needed by the Azure AD Application Proxy to provide an SSL certificate for our custom domain.

  1. The easiest way (In my opinion) to install OpenSSL, is via winget. So long as you are up to date with Windows and on a supported release, this is the easiest method. It requires Administrator privileges to install. (Check GitHub for the latest instructions). Open PowerShell as Administrator and run this command.
winget install openssl
  1. Next, we will want to ensure OpenSSL is added to the Path Environmental variable for this to work seamlessly.
#Update this if your installation directory is anything but default
$env:Path += ";C:\Program Files\OpenSSL-Win64\bin"
  1. Next, in File Explorer, extract the downloaded .zip file containing the certificates.
  2. Grab the private key file you downloaded and copy it into the folder with the certificate information you downloaded.
  3. From within your PowerShell window navigate to the folder where all these certificate files you just downloaded (and private key) are located.
  4. Once you are in the correct directory in PowerShell, run this command (replacing the placeholders with the real names).
#Combines the two files into a single file for the creation of the .pfx file
copy /b ssl_certificate.crt + private_key.txt ssl_certificate.pem
  1. Now, run this command to get the .pfx certificate. (This will prompt for a password, so have a password ready that you want to assign and save it somewhere secure!)
#Exports the .pfx file using the private key and the .pem file created earlier
openssl pkcs12 -export -out ssl_certificate.pfx -inkey private_key.txt -in ssl_certificate.pem
  1. Now, back in your Browser, go back to your Enterprise Application for your app proxy, and click the drop down for the custom domain, so the custom domain matches what you entered into the certificate.
  2. Click the ‘SSL Certificate’ link to upload the .pfx file you just created.

As long as this is successful, you should now see the custom domain as the ‘External URL’ and a successful notification from Azure.

DNS Changes

Last but not least, we need to let DNS know the changes we made to our custom domain URL. (Instructions for GoDaddy as an example)

  1. In your DNS records, you will need to add a CNAME entry. Login to your DNS provider and add a CNAME entry.
  2. Enter the details for your new CNAME record:
    • Name: The host name or prefix the CNAME record will be set to. (ex. DesktopCental)
    • Value: The URL you are setting as the destination for the host. (ex. https://desktopcentral-77d5fd.msappproxy.net/)
    • TTL: Default is fine (Usually 1 hour)
  3. Select Add Record to save your new CNAME record.

It can take 24-48 hours for DNS changes to be reflected everywhere, but usually within an hour or so, you can start testing the new custom URL.


There it is! Your first Azure AD Application proxy is online and working! This should provide secure access to applications that live behind the firewall with minimal changes needed to the environment. Eventually you’ll want to have a second proxy server on premises to help with load balancing and availability. Additionally, you may want separate groups of proxy servers in different regions if they live in different areas. From here you can expand to fit your needs.

Additionally, since this is an Enterprise Application in your tenant, you can now make it available based on group membership in Azure AD. You can have the application show up as a featured app on their Microsoft 365 home page, and also leverage conditional access policies to lock it down further. All the advantages that come with Azure AD P1 & P2 are available in this solution as well.

There are still some challenges to this process that make it difficult for Home Labber’s to really take advantage of it, but for the purpose of learning, it can be fine temporarily. Unless you already have premium licensing, or you are just using a disposable dev tenant, there will be costs incurred.

As always, let me know what you think and if this worked for you. Hit me up on Twitter @SeeSmittyIT to let me know what you thought of this post. Or if you are avoiding the bird site, I’m also posted up on Mastodon @[email protected]. Thanks for reading!


Curtis Smith works in IT with a primary focus on Mobile Device Management, M365 Apps, and Azure AD. He has certifications from CompTIA and Microsoft, and writes as a hobby.

View all posts by Smitty →