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:
User Principle Name: joe@contoso.com
Alternate User Principle Name: joed@contoso.local
Username part of User Principle Name: joe
Username part of Alternate User Principle Name: joed
On-premises SAM account name: depending on-prem domain controller configuration
The final result will allow Application Proxy to issue the right Kerberos ticket when accessing the backend application:
Troubleshooting identity delegation
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.
