Azure AD Application Proxy single-sign-on to non-Windows Applications


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.

 

Partial Delegated Identity

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”):

REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft AAD App Proxy Connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1

net stop WAPCSvc & net start WAPCSvc

 

This should be run on each machine that is running the Azure AD Application Proxy Connector.

After the preview is over, all Connectors will be updated to use SPNego as their backend authentication method.

 

Troubleshooting single-sign-on

Whenever there is an error in the single-sign-on process, it is logged into the Connector machine’s event log:

Examine the event details for additional explanation on each error. More information on these errors can be found in the troubleshooting guide.

See additional SSO troubleshooting tips here


Comments (4)

  1. Tschäidie says:

    Hi MeirM,

    thank you for this nice article!

    Just one question: is the same possible with Wep Application Proxy in Windows Server 2012 R2 – in other words: does WAP 2012 R2 only support KCD for applications using "Windows Internal Authenticaion" or does it also Support non-Windows Applications using Negotiate/SPNego?

    Thank you in advance for your response,
    Tschäidie.

  2. MeirM says:

    Thanks Tschäidie, this article is about Azure AD Application Proxy and does not apply to WAP in WS2012R2 or the next version of Windows Server. WAP is WIA only, no SPNego.

  3. MeirM says:

    Thanks Tschäidie, this article is about Azure AD Application Proxy and does not apply to WAP in WS2012R2 or the next version of Windows Server. WAP is WIA only, no SPNego.

    1. Alex Seigler says:

      In the “Step 3: Plan to Publish Applications using AD FS Preauthentication” document on TechNet, the following is stated:

      “Web Application Proxy adds the Kerberos ticket to the request as part of the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) token, and forwards the request to the backend server. The request contains the Kerberos ticket; therefore, the user is granted access to the application without the need for further authentication.”

      This kind of makes it seem like SPNego is supported for the on prem WAP. In practice, it appears that it does not, which really sucks.

Skip to main content