First published on CloudBlogs on Apr 21, 2017 by Microsoft Azure Active Directory Team
Hey everyone,
Ian Parramore here. Long time no post for us on these mailbags. You might be wondering what happened and why we didn’t have a post for almost 2 months. I can tell you who is to blame, Mark . Now that we got that out of the way. Today we’re going to dive in a little bit on some of the most common questions we’ve seen around the Azure AD Application Proxy.
For those of you not familiar with this awesome feature, Application Proxy provides single sign-on (SSO) and secure remote access for web applications hosted on-premises. These on-premises web applications can now be integrated with Azure AD, allowing your end users to access your on-premises applications the same way they access O365 and other SaaS apps integrated with Azure AD. You don't even need to change the network infrastructure or require a VPN to provide this solution for your users. To learn more about Application Proxy and how to get started, see our documentation .
Now let’s dig into some of your questions.
Question 1: I’m trying to setup Kerberos constrained delegation as discussed in this article but am struggling to understand the PrincipalsAllowedToDelegateToAccount method. Do you have some more insights you can share on this?
Answer 1: PrincipalsAllowedToDelegateToAccount is specifically used where the Connector servers are in a different domain to the web application service account and requires the use of Resource-based Constrained Delegation.
If the Connector servers and the web application service account are in the same domain then you can use the Active Directory Users and Computers to configure the delegation settings on each of the Connector machine accounts to allow them to delegate to the target SPN.
If the Connector servers and the web application service account are in different domains then we need to use Resource based delegation where the delegation permissions are configured on the target web server / web application service account. This is a relatively new method of Constrained Delegation introduced in Windows Server 2012 which supports cross-domain delegation by allowing the resource (web service) owner to control which machine/service accounts are allowed to delegate to it. There is no UI to assist with this configuration so we need to use PowerShell.
Each Azure AD Application Proxy Connector machine account needs to be granted permissions to delegate to the web application service account. When validating your configuration you can check the PrincipalsAllowedToDelegateToAccount setting using the following PowerShell:- Get-ADUser -Identity sharepointserviceaccount -Properties "PrincipalsAllowedToDelegateToAccount" The following output shows 2 machine accounts with permissions to delegate to the sharepointserviceaccount corresponding to our 2 Connector servers:
If one or more of your Connector servers do not have permissions to delegate to the target web application service account then you will see errors similar to the following:
In the article you'll see the following sample PowerShell commands: $connector= Get-ADComputer -Identity connectormachineaccount -server dc.connectordomain.com Set-ADUser -Identity sharepointserviceaccount -PrincipalsAllowedToDelegateToAccount $connector This is fine but will only set one Connector with delegation rights to the sharepointserviceaccount. If you only specify one of two Azure AD App Proxy connectors, access to the app will only succeed if traffic is routing through that connector. Where you have more than one Connector the first command would ideally look something like this: $connectors = Get-ADComputer -filter {name - like "* appproxyname *"} -server dc.connectordomain.com This command assumes the connectors have a similar name and that the wildcards will return more than one computer account. For example, in my environment I have two connectors, MSFTPM-AAP1 and MSFTPM-AAP2. So I would run: $connectors = Get-ADComputer -filter {name - like "* aap *"} -server dc.connectordomain.com This returns both servers and sets them in the $connectors variable. I can then run the second command to set the attribute appropriately on my resource server: Set-ADUser -Identity sharepointserviceaccount -PrincipalsAllowedToDelegateToAccount $connectors We can then use the following PowerShell to re-validate the setting: Get-ADUser -Identity sharepointserviceaccount -Properties "PrincipalsAllowedToDelegateToAccount" Note – the above examples are using Set-AdUser/Get-AdUser when getting/setting the PrincipalsAllowedToDelegateToAccount attribute. This is because the web application is running under a service account.
If the web application was running under a machine context we would need to use Set-AdComputer/Get-AdComputer. This may be relevant in a test environment with only a single web server but in a load balanced web server deployment we would expect the services to be running under a common service account. When populating the $connectors variable we will always use Get-AdComputer as we are specifically interested in the Connector machine accounts.
For further information about Kerberos Constrained Delegation and Resource-based Constrained Delegation please see the following whitepaper – http://aka.ms/kcdpaper
Question 2: Should I create a dedicated account to register the connector with the Azure AD Application Proxy?
Answer 2: There's no reason to. Any global admin account will work fine. The credentials entered during installation are not used after the registration process. Instead, a certificate is issued to the connector which will be used for authentication from that point forward. You can see this certificate in the personal store of the computer account:
Question 3: How can I monitor the performance of the Azure AD Application Proxy connector? Answer 3: There are Performance Monitor counters that are installed along with the connector. To view them do the following: 1. Start -> Type "Perfmon" -> Enter 2. Select Performance Monitor and click the green "+" icon: 
Question 4: Can only IIS-based apps be published? What about web apps running on non-Windows web servers? Does the connector have to be installed on a server with IIS installed?
Answer 4: Woah, this is a 3 for 1! · No there is no IIS requirement for apps that are published. · Yes you can publish web apps running on servers other than Windows Server. Having said that, you may or may not be able to use pre-authentication with a non-Windows Server depending on if the web server supports Negotiate (Kerberos authentication). The server the connector is installed on does not have to have IIS installed.
Question 5: Does the Azure AD App Proxy connector have to be on the same subnet as the resource? Answer 5: There is no requirement for the connector to be on the same subnet. It does however need name resolution to the resource as well as the necessary network connectivity (routing to the resource, ports open on the resource, etc.). If you want a more detailed discussion on connector location, please see our blog .
Question 6: I’ve published the App Proxy application, and I’m able to log in, but the application is not displaying as expected. Why isn’t it working?
Answer 6: If you’re able to login and the application isn’t displaying properly, there are two common possible causes. Please verify that all the pages referenced by the application are in the path you published. For example, we see many cases where the published path is “contoso/myapp/register/”, but the web page has references to resource under different paths e.g. “conotoso/myapp/style.css”. Because the path containing the style page has not been published, the application is unable to find it when loading. One way to check if this may be the problem is to look at a Fiddler trace or use the Network tab in the F12 Developer tools in Internet Explorer or Edge browsers to get an overview of the request/response pairs and associated HTTP status codes as you load a web page. You can use the output to identify if you are getting any 404 errors, and if so, whether the resources with the 404 errors are in the published path. In the above example, publishing “contoso/myapp/” instead of “contoso/myapp/register/” would solve the problem. Also, make sure to check if your application uses hard-coded internal links to either other applications or unpublished sites or, for its own internal namespace. This can be problematic where the internal and external FQDN’s in use are different and the web server generates links based on its internal name. Our general recommendation is to use the same internal and external FQDN and protocol (validate that both are the same – https is preferred, http is allowed) where possible to reduce the chance of any problems. For sites that contain links to other internal sites or applications, you would need to identify these and then ensure the relevant applications and sites are also published and available externally through Application Proxy. If these links are fully qualified, please use the custom domains feature to make sure these links will work. If not, look for an upcoming announcement in the coming months on some new Application Proxy capabilities in this area.!
Please check the Enterprise Mobilty and Security blog for announcements. You can use a tool such as Fiddler to review the traffic and identify request failures with a 404 status. You can also use the Network tab in the F12 Developer tools in Internet Explorer or Edge browsers to get an overview of the request/response pairs and associated HTTP status codes as you load a web page.
Thanks for reading. For any questions you can reach us at AskAzureADBlog@microsoft.com, the Microsoft Forums and on Twitter @AzureAD , @MarkMorow and @Alex_A_Simons
-Ian Parramore, Harshini Jayaram, and Mark Morowczynski