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

Register-AppProxyConnector

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 AADAPFeedback@microsoft.com.