Customers utilize Azure AD Application Proxy for more and more scenarios and applications. They asked us to make App Proxy more flexible, and to enable more topologies. We are enabling this using Application Proxy Connector groups – a new capability to assign specific connectors to serve specific applications. This capability enables a slew of use cases for Application Proxy that were not possible before. Over the last few months, during the private preview phases of this functionality, we already saw large customers deploying it to boost their live Application Proxy deployments. It will be available as a preview in the next couple of months.

The basic concept is that each Application Proxy Connector is assigned to a connector group. All the connectors that belong to the same connector group act as a separate group for high-availability and load balancing. By default, all connectors belong to a default group. The admin can create new groups and change these assignments in the Azure portal.

By default, all applications are also assigned to the default connector group. If the admin doesn’t change anything, the system keeps on behaving like it did before. All the applications are assigned to the default connector group that includes all the connectors. But if you organize your connectors into groups, you can then set each application is to work with a specific connector group, so that only the connectors in that group serve the application when it is requested.

Since new connectors are automatically assigned to the default connector group, it is recommended in large deployments not to have applications assigned to this group. In this case, once installed, the connectors will not receive any live traffic. Only after the connector is assigned to one of the active groups, it would start serving live traffic. This also enables you to put connectors in idle mode to enable maintenance.

Use cases

There are many reasons to use connector groups. Here are some of them:

Optimizing a multi-datacenter experience

Many organizations have a number of interconnected datacenters. In this scenario it’s best to keep as much traffic within the datacenter as possible, and not utilize cross-datacenter links that are usually expensive and have high latency.

If you deploy connectors in each datacenter to serve only the applications that reside within the datacenter, it saves valuable cross-datacenter links and from the end-users’ point of view it’s entirely transparent.

Applications installed on isolated networks

In some cases, applications are hosted in networks that are not part of the main corporate network. This usually happens when a 3^rd party vendor maintains a specific application for your organization.

Connector groups allow you to install dedicated connectors for this network that would publish only these specific applications. This makes it easier and more secure to outsource application management to 3^rd party vendors.

Applications installed on IaaS

Many organizations are moving to or experimenting with the cloud, by following the Infrastructure as a Service (IaaS) model. In such cases, the organizations have number of virtual machines connected to their own IaaS hosted virtual network. To allow employees to use these applications, in most cases, these private networks are connected into the corporate network using site-to-site VPN. This provides a good experience for employees that are located on-prem but it is not ideal for remote employees and requires additional on-premises infrastructure as you can see here:

The problem is even worse as most organizations are using multiple cloud vendors and many of their applications reside in numerous datacenters. With Azure AD Application Proxy connector groups, you can now have a common service to secure the access to all of them without creating additional dependency on your corporate network or fragmenting the experience:

Connectors could be installed on every cloud datacenter and serve only applications that reside in this network. You can install several connectors to achieve high availability. This will allow consistent identity, security and high availability service for all corporate applications regardless of where they are located with no dependency on the on-premises infrastructure.

Multi-forest – different connector groups for each forest

Most of the customers that deployed Application Proxy are using its single-sign-on (SSO) capabilities by performing Kerberos Constrained Delegation (KCD). To do that, the connector’s machines need to be joined to a domain that can delegate the users toward the application. KCD supports cross-forest capabilities but in a company that has distinct multi-forest environments with no trust between them, a single connector cannot be used for all forests.

In such a case, specific connectors can be deployed per forest and set to serve applications that were published to serve only the users of that specific forest. Each connector group will represent a different forest. While the tenant and most of the experience will be unified for all forests, users can be assigned to their forest applications using Azure AD groups.

Disaster Recovery sites

Another interesting appearance of the multi-datacenter case is the existence of disaster recovery sites. There are two different approaches you can take with disaster recovery (DR) sites depending on how these sites are implemented:

1. If your DR site is built in active-active mode where it is exactly like the main site and has the same networking and AD settings – Have the connectors on the DR site in the same connector group as the main site and let Azure AD detect failovers for you.

2. If your DR site is separate from the main site – Have a different connector group in the DR site and either have additional applications or manually divert the existing application to the DR connector group when needed.

Serving multiple companies from a single tenant

There are many different ways to implement a model in which a single service provider deploys and maintains Azure AD related services for multiple companies. One of them, which is suitable for small companies, is to have a single Azure AD tenant while the different companies have their own domain name and networks. This is also true for M&A scenarios and situations where a single IT division serves several companies for regulatory or business reasons.

In all these cases, connector groups help the admin segregate the connectors and applications into different groups.

Sample configurations

Here are few examples of configurations that you can implement using connector groups.

Default configuration – no use for connector groups

If you don’t use connector groups, your configuration would look like this:

This configuration is sufficient for small deployments and tests. It will also work well if your organization has a flat network topology.

Default configuration and an isolated network

This configuration is an evolution of the default one, in which there is a specific app that runs in an isolated network such as IaaS virtual network:

 Recommended configuration – several specific groups and a default group for idle

The recommended configuration for large and complex organizations is to have the default connector group as a group that doesn’t serve any applications and is used for idle or newly installed connectors. All applications are served using customized connector groups. This enables all the complexity of the scenarios described above.

In the example below, the company has two datacenters, A and B, with two connectors that serve each site. Each site has different applications that run on it.

Working with connector groups

Create connector groups

First, define additional connector groups. You can define as many groups as you want. Connector group creation is accomplished in the Azure portal. Select your directory and click Configure. Then, under Application Proxy, click Manage Connector Groups and create a new connector group:

Assign connectors to connector groups

Once the connector groups are created, move the connectors to the appropriate group. Connector group assignment is accomplished in the Azure portal. Select your directory and click Configure. Then, under Application Proxy, click Manage Connectors and assign each Connector to a group. Note that it might take the connectors up to 10 minutes to become active in the new group.

Assign applications to connector groups

The last step is to set each application to the connector group that will serve it. In the Azure portal, in your directory, select the Application and update the connector group setting. This change is immediately applied.