Kerberos Constrained Delegation (KCD) is a key technology in our application proxies. It enables single-sign-on (SSO) from the cloud to on-prem applications. With it, users can start work on Office 365, click on a link to on-prem app and continue working on this app with no password prompts. If the user is working from Azure AD Joined machine, she will not be prompted even once!
It is pretty straight forward to configure KCD but as anything good, KCD can also be complex – especially when your on-prem infrastructure is complicated. In order clarify the process and help you troubleshoot the complex scenarios, Mark Grimes from Microsoft Services have written a whitepaper that covers KCD from top to bottom. It includes introduction and explanation on the various technologies, step-by-step guides and easy to use checklists. It demystify topics like cross-forest and cross-domain federation and provide you tools to support your deployment.
Single sign on is a key element of Azure AD Application Proxy. It provides the best user experience: user signs in to the cloud, all security validations happen in the cloud (preauthentication) and then, when the request is sent to on-prem application, the App Proxy connector impersonates the user so the backend application thinks that this is a regular user coming from a domain-joined device.
This flow assumed that users have exactly the same identity in the cloud and on-prem.
We have improved Application Proxy to enable more flexibility! Now, the admin can configure, for each application, what identity should be used when performing single-sign-on for this app:
By default, all applications using the user principle name of the cloud user. The additional options are intended to be used for applications that need the alternate user principle name or identity that is not expressed as e-mail address.
Different on-prem and cloud identities
This capability allows many organization that have different on-prem and cloud identities to have single sign on from the cloud to on-prem apps without requiring the users to enter different usernames and passwords. This includes organizations that:
Have multiple domains internally (joe@us.contoso.com, joe@eu.contoso.com) and a single domain in the cloud (joe@contoso.com).
Have non routable domain name internally (joe@contoso.usa) and a legal one in the cloud.
Do not use domain names internally (joe)
Use Different aliases on-prem and in the cloud. E.g. joe-johns@contoso.com vs. joej@contoso.com
It will also help with applications that do not accept addresses in the form of e-mail address, which is a very common scenario for non-Windows backend servers.
Let’s examine for example an organization that has a non-routable domain name, such as contoso.local. When they moved to the cloud, they chose to use the e-mail address as the cloud identity:
The first step to get this configuration up and running is to configure AAD Connect settings so the main identity will be the e-mail address (mail). This is done as part of the customize process, by changing the user principle name field in the sync settings. Note that not all options will work if you are using AAD Connect versions before the general availability:
Note that these settings also determine how users login to Office365, Windows10 devices and other applications that use Azure AD as their identity store.
The last step is to tell Application Proxy to use the alternate login and not the main login when performing the identity delegation. This is done in the application configure page as shown above. Each application that requires it must be changed accordingly.
In this example, the different options on Application Proxy settings will yield the following results:
If there is an error in the SSO process it will appear in the connector machine event log as explained in the troubleshooting guide.
But, in some cases, the request will be successfully sent to the backend application while this application will reply in various other HTTP responses. Troubleshoot these cases could start by examining event number 24029 on the connector machine in the application proxy session event log. The user identity that was used for delegation will appear in the “user” field within the event details (“dean@contoso55.com” in the example below). To turn on session log, the “Show analytic and debug logs” option must be selected in the event viewer view menu.
Azure Active Directory Application Proxy enables making Remote Desktop deployments accessible for remote users. Such Remote Desktop deployments can reside on-premises or at private network such as IaaS deployments.
Remote Desktop protocol traffic can be published through Application Proxy as a pass-through proxy application. This solution solves the connectivity problem and provides basic security protection such as network buffering, hardened Internet frontend and DDoS protection.
Within the Remote Desktop deployment, the Remote Desktop Gateway is published so it will be able to convert the RPC over HTTPS traffic to RDP over UDP traffic. The clients will use their Remote Desktop clients (MSTSC.exe) to access Azure AD Application Proxy that would start a new HTTPS connection to the Remote Desktop Gateway using its connectors. That way, Remote Desktop Gateway will not be directly exposed to the Internet and all HTTPS requests will first be terminated in the cloud.
From the user’s point of view, they would simply trigger RDP traffic as they do today using files or other methods as long as they are configured with the Remote Desktop Gateway URL.
Publishing can be done either using the domain name provided by App Proxy (msappproxy.net) or using a custom domain name that is configured on Azure AD (e.g. rdg.contoso.com). If your client devices and RDP file are already configured with a Remote Desktop Gateway URL, you might want to use the same domain name and avoid the change. In this case the certificate that covers this domain should be provided to Application Proxy and its CRL should be accessible over the Internet.
If no Remote Desktop Gateway URL is configured, users or admins can specify it in the Remote Desktop clients (MSTSC):
If your organization is using Remote Desktop Web Access (RDWA) portal, you can also publish it using Azure AD Application Proxy. This portal can be published with preauthentication and signle-sign-on (SSO).
In this case the end users will be authenticated on Azure AD before accessing RDWA. If they are already authenticated on Azur AD, for example because they are using Office 365, they would not have to authenticate again for RDWA.
When the users starts the RDP session, they need to authenticate again over the RDP channel. This happens because SSO from RDWA to Remote Desktop Gateway is based on storing the end-user credentials on the client using ActiveX that is triggered from RDWA form-based authentication. When RDWA authentication is using Kerbros, no form-based authentication is presented and the RDWA to RDP SSO doesn’t work.
If RDWA SSO to the RDP traffic is needed or RDWA form-based authentication was heavily customized, it is possible to publish RDWA without preauthentication:
We are always working on adding more applications to the Azure Active Directory eco-systems, making Azure Active Directory the one-stop-shop for all the applications your users consume. It is a long journey to support more and more types of backend applications.
Today we are enabling single-sign-on (SSO) to non-Windows backend applications using Kerberos over SPNego. Support for this protocol is widespread and covers a large portion of mainstream applications running on platforms like Linux and Unix. This means that every application that has SSO via Kerberos for on-prem domain joined browsers will have SSO from the cloud.
The Kerberos delegation flow in Azure AD Application Proxy starts when Azure AD authenticates the user in the cloud. Once the request arrives on-premises, the Azure AD Application Proxy Connector issues a Kerberos ticket on behalf of the user by interacting with the local Active Directory. This process is referred to as Kerberos Constrained Delegation (KCD). In the next phase, a request is sent to the backend application with this Kerberos ticket. There are number of protocols that define how to send such requests. Most non-Windows servers expect Negotiate/SPNego that is now supported on Azure AD Application Proxy.
Non-Windows applications typically get user identity in the form of a username or SAM account name, not an email address (username@domain) . This is different than most Windows based systems that prefer a UPN, which is more conclusive and ensures no duplication cross domains.
For this reason, Application Proxy enables you to select which identity appears in the Kerberos ticket, per application, . Some of these options are suitable for systems that do not accept email address format.
If partial identity is used, and this identity might not be unique for all the domains or forests in your organization, you might want to publish these applications twice using two different connector groups, since each application has a different user audience, you can join its Connectors to a different domain.
Activating SPNego during the preview period
During the preview, use of SPNego will be off by default. In order to turn it on, run the following script from an elevated command prompt (“run as administrator”):
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 3rd 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 3rd 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:
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.
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:
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.
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:
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.
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.
As part of our continuous work to make Azure AD Application Proxy easier to deploy and more transparent we have created a whitepaper that provides full overview of all the capabilities around Application Proxy troubleshooting. The paper can be downloaded from here: http://aka.ms/proxytshootpaper
Even if you don't have immediate troubleshooting needs, we hope that the introduction parts will help you better understand the service. Section 3 of the paper provides detailed and complete description of all Application Proxy flows.
We heard feedback from customers that they need to be able to install the Azure AD Application Proxy connector without using the interactive login UI. It is now possible!
This capability is useful when you want to:
Install the connector on machines with no UI layer or when you cannot RDP to the machine.
Install and register many connectors at once.
Integrate the connector installation and registration as part of another procedure.
Create a standard server image that contains the connector bits but is not registered.
The procedure to perform this operation is:
Install the connector using a command line or standard silent MSI install. At this stage, you can make an image of the machine and replicate it. Installation does not involve any interaction with the on-line service.
The administrator acquires an offline token from Azure AD to use for the registration (we show you how to do this in the documentation).
On the connector machine, registration is performed using this token. This is when the connector establishes its connectivity to the service, registers the connector machine and creates a certificate to identify it. When this stage is done, the connector is ready to receive traffic. Alternatively, the admin can enter his credentials as part of the registration process which will acquire the token and register.
At this time, we would like to remind you that Forefront Threat Management Gateway (TMG) Web Protection Services will be discontinued on December 31st, 2015. There will be no further updates to this URL filtering/categorization service beyond this date.
The gateway product itself, Forefront Threat Management Gateway 2010, will remain under extended support until April 14, 2020.
We are happy to announce that one of our most commonly requested feature is now live and enabled for all tenants: the ability to have automatic redirection from HTTP to HTTPS. This feature is turned on by default for all organizations that are using App Proxy, no action is needed to make it work.
Redirection of HTTP URLs is needed for the following reasons:
Some applications use HTTP internally and HTTPS externally and they have embedded links that have HTTP. For example, if a SharePoint site uses HTTP internally, then users will receive email with HTTP links. If the user clicks on the links, access will fail.
Sometime, users manually type the application domain in the browser address bar. In this case, the browser sends the request using HTTP and not HTTPS.
The logic works as follows:
A device sends an HTTP request to a domain name that is published on App Proxy using HTTPS. E.g. http://sales.contoso.com. In the past, App Proxy rejected these requests.
Now, App Proxy replies to this request with a 307 redirection response to the same domain with HTTPS.
At this point App Proxy handles the request and performs authorization and authentication logic together with other Azure AD services. Once the request is authenticated and authorized, it is sent to the backend application.
Azure Active Directory Application Proxy enables making Remote Desktop deployments accessible for remote users. Such Remote Desktop deployments can reside on-premises or at private network such as IaaS deployments.
Remote Desktop protocol traffic can be published through Application Proxy as a pass-through proxy application. This solution solves the connectivity problem and provides basic security protection such as network buffering, hardened Internet frontend and DDoS protection.
Within the Remote Desktop deployment, the Remote Desktop Gateway is published so it will be able to convert the RPC over HTTPS traffic to RDP over UDP traffic. The clients will use their Remote Desktop clients (MSTSC.exe) to access Azure AD Application Proxy that would start a new HTTPS connection to the Remote Desktop Gateway using its connectors. That way, Remote Desktop Gateway will not be directly exposed to the Internet and all HTTPS requests will first be terminated in the cloud.
From the user’s point of view, they would simply trigger RDP traffic as they do today using files or other methods as long as they are configured with the Remote Desktop Gateway URL.
Publishing can be done either using the domain name provided by App Proxy (msappproxy.net) or using a custom domain name that is configured on Azure AD (e.g. rdg.contoso.com). If your client devices and RDP file are already configured with a Remote Desktop Gateway URL, you might want to use the same domain name and avoid the change. In this case the certificate that covers this domain should be provided to Application Proxy and its CRL should be accessible over the Internet.
If no Remote Desktop Gateway URL is configured, users or admins can specify it in the Remote Desktop clients (MSTSC):
If your organization is using Remote Desktop Web Access (RDWA) portal, you can also publish it using Azure AD Application Proxy. This portal can be published with preauthentication and signle-sign-on (SSO).
In this case the end users will be authenticated on Azure AD before accessing RDWA. If they are already authenticated on Azur AD, for example because they are using Office 365, they would not have to authenticate again for RDWA.
When the users starts the RDP session, they need to authenticate again over the RDP channel. This happens because SSO from RDWA to Remote Desktop Gateway is based on storing the end-user credentials on the client using ActiveX that is triggered from RDWA form-based authentication. When RDWA authentication is using Kerbros, no form-based authentication is presented and the RDWA to RDP SSO doesn’t work.
If RDWA SSO to the RDP traffic is needed or RDWA form-based authentication was heavily customized, it is possible to publish RDWA without preauthentication:
We are always working on adding more applications to the Azure Active Directory eco-systems, making Azure Active Directory the one-stop-shop for all the applications your users consume. It is a long journey to support more and more types of backend applications.
Today we are enabling single-sign-on (SSO) to non-Windows backend applications using Kerberos over SPNego. Support for this protocol is widespread and covers a large portion of mainstream applications running on platforms like Linux and Unix. This means that every application that has SSO via Kerberos for on-prem domain joined browsers will have SSO from the cloud.
The Kerberos delegation flow in Azure AD Application Proxy starts when Azure AD authenticates the user in the cloud. Once the request arrives on-premises, the Azure AD Application Proxy Connector issues a Kerberos ticket on behalf of the user by interacting with the local Active Directory. This process is referred to as Kerberos Constrained Delegation (KCD). In the next phase, a request is sent to the backend application with this Kerberos ticket. There are number of protocols that define how to send such requests. Most non-Windows servers expect Negotiate/SPNego that is now supported on Azure AD Application Proxy.
Non-Windows applications typically get user identity in the form of a username or SAM account name, not an email address (username@domain) . This is different than most Windows based systems that prefer a UPN, which is more conclusive and ensures no duplication cross domains.
For this reason, Application Proxy enables you to select which identity appears in the Kerberos ticket, per application, . Some of these options are suitable for systems that do not accept email address format.
If partial identity is used, and this identity might not be unique for all the domains or forests in your organization, you might want to publish these applications twice using two different connector groups, since each application has a different user audience, you can join its Connectors to a different domain.
Activating SPNego during the preview period
During the preview, use of SPNego will be off by default. In order to turn it on, run the following script from an elevated command prompt (“run as administrator”):
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 3rd 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 3rd 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:
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.
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:
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.
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:
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.
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.
As part of our continuous work to make Azure AD Application Proxy easier to deploy and more transparent we have created a whitepaper that provides full overview of all the capabilities around Application Proxy troubleshooting. The paper can be downloaded from here: http://aka.ms/proxytshootpaper
Even if you don't have immediate troubleshooting needs, we hope that the introduction parts will help you better understand the service. Section 3 of the paper provides detailed and complete description of all Application Proxy flows.
We heard feedback from customers that they need to be able to install the Azure AD Application Proxy connector without using the interactive login UI. It is now possible!
This capability is useful when you want to:
Install the connector on machines with no UI layer or when you cannot RDP to the machine.
Install and register many connectors at once.
Integrate the connector installation and registration as part of another procedure.
Create a standard server image that contains the connector bits but is not registered.
The procedure to perform this operation is:
Install the connector using a command line or standard silent MSI install. At this stage, you can make an image of the machine and replicate it. Installation does not involve any interaction with the on-line service.
The administrator acquires an offline token from Azure AD to use for the registration (we show you how to do this in the documentation).
On the connector machine, registration is performed using this token. This is when the connector establishes its connectivity to the service, registers the connector machine and creates a certificate to identify it. When this stage is done, the connector is ready to receive traffic. Alternatively, the admin can enter his credentials as part of the registration process which will acquire the token and register.
At this time, we would like to remind you that Forefront Threat Management Gateway (TMG) Web Protection Services will be discontinued on December 31st, 2015. There will be no further updates to this URL filtering/categorization service beyond this date.
The gateway product itself, Forefront Threat Management Gateway 2010, will remain under extended support until April 14, 2020.
We are happy to announce that one of our most commonly requested feature is now live and enabled for all tenants: the ability to have automatic redirection from HTTP to HTTPS. This feature is turned on by default for all organizations that are using App Proxy, no action is needed to make it work.
Redirection of HTTP URLs is needed for the following reasons:
Some applications use HTTP internally and HTTPS externally and they have embedded links that have HTTP. For example, if a SharePoint site uses HTTP internally, then users will receive email with HTTP links. If the user clicks on the links, access will fail.
Sometime, users manually type the application domain in the browser address bar. In this case, the browser sends the request using HTTP and not HTTPS.
The logic works as follows:
A device sends an HTTP request to a domain name that is published on App Proxy using HTTPS. E.g. http://sales.contoso.com. In the past, App Proxy rejected these requests.
Now, App Proxy replies to this request with a 307 redirection response to the same domain with HTTPS.
At this point App Proxy handles the request and performs authorization and authentication logic together with other Azure AD services. Once the request is authenticated and authorized, it is sent to the backend application.
As you may have noticed, things have been a little quiet on this blog for a few months. A combination of the holiday season and a little bit of a reorganization within the team is to blame for that. But I intend to rectify that going forward.
But let me start by introducing myself. I’m Girish Chander, one of the Product leads in the Azure Active Directory team. I focus on our Hybrid Identity Strategy within Azure AD; and Azure AD application proxy is a key element of that focus. Meir, who used to own the Application Proxy efforts from the product side, and who I’m sure you all are very familiar with, has moved on to a different role within Microsoft. <But he still keeps an eye out on this space and I never miss an opportunity to leverage his expertise here Image may be NSFW. Clik here to view.>.
So I’ll be taking over on this forum.
A bit more about me though….
I’ve been with Microsoft for over 15 years and in that time I’ve led various teams in different platforms and services in the Identity and Security space—ranging from Exchange server, SQL server, Windows and Cloud Identity.
I’ve been with the Azure Active Directory team since its inception focusing on various areas in my time here. I started in the core Directory team helping shape its growth into the largest enterprise directory in the cloud, supporting millions of organizations.
More recently, I was focused on helping organizations secure their enterprises in the Cloud and mobile world. My team was responsible for building and launching the Cloud App Discovery feature of Azure Active Directory. We also owned all of the Machine Learning based security reports that are available in Azure Active Directory. So if you’ve seen any of the blogs/presentations on these topics, you may have seen my name.
Over the past few months, I’ve shifted my focus to our Hybrid Identity Strategy and helping customers derive #HybridValueFaster. Specifically, to me that means helping customers get to the cloud faster and helping them derive value from the cloud quicker across their hybrid enterprise. As you can imagine, Azure AD app proxy has a special significance in this arena and offers compelling value.
I want to extend a HUGE ‘thank you’ to Meir, who along with others in the team started the app proxy effort.
And I look forward to ‘chatting’ more with all of you going forward.
In this post, I wanted to draw attention to a feature that we'd released and documented some time back, but hadn't really covered in this blog. I often talk about how the application proxy enables bringing 'new age' value (like MFA, conditional access controls and security reporting) to legacy applications–a super compelling value proposition. This feature that I cover below is about enabling 'new age' clients to talk to legacy applications.
Azure AD Application Proxy is widely used to publish browser applications such as SharePoint, Outlook Web Access, and custom line of business applications. Now it is also possible to use it to publish HTTP backend services that are consumed by non-browser applications.
There is a growing demand in organizations to create mobile applications on various platforms that target backend services that for a variety of reasons need to exist on-premises. Now you can do that with the rich application support we've released.
The Azure AD app proxy now supports pre-authentication using Azure AD bearer tokens that rich client applications can obtain and pass in standard HTTP Authorize headers. The recommended method to do this is for these client applications to use the Azure AD Authentication Library (or ADAL for short). ADAL takes care of all the authentication flows and is supported on a variety of different client environments. Learn more about it here.
All the details of how to point these rich client applications at published apps are available here. Every pre-authenticated proxy app can be accessed this way. No need to make any configuration change.
One of the big advantages of App Proxy is that if your backend service uses Kerberos, then Application Proxy can convert the Azure AD token to a Kerberos ticket. As a result, your legacy backend systems can be easily published without changing their authentication mechanisms. However, you can still have 'new age' rich clients integrate with our modern authentication system and get SSO all the way to the backend.
Go ahead, give it a try! And let us know if u have any feedback. I’d also love to hear the types of apps you’re integrating through this paradigm—so feel free to leave a comment in that regard. And as always, if you have any feedback/questions feel free to contact the team at: aadapfeedback@microsoft.com.
The topic for today's post was borne out of the number of queries we've received from customers asking about configuring the Azure AD app proxy connector to work with existing proxies on-premises. In many organizations, network policy does not allow internal machines to access the internet directly. Therefore, going through an on-premises proxy to connect to the Azure service is a requirement to make the scenario work.
This is a setup that many of you may have to grapple with. To that end, Ian Parramore on our team has been leading the effort to examine what it takes to make the connector traffic work in customer environments with proxies. And he’s written up a very detailed set of steps to consider.
Hope this unblocks you and speeds up your adoption of Azure AD App proxy. As always, if you have any questions or feedback, please contact us at aadapfeedback@microsoft.com.
BTW, am about to hop on a plane. I'm on my way to Hong Kong for the Azure Cloud Roadshow where I'll be talking about Azure AD and all its cool capabilities. If any of you are there, do drop by and say hi!
Thanks,
Girish Chander.
@chander_Girish
Hi everyone,
I’m Ian Parramore, one of the Senior Program Managers in the Azure Active Directory Go-To-Production team. We’ve been working with various customers to configure the Application Proxy connector to work with outbound proxy servers. In this article we’ll look at 2 main deployment scenarios:
-Configuring Connectors to bypass your on-premise outbound proxies
-Configuring Connectors to use an outbound proxy to access Azure AD Application Proxy
We’ll look at each of these scenarios in details, call out things to watch out for, as well as some troubleshooting tips and tricks.
But first some background:
The Connector install contains two services:
Microsoft AAD Application Proxy Connector—this is the core Connector service that establishes the connection with the proxy
Microsoft AAD Application Proxy Connector Updater—this is the updater service that is responsible for checking for and applying updates to the Connector service.
Both these services will need to be configured explicitly
The Core connector service uses Azure Service Bus to handle some of the underlying communications to the Azure AD Application Proxy service. Service Bus brings with it additional configuration requirements.
If you have an outbound proxy in your environment, ensure that the account doing the install is appropriately configured to use the outbound proxy. As the installer runs in the context of the user doing the install this can be done in Internet Explorer, Settings, Internet Options, Connections, LAN Settings and configuring the necessary proxy settings.
Please change ‘proxyserver’ and ‘8080’ to reflect your local proxy server name and the port it is listening on.
Bypassing outbound proxies
By default, the underlying OS components used by the Connector for making outbound requests automatically attempt to locate a proxy server on the network using WPAD (Web Proxy Auto-Discovery), if it is enabled in the environment.
This typically works by carrying out a DNS lookup for wpad.domainsuffix. If this resolves in DNS, an HTTP request will then be made to the IP address for wpad.dat which will be the proxy configuration script in your environment. The Connector will then use this to select an outbound proxy server.
However, connector traffic may still not be going through because of additional configuration needed on the proxy.
In the next section we’ll cover the configuration steps needed on the outbound proxy to make the traffic flow through it. But first, let’s cover how you can configure the connector to bypass your on-premises proxy to ensure it uses direct connectivity to the Azure services. This is the recommended way to go (as long as your network policy allows for it) as it means that you have one less configuration to maintain.
To disable outbound proxy usage for the connector, edit the C:\Program Files\Microsoft AAD App Proxy Connector\ApplicationProxyConnectorService.exe.config file and add the following section in bold:-
To ensure that the Connector updater service also bypasses the proxy, make a similar change to the ApplicationProxyConnectorUpdaterService.exe.config file located at C:\Program Files\Microsoft AAD App Proxy Connector Updater\ApplicationProxyConnectorUpdaterService.exe.config
Please ensure you take copies of the original files in the event that you need to revert to the default .config files.
Using the outbound proxy server
As mentioned above, in some customer environments, there is a requirement for all outbound traffic to go through an outbound proxy without exception. As a result, bypassing the proxy is not an option.
You can configure the connector traffic to go through the outbound proxy as shown below.
1)Configure the connector and Updater service to go through the outbound proxy
2)Configure the proxy settings to permit connections to the Azure AD App proxy service
Step 1: Configure the connector and related services to go through the outbound proxy
As covered above, if WPAD is enabled in the environment and configured appropriately, the connector will automatically discover the outbound proxy server and attempt to use it. However, you can explicitly configure the connector to go through an outbound proxy.
To do so, edit the C:\Program Files\Microsoft AAD App Proxy Connector\ApplicationProxyConnectorService.exe.config file and add the following section in bold.
Please change http://proxyserver:8080 to reflect your local proxy server name or IP address and the port it is listening on.
Configure the Connector updater service to use the proxy, by making a similar change to the file located at C:\Program Files\Microsoft AAD App Proxy Connector Updater\ApplicationProxyConnectorUpdaterService.exe.config
Step 2: Configure the Proxy to allow traffic from the Connector and related services to flow through
There are 4 aspects to consider at the outbound proxy
A.Proxy Outbound Rules
B.Proxy Authentication
C.Proxy Ports
D.SSL Inspection
2.A: Proxy outbound Rules
Allow access to the following endpoints for Connector service access.
*.msappproxy.net
*.servicebus.microsoft.net
Additionally, for initial registration, allow access to the following end points
login.windows.net
login.microsoftonline.com.
The underlying Service Bus control channels used by the connector service additionally require connectivity to specific IP addresses. (We are working with the Service Bus team to move to a fully FQDN instead). For now however, there are two options:
1)Allow the connector outbound access to all destinations
Note – the challenge with using the Azure Datacenter IP Ranges list is that this gets updated weekly so you would need to put a process in place to ensure your access rules are updated accordingly.
2.B: Proxy Authentication
Proxy authentication is not currently supported. Our current recommendation is to allow the Connector anonymous access to the Internet destinations.
2.C: Proxy ports
The Connector makes outbound SSL based connections using the CONNECT method. This essentially sets up a tunnel through the outbound proxy. Some proxy servers by default only allow outbound tunneling to standard SSL ports such as 443. If this is the case, the proxy server will need to be configured to allow tunneling to additional ports.
Configure the proxy server to allow tunneling to non-standard SSL ports – 8080, 9090, 9091 and 10100-10120.
Special service bus considerations
When Service Bus runs over HTTPS it uses port 443. However, by default, Service Bus will attempt direct TCP connections and will fall back to HTTPS only if direct connectivity fails.
To ensure that the Service Bus traffic is also sent through the outbound proxy server you need to ensure that the Connector cannot directly connect to the Azure services on ports 9350, 9352 and 5671.
2.D: SSL Inspection
Do not use SSL Inspection for the Connector traffic as it will cause issues for the Connector traffic.
And that’s it, now you should see all traffic flowing through the proxy. If you run into issues, the following troubleshooting steps should help.
Troubleshooting Connector Proxy problems and service connectivity issues
The single best way of identifying and troubleshooting Connector connectivity issues is to take a Network capture on the Connector service while starting the connector service. This can seem quite daunting so let’s look at quick tips on capturing and filtering Network traces.
You can use the tool of your choice such as Network Monitor, Wireshark or Message Analyzer. For the purposes of this blog I’m going to use Network Monitor 3.4 which you can download here – https://www.microsoft.com/en-us/download/details.aspx?id=4865
Examples and filters will be specific to Network Monitor but the principles can be applied in any analysis tool.
Taking a Capture using Network Monitor
To start a Network Monitor capture select New Capture and then the Start button
3.Start the Microsoft AAD Application Proxy Connector service
4.Stop the Network capture
Looking at the Connector to Proxy server requests
Now that you’ve got a Network Capture we can move on to the fun parts Image may be NSFW. Clik here to view.
The key to looking at the trace is understanding how to filter the capture to find what we’re interested in.
One of my favourite filter for this is as follows (where 8080 is the proxy service port):
(http.Request or http.Response) and tcp.port==8080
If you enter this filter in the Display Filter window and select Apply it will filter the captured traffic based on the filter.
The above filter will show just the HTTP requests and responses to/from the proxy port. For a Connector start-up where the Connector is configured to use a proxy server this would show something like this:-
We are specifically looking for the CONNECT requests which show we are talking to the proxy server and then that we get an HTTP OK (200) response back.
If you see other response codes such as 407 or 502 this would indicate that the proxy is requiring authentication or not allowing the traffic for some other reason at which point you should engage your proxy server support team.
Identifying failed TCP Connection attempts
The other common scenario we are interested in is when the Connector is trying to connect directly but this is failing.
Another one of my favorite Network Monitor filters which helps us easily identify this is:-
property.TCPSynRetransmit
Without going into too much detail a SYN packet is the first packet sent to establish a TCP connection. If this doesn’t get a response, then the SYN will be re-tried. The above filter allows us to see any re-transmitted SYN’s and we can then look to see if these correspond to any Connector related traffic.
The following example shows a failing connection attempt to the Service Bus port 9352
If you see something like the image above, it means firstly that the Connector is trying to talk directly to the Azure Service Bus service. If you expect the Connector to be making direct connections to the Azure services, then this is a clear indication of a network/firewall issue.
As noted above if you are configured to use a proxy server this may just be Service Bus attempting a direct TCP connection before switching to try connecting over HTTPS so please keep this in mind.
Network trace analysis is not everyone’s cup of tea but can be a hugely valuable tool to get some quick information about what is going on. If you are struggling with Connector connectivity issues though, please do feel free to raise a ticket with our support team who would be happy to assist with further troubleshooting.
Thanks,
Ian Parramore
Senior Program Manager, Azure Identity and Security