Azure AD Application Proxy can perform single-sign-on when cloud and on-prem identities are different


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:

  1. Have multiple domains internally (joe@us.contoso.com, joe@eu.contoso.com) and a single domain in the cloud (joe@contoso.com).

  2. Have non routable domain name internally (joe@contoso.usa) and a legal one in the cloud.

  3. Do not use domain names internally (joe)

  4. 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:

  1. User Principle Name: joe@contoso.com

  2. Alternate User Principle Name: joed@contoso.local

  3. Username part of User Principle Name: joe

  4. Username part of Alternate User Principle Name: joed

  5. 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.

 

 


Comments (2)

  1. Ruud Borst says:

    I’m a bit confused about the title, the authentication identity should be exactly the same, that’s the federated onpremise user. So if I’m right the only thing is Azure AD Application is now compatible with the alternate login method which can be utilized
    with ADFS and AADconnect. Am I right?

  2. Anonymous says:

    We are always working on adding more applications to the Azure Active Directory eco-systems, making Azure

Skip to main content