All you want to know about Azure AD Application Proxy connectors

The connectors are the secret sauce of Azure AD Application Proxy. They are simple, easy to deploy and to maintain but super powerful. We have gathered in this blog post different topic regarding the connectors that we were asked about.


One connector, two connectors, lots of connectors

You can install connectors based on your high availability and scalability needs. You can start with one and then add more as needed. Each time a connector is installed it is added to the pool of connectors that serves your tenant.

It is recommended not to install the connectors on the application servers themselves though it is possible, especially for small deployments.


Cloud Rules!

The connectors and the service take care of all the high availability tasks. They can be added or removed dynamically. Each time a new request arrives it will be routed to one of the connectors that is currently available. If a connector is temporary not available, it will therefore not respond to this traffic.

The connectors are stateless and have no configuration data on the machine other than the connectivity to the service settings and the certificate that authenticate this connector. When they connect to the service, they pull all the required configuration data and refresh it every couple of minutes.

They also poll the server to find if there is a newer version of the connector. If one is found, the connectors update themselves.

You can monitor your connectors from the machine they are running on using either the event log and performance counters or from the cloud using the connector status page.


All networking is outbound

Connectors only send outbound requests. There is no need to open inbound ports. The outbound traffic is sent to the Application Proxy service and to the published applications. The traffic to the service is sent to Azure datacenters to several different ports numbers. Look here for more details.

As a result of having only outbound traffic, there is no need to setup load balancing between the connectors or configure inbound access through your firewalls.


To DMZ or not to DMZ?

The connectors can be installed anywhere that allow them to send requests to both the service and the backend applications. They will work fine if they are installed inside the corpnet, within a DMZ or even on VM that is running in the cloud and has access to the apps.

DMZ deployments are usually more complicated. But, one of the reasons to deploy connectors in the DMZ is to use other infrastructure that is available to components running there e.g. backend application load balancers and/or security controls like intrusion detection systems.


To domain join or not to domain join?

The connector can run on a machine that is not domain joined. However, a domain joined machine is required if you would like to use single sign-on (SSO) for applications that use Integrated Windows Authentication (IWA). In this case, the connector machines must be joined to a domain that can perform Kerberos Constrained Delegation on behalf of the relevant users for the published applications.

Connectors can be joined to domains or forests that have a partial trust or to read-only domain controllers (RODC).


Connectors on hardened environments

In most cases, connector deployment is very straight forward and requires no special configuration. But, there are several unique conditions that should be taken into consideration:

  1. Organizations that limits the outbound traffic must follow the instructions here to open the required ports.
  2. FIPS compliant machines might be required to change their configuration to allow the connector service, the connector updater service and its installer to generate and store a certificate on that machine.
  3. Organizations that lock down their environment based on the processes that issue the networking requests have to make sure that both the connector services are enabled to access all required ports and IPs.
  4. In some cases, outbound forward proxies may break the two way certificate authentication and cause the communication to fail.


All connectors are equal (until…)

All connectors are assumed to be identical to each other and every incoming request may arrive to each one of the connectors. This means that all of them should have the same network connectivity and Kerberos settings.

Our team is working on introducing new way to group the connectors so they can serve different sets of applications, installed on different networks or joined to several different forests. Stay tuned for updates.


Connector authentication

In order to provide a secure service, the connectors have to authenticate toward the service and also the service has to authenticate toward the connector. This is done using client and server certificates when the connectors initiate the connection. This way the administrator’s username and password are not stored on the connector machine.

The certificates that are used are specific to the Application Proxy service. They are created during the initial registration and automatically renewed by the connectors every couple of months. If a connector is not connected to the service to a period of several months, it might have outdated certificate and registration is required. In this case, just uninstall and install the connector to trigger registration or run the following PowerShell commands:

Import-module AppProxyPSModule




Performance & Scalability

While the on-line service scale is transparent for you, scale is a factor when it comes to connectors. You need to have enough connectors to handle the peak traffic. Since the connectors are stateless, they are not dependent on the number of users or on sessions, but on the number of requests and their payload size. For the standard Web traffic, we have seen an average machine handle a couple of thousands of requests per second – depending on the exact machine characteristics.

The connector performance is bound by CPU and networking. CPU is needed for the SSL encryption and decryption while networking is important to get fast connectivity to the applications and to the on-line service in Azure. In contrast, memory is less of an issue for the connectors.

On the service, we make an effort to off load the connectors as much as we can. The on-line service is taking care of much of the processing and on all unauthenticated traffic. Everything that can be done in the cloud, is done in the cloud.

Another factor on the performance is the quality of the networking between the connectors and:

  1. The on-line service: If the connection is slow, jitter or have high latency it will influences the service level. It is the best if your organization is connected to Azure via Express Route or that the networking team made sure that connections to Azure are handled in an efficient way.
  2. The backend applications: In some cases, there are additional proxies between the connector and the backend applications. It is easy to troubleshoot this by opening a browser from the connector machine and accessing these applications. If you run the connectors in Azure, and the applications are on-prem, the experience might not be as your users are used to.
  3. The domain controllers: if the connectors are performing SSO using Kerberos Constrained Delegation (KCD), they contact the domain controllers before they send the request to the backend. The connectors have a cache of Kerberos tickets but in a busy environments, the responsiveness of the domain controllers can slow the experience. This is more common for connectors that run in Azure while the domain controllers are on-prem.


Under the hood

While we provide all the tools for you in Azure, the connectors also have lots of local useful functionality. As the connectors are based on Windows Server Web Application Proxy, they have most of the same management tools; including the rich set of Windows Event Logs and Windows Performance counters:


Note that the connectors have both admin and session logs. The admin logs includes key events and the errors. The session logs include all the transactions and their detailed processing. To be able to see them, you have to enable “show analytic and debug logs” on the event viewer “view” menu. Then, you have to enable them to start collecting events. These logs do not appear in Web Application Proxy in Windows Server 2012 R2, as the connectors are based on a newer version.

If you want to examine their execution, the connector is comprised of two Windows Services, one is the actual connector, and another is one that takes care of the update. Both of them are required to run all the time.


We are going to update this post as we evolve the connectors on future releases.

If there is a question on the connectors that remained unanswered or for any feedback you have, send us an e-mail to

Comments (25)

  1. Great Post - very Helpful says:

    For the random Admin trying to use a technology in preview, these under-the-hood type posts by the developers are truly invaluable. Thanks for Sharing!

    Also, Here’s a vote for reducing all outbound traffic to port 443! The half-dozen "custom azure ports" are our biggest to deployment.

  2. adam says:

    can you explain why there’s no inbound traffic? I don’t understand this statement "There is no need to open inbound ports"… how is the data sent to the published applications if there’s no inbound traffic?

    1. Murad Akram says:

      @ Adam, “There is no need to open inbound ports”. Basically this means the connection will always be initiated by the connector(s) and once the session is established, the traffic will flow both way.

    2. Paul Ungoed says:

      It is the same principle when you open a browser and make a request for a website. You establish the connection, which then allows the requested information to flow over that existing connection state. The proxy connector connects to Azure and establishes an outbound connection (known as a service bus) that remains established to allow the inbound requests to be made through that service bus.

  3. Philip Gumm says:

    Once an ‘Out-bound’ TCP connection has been established, traffic can flow both ways, it’s just that the initial TCP connection cannot be made ‘In-bound’ by any sort of ‘baddie’! 🙂

  4. sadia_m says:

    I want to know about"> proxy websites , as I know it can hide all information that we do while using the internet. Is it true really it can hide IPaddress and location.

  5. Abhishek Sudhir Choudhary says:

    Thanks for clearing my doubts.
    By the way here’s the list of proxy sites I use –

  6. Stephane Eyskens says:


    I’ve successfully publiished some applications to the Azure Proxy and SSO is working fine. However, all of this works through a browser. Is it possible to leverage the proxy (external URLs) from a server-side request? The idea is to have a front-end web site
    site in Azure with its webapi calling to the onprem webapi via the proxy. It doesn’t seem to work and I doubt the proxy is meant for that but I’m not totally sure.

    Any clue?

    Best Regards

  7. E.ISSALY says:


    I’m setting up a sharepoint lab to test your proxy, as it sounds a good alternative to ADFS. And just publishing your onprem SharePoint as an app makes sense!

    Now, I have two questions :

    – I noticed there’s quite a lot of outbound traffic to open. My corp Allows only opening traffic to fixed IPs, not domains. Is this resolvable?
    – in case the customer already leveraged ADFS, is the connector still usable? in that case i’d activate both integrated and claims auth on my onprem app, users coming from the proxy would be using a non claim aware RP to be mapped to a window identity (if i
    follow everything correctly 😉

  8. Billy [MSFT] says:

    In response to the comment from E.ISSALY regarding the fixed IPs for the Azure datacenters, please see:

    How to troubleshoot Azure AD Application Proxy connectivity problems

    As the service is spread across several different data centers for high availability and optimization, you must include all Azure datacenters IP range as specified here:

  9. MD says:

    In a point above, it says it’s best for an organisation to be connected to AAD-AP through an ExpressRoute. How would this work if it connects to which would go through the public internet. Is this just a traffic route to send it to Azure
    first before going out?


  10. Deane says:

    For outbound firewall rules, does the Azure Application Proxy get a static IP address? Or do we need to open outbound ports to every Azure IP?

  11. David Sampson says:

    Is it possible to delete a connector from the portal? I redeployed a connector server and now have a duplicate inactive connector entry I don’t need. There aren’t any options in the portal, can this be done from PowerShell?

    1. Jörg says:

      I have the same problem with an redeployed connector, now I have two with the same name where one is inactive. How delete the inactive connector.

      1. David Sampson says:

        I Got this response on another post. Thanks Ross!

        There is no way today to remove/”unregister” a connector. When a connector is running it will remain active as it connects to the service, if you uninstall the connector or simply turn off the box it is running on it will be marked as inactive and removed from the list of connectors in 10 days if it remains inactive during that time. We do this because it is possible that a connector could come back online during that period and no information is lost.

        1. Benoit says:

          Hi there
          I think there is some glitch as I’m unable to delete a Connectors Group because there is still inactive connector; but this/these connector(s) has/have been inactive/uninstalled for months as I was testing the solution
          It would be great to have some PowerShell command to list the connector(s) and group(s) and force a deletion

  12. David Sampson says:

    Very useful post guys thanks.

    It would be good to understand a little more of the mechanics around the outbound connection. Does the connector maintain an outbound connection all the time in order to service new requests or does it poll an Azure service and open a connection when necessary? What encryption is applied to the connection between the service and the connector?

    1. Avi Carmon (MSFT) says:

      The connector doesn’t keep the connection open. it is currently constantly polling for new msgs. All connector to service communication is protected by a client cert that is in installed on the connector machine and was issued when the connector was installed

      1. David Sampson says:


  13. Abhi113 says:

    I am seeing an expiry of the connector certificate on the server where it is installed. We are using it quite frequently as we have published our internal sharepoint sites through it. Therefore I am expecting a auto renewal as mentioned in this post. Is there a time frame before which it should renew? This is may help us to decide whether a manual reinstallation is required.

    1. Avi Carmon (MSFT) says:

      If your connector cert is not being renewed and is going to expire in less than 14 days than it is probably due to a blocked port on your side. Pls see for the list of needed ports. Probably port 9091 is blocked. Pls email us at Azure AD Application Proxy feedback if this is not resolved.

  14. Matt Hudson says:

    Is there any content caching in the Azure Application Proxy setup, if so where does it happen? If not, is it needed and is there a way to add it?

    1. bjornhouben says:

      Our certificate was also expiring, and I did not want to find out that auto renewal did not work …..

      So I tried running:
      Import-module AppProxyPSModule

      For some reason however I got the following error with the module:
      PS H:\> import-module AppProxyPSModule
      import-module : The specified module ‘AppProxyPSModule’ was not loaded because no valid module file was found in any mo
      dule directory.
      At line:1 char:1
      + import-module AppProxyPSModule
      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      + CategoryInfo : ResourceUnavailable: (AppProxyPSModule:String) [Import-Module], FileNotFoundException
      + FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand

      After running Import-Module -Name ‘C:\Program Files\Microsoft AAD App Proxy Connector\Modules\AppProxyPSModule’ -Verbose
      I was able to succesfully renew the certificate.

Skip to main content