whitepaperdownload.microsoft.com › download › 3 › e › 3 › 3e335d… · web...

Troubleshooting the Azure Active Directory Application Proxy

October 2015

Prepared forMicrosoft

AuthorJohn Craddock, XTSeminars LtdIdentity and security [email protected]

Whitepaper

0

MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, our provision of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. The descriptions of other companies’ products in this document, if any, are provided only as a convenience to you. Any such references should not be considered an endorsement or support by Microsoft. Microsoft cannot guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products, please consult their respective manufacturers.© 2014 Microsoft Corporation. All rights reserved. Any use or distribution of these materials without express authorization of Microsoft Corp. is strictly prohibited.Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

iiWhitepaper, Troubleshooting the Azure Active Directory Application Proxy, Version 1.0, ReleasePrepared by John Craddock, XTSeminars Ltd

0

Table of ContentsList of Figures..................................................................................................6List of Tables..................................................................................................101 Purpose of this whitepaper......................................................................11

1.1 Naming........................................................................................................111.2 What is not covered.....................................................................................111.3 How to use this document for troubleshooting............................................11

2 Introduction..............................................................................................122.1 What is the AAD App Proxy?........................................................................122.2 Relationship of Azure AD and on-premises AD............................................12

2.2.1.................................No relationship between Azure AD and on-premises AD................................................................................................................................122.2.2.....On-premises AD users synchronized in to Azure AD and UPN used for identity...................................................................................................................122.2.3. .On-premises AD users synchronized in to Azure AD and an alternative attribute used for identity...................................................................................122.2.4................................................................................................................Federated SSO................................................................................................................................13

3 AAD App Proxy scenarios.........................................................................143.1 Passthrough (no preauthentication)............................................................163.2 Azure AD preauthentication.........................................................................17

3.2.1............................................................................................Preauthentication details................................................................................................................................18

3.3 Kerberos authentication to the internal application.....................................223.3.1................................................................................................Kerberos configuration................................................................................................................................233.3.2.................................................................................................Kerberos in a nutshell.................................................................................................................................243.3.3................................................Kerberos authentication via the AAD App Proxy................................................................................................................................273.3.4.............................................Alternative login ID and delegate login identities................................................................................................................................29

3.4 Publishing a claims-aware application.........................................................31

Whitepaper, Troubleshooting the Azure Active Directory Application Proxy, Version 1.0, ReleasePrepared by John Craddock, XTSeminars Ltd

0

3.4.1....................................................................................AD FS reply address (wreply)................................................................................................................................353.4.2......................................................SSO for published claims-aware applications................................................................................................................................38

3.5 Publishing a claims-aware application that trusts the Azure AD..................393.5.1...................................Adding a resource AD FS server for claims enrichment................................................................................................................................42

3.6 Claims-aware application trusting ADFS with Azure AD Federated SSO......444 Troubleshooting.......................................................................................49

4.1 Troubleshooting checklist and signposts.....................................................494.2 Publishing the application............................................................................52

4.2.1............................................................................................Application configuration................................................................................................................................524.2.2...................................................................Authorizing access through the proxy................................................................................................................................524.2.3............................................................Assigning a user to the proxy application................................................................................................................................554.2.4.....................................................................................Assigning a license to a user................................................................................................................................564.2.5.................................................................................................Verify published paths................................................................................................................................56

4.3 DNS name resolution...................................................................................594.3.1........................................................Internal FQDN for the published application................................................................................................................................594.3.2..............................................................External FQDN for published application................................................................................................................................604.3.3............................................................................................Verifying the AD FS URLs................................................................................................................................63

4.4 The AAD App Proxy Connector.....................................................................644.4.1..........................................................Checking the functioning of the connector................................................................................................................................654.4.2.........................................................................Checking the connector event logs................................................................................................................................67

4.5 Authentication to the application.................................................................694.5.1.......................................................................................................SSO Authentication................................................................................................................................694.5.2....................................................................................................NTLM Authentication................................................................................................................................69


0

4.5.3..............................................................................................Kerberos authentication................................................................................................................................71

4.6 Certificates..................................................................................................754.7 Host header translation...............................................................................764.8 Kerberos configuration.................................................................................77

4.8.1..........................................Configuring Kerberos delegation for the connector................................................................................................................................774.8.2..............................................................................................Internal Application SPN................................................................................................................................774.8.3...................................................................Changing the delegated login identity................................................................................................................................784.8.4...........................................................................................................Enabling SPNEGO................................................................................................................................784.8.5...........................................................................................Analyzing Kerberos traffic................................................................................................................................80

4.9 Tracing with Fiddler.....................................................................................914.9.1............................................................................................................Why use Fiddler?................................................................................................................................914.9.2.................................................................................................Preauthentication flow................................................................................................................................924.9.3..........................................................................................Claims aware applications................................................................................................................................97

4.10..................................................Azure AD object naming for published applications103


0

List of FiguresFigure 1: Publishing an application with no preauthentication.................................16Figure 2: Publishing an application with preauthentication......................................17Figure 3: Preauthentication flow...............................................................................19Figure 4: Example of JWT (tenant ID obfuscate).......................................................21Figure 5: Viewing the Azure AD service principle.....................................................21Figure 6: Kerberos authentication to the internal application..................................22Figure 7: Internal authentication method.................................................................23Figure 8: Enabling Kerberos delegation....................................................................24Figure 9: Accessing app1 using Kerberos.................................................................25Figure 10: Constrained delegation...........................................................................26Figure 11: Kerberos protocol transition with constrained delegation.......................28Figure 12: Publishing a claims-aware application.....................................................31Figure 13: Using two different IdPs...........................................................................32Figure 14: Authenticating to app1, where app1 trusts AD FS as the IdP..................33Figure 15: WS-Federation redirect to the AD FS server............................................34Figure 16: Web page including hidden form.............................................................35Figure 17: AD FS relying party endpoint...................................................................36Figure 18: POST back URL from hidden form in Step 12 of Figure 14.......................36Figure 19: Redirect URL – with app1 published as proxyapp1.xtseminars.com........37Figure 20: AAD App Proxy endpoint added as AD FS relying party endpoint............37Figure 21: POST back URL set via wreply parameter................................................38Figure 22: Publishing a claims-aware application that trusts the Azure AD..............39Figure 23: Authenticating to app1, where app1 trusts Azure AD as the IdP.............40Figure 24: Adding a resource AD FS server for claims enrichment...........................42Figure 25: Claims enrichment...................................................................................43Figure 26: Claims-aware application trusting ADFS with Azure AD Federated SSO. .44Figure 27: Preauthentication with Azure AD federated SSO – part 1........................45Figure 28: Preauthentication with Azure AD federated SSO – part 2........................46


0

Figure 29: Authentication to app1............................................................................47Figure 30: User not authorized for access................................................................53Figure 31: Error message - user not authorized for access......................................53Figure 32: Preauthentication flow from Section 3.2.1...............................................54Figure 33: Error message - user authorized, but not licensed..................................55Figure 34: Accessing the published site with Chrome..............................................57Figure 35: Accessing a site that is not published......................................................57Figure 36: Using the developer tools........................................................................58Figure 37: Resolving the FQDN using nslookup........................................................60Figure 38: CNAME required for the external FQDN...................................................61Figure 39: Resolving the FQDN with multiple aliases...............................................62Figure 40: Connector status.....................................................................................65Figure 41: Connector time out..................................................................................66Figure 42: Port 1010 blocked....................................................................................66Figure 43: The connector event logs........................................................................68Figure 44: Disable automatic logon..........................................................................70Figure 45: Kerberos session ticket to wia.xtseminars.com.......................................71Figure 46: NTLM authentication................................................................................72Figure 47: Kerberos authentication..........................................................................72Figure 48: Authentication via NTLM..........................................................................73Figure 49: Authentication via Kerberos....................................................................74Figure 50: IIS site bindings.......................................................................................76Figure 51: Properties of the computer object...........................................................77Figure 52: SPNEGO not enabled...............................................................................79Figure 53: SPNEGO enabled.....................................................................................80Figure 54: Kerberos traffic between the connector and the domain controller........81Figure 55: HTTP traffic to the internal application....................................................82Figure 56: AS-REQ for jill@xtseminars.co.uk............................................................83Figure 57: TGS-REQ for ticket to self (the connector addproxy1$)...........................83Figure 58: TGS-REP showing principal [email protected] 59: TGS-REQ for ticket to http/wia.xtseminars.com.......................................84


0

Figure 60: Scenario 1 - response after login as [email protected] 61: Scenario 1 - connector Admin event log..................................................85Figure 62: Network trace showing the account is disabled......................................85Figure 63: Scenario 2 - response after login as [email protected] 64: Scenario 2 - connector Admin event log..................................................86Figure 65: TGS-REQ for the Kerberos session ticket to the application is missing....87Figure 66: Scenario 3 - response after login as [email protected] 67: Scenario 3 - connector Admin event log..................................................88Figure 68: TGS-REQ using the wrong SPN................................................................88Figure 69: Scenario 4 - response after login as [email protected] 70: Scenario 4 - connector Admin event log..................................................89Figure 71: Invalid username.....................................................................................90Figure 72: Preauthentication flow (copy of Figure 3)................................................92Figure 73: Complete authentication trace................................................................93Figure 74: GET request & redirect response.............................................................94Figure 75: Decoded - OpenID Connect authentication string...................................95Figure 76: The user has completed authentication..................................................95Figure 77: Setting the AzureAppProxyAccessCookie................................................96Figure 78: Get request passed to application...........................................................97Figure 79: Authenticating to app1, where app1 trusts Azure AD as the IdP (copy of Figure 23).................................................................................................................98Figure 80: Application redirecting to Azure AD.........................................................99Figure 81: Decoded application authentication string..............................................99Figure 82: Azure Authentication cookies included..................................................100Figure 83: Viewing the claims................................................................................101Figure 84: Federation inspector..............................................................................101Figure 85: Authenticated to the application...........................................................102Figure 86: Publishing a claims-aware application...................................................103Figure 87: Creating the application in Azure..........................................................104Figure 88: Creating the AAD App Proxy..................................................................105Figure 89: Changing the external URL....................................................................105


0

Figure 90: Saving the changes...............................................................................106Figure 91: Before changing the external URL of the AAD App Proxy......................106Figure 92: Authentication to the application fails...................................................107Figure 93: After changing the external URL of the AAD App Proxy.........................108


0

List of TablesTable 1: AAD App Proxy endpoint and application endpoint behaviors....................15Table 2: No preauthentication..................................................................................16Table 3: AAD App Proxy preauthentication...............................................................18Table 4: Kerberos authentication to the internal application....................................23Table 5: Selecting the KCD identity..........................................................................30Table 6: Troubleshooting steps and signposts..........................................................50Table 7: Required outbound ports for the connector................................................64Table 8: Certificate troubleshooting tips..................................................................75


0

1 Purpose of this whitepaperThe objective of this whitepaper is to provide you with background and technical details to a sufficient depth for you to troubleshoot the Azure AD Application Proxy when used in a range of different scenarios. Section 3 of this whitepaper will give you detailed background of the different scenarios in which the Azure AD Application Proxy can be deployed. Section 4 provides you with tools and technical details that will allow you to succinctly troubleshoot problems.

1.1 NamingThroughout the rest of this document the Azure AD Application Proxy is referred to as the AAD App Proxy.

1.2 What is not coveredThe scenarios in which the AAD App Proxy can be used are only limited by your imagination, consequently this whitepaper cannot cover all the details of Azure AD, AD FS, configuring claims-aware applications and more. However the tools and techniques that you will learn will help you troubleshoot most scenarios.

1.3 How to use this document for troubleshootingAs there are potentially so many scenarios and configurations, it is not possible to provide troubleshooting flowcharts that will be useful in every situation. Consequently the approach taken in this whitepaper has been to provide technical details of the different scenarios in Section 3 and then Section 4 has a detailed table showing all the steps needed to completely validate a system regardless of the implemented scenario. Not all of the steps in the table will apply to your situation, but where they do, you need to verify the appropriate functionality and remediate if necessary. For many of the steps, sign-posts are provided to additional sections which show you how to troubleshoot the issues.The first time you use this guide, read Section 3 and focus on the sections that are appropriate to your scenario and then choose the appropriate steps from Table 6 in Section 4.


0

Once you are more familiar with troubleshooting, just dip in to the appropriate sections as necessary.


0

2 Introduction

2.1 What is the AAD App Proxy?The Microsoft AAD App Proxy lets you publish applications, such as SharePoint sites, Outlook Web Access and HTTP/S apps, inside your private network and provides secure access to users outside your network. Employees can log into your apps from home, on their own devices and authenticate through this cloud-based proxy. AAD App Proxy is a feature that is available only if you upgraded to the Premium or Basic edition of Azure AD.

2.2 Relationship of Azure AD and on-premises ADThe AAD App Proxy can publish your application and require that the user is authenticated with the Azure AD before access is allowed through the proxy to the application. There are a number of options for linking the Azure AD and your on-premises AD.

2.2.1 No relationship between Azure AD and on-premises ADThe Azure AD can be populated with users that have no relationship with your on-premises AD, you may not even have an on-premises AD. User will preauthenticate using an Azure AD identity and password.

2.2.2 On-premises AD users synchronized in to Azure AD and UPN used for identity

Users from the on-premises AD are synchronized into the Azure AD, the user’s password can also be synchronized. The user logs in with the same username (UPN) and password for both the Azure AD and on-premises. This is not single-sign-on but same-sign-on.

2.2.3 On-premises AD users synchronized in to Azure AD and an alternative attribute used for identity

The user is identified by the UPN in the Azure AD and it must be unique and use a routable suffix. An on-premises suffix that uses .local or example.com or that is not registered to the Azure AD tenant, cannot be used as the Azure UPN. To mitigate the situation where a non-routable suffix has been used, an alternative on-premises AD user attribute can be used as the login name for Azure AD. It is common to use the mail attribute as the alternative login ID and the value in this attribute is


0

replicated to the Azure AD UPN attribute, the user’s password can also be synchronized. In this scenario, a user logs in to Azure AD using their email address and logs in to the on-premises AD using their domain\user name combo or the on-premises AD UPN.

2.2.4 Federated SSOA domain (UPN suffix) that has been synchronized with Azure AD can be configured as federated. When a user attempts to login to Azure AD and they are a member of a federated domain, Azure AD will redirect the user to their on-premises AD FS farm. They are then authenticated against their on-premises AD. This provides SSO for both Azure AD and on-premises AD.


0

3 AAD App Proxy scenariosTable 1 below shows the key options for the behaviors between the published AAD App Proxy endpoint and the application endpoint.The main differences between all of the scenarios depicted in the guide is how access to the AAD App Proxy and application endpoints is authenticated and authorized. The details of the authentication and authorization options are given in each of the appropriate sections.


0

Table 1: AAD App Proxy endpoint and application endpoint behaviors

AAD App Proxy endpoint Connector Application endpoint

Protocol1 HTTP or HTTPS <-------------> HTTP or HTTPS

URL2 http://hostname.msappproxy.net3

https://hostname.msappproxy.net3,4

http://custom FQDNhttps://custom FQDN5

<------------->http: custom URLhttps: custom URLThe URL6 can contain a hostname, IP address or FQDN

Authentication

None or Authentication against Azure

AD tenant7<------------->

Anonymous, forms, basic digest, NTLM8, Kerberos9 or claims

Host header translation

External FQDN <- Optional10,11 ->

Internal FQDN

Notes:1. Protocol choices will depend on authentication methods used for the AAD App Proxy and internal

application. For instance preauthentication will require HTTPS on the AAD App Proxy endpoint and an application using claims authentication will require HTTPS for all endpoints.

2. All published URLs can include a path. The external and internal paths must be the same.3. When the URL is stemmed on msappproxy.net the hostname is automatically derived from a

combination of the name used during the creation of the AAD App Proxy application and the tenant name. (For example: app1proxy-tenantname).

4. SSL for the msapproxy.net domain is automatically supported through a Microsoft certificate.5. SSL for custom domains requires an appropriate certificate to be uploaded to Azure AD.6. The internal port to be used can be defined as part of the URL. For example http://server12:8012.7. If the Azure tenant is configured for federated SSO the user can be authenticated against another

identity provider. 8. Although NTLM can be used through the AAD App Proxy it should never be used except for down-level

compatibility. Never use it without a full security assessment and review.9. Kerberos authentication requires the on-premises AAD App Proxy connector to be domain joined and

configured for Kerberos Constrained Delegation 10. The default is for translation it to be enabled.11. Host header translation will translate the FQDN but not the path. If you publish an internal path the

external path must be the same. (For example: https://app1.example.com/app/pages/ and https://app1proxy.msappproxy.net/app/pages/).


0

3.1 Passthrough (no preauthentication)

Figure 1: Publishing an application with no preauthentication

In this scenario depicted in Figure 1. App1 is published to the external network with no preauthentication. The user identity is not verified on Azure AD before the request is forwarded to on-premises resource, however the service terminates all traffic in the cloud and establishes a new connection to the on-premises resource via the connector. Refer to Table 2 below for details of the protocol, authentication and authorization options. For other details see Table 1: AAD App Proxy endpoint and application endpoint behaviors.

Table 2: No preauthentication


Protocol HTTP or HTTPS1 <-------------> HTTP or HTTPS1

Authentication

None<------------->

Anonymous, forms, basic digest, NTLM2 or

claims3

Authorization

None4 (Any user can access the

endpoint)

<-------------> Controlled by application

Notes:1. Claims-aware applications will require HTTPS. Basic and Forms application should use HTTPS to avoid

passing the user’s context (name/password) in the clear.2. Although NTLM can be used through the AAD App Proxy it should never be used except for down-level

compatibility. Never use it without a full security assessment and review.3. For claims authentication the end user’s computer will need to be able to access the appropriate

security token service (STS). If you are using AD FS on-premises you will need to deploy the Web Application Proxy for AD FS. You cannot use the AAD App Proxy as a proxy to AD FS.

4. The user must have a Basic or Premium license, usage can be monitored and enforced if necessary.


0

A typical usage for this type of publishing is for providing access to web published CRL distribution points and the Network Device Enrollment Service (NDES) for Microsoft Intune.

3.2 Azure AD preauthentication

Figure 2: Publishing an application with preauthentication

This scenario is depicted in Figure 2, app1 is published to the external network with preauthentication at the AAD App Proxy. Refer to Table 3 below for details of the protocol, authentication and authorization options. For other details see Table 1: AAD App Proxy endpoint and application endpoint behaviors.


0

Table 3: AAD App Proxy preauthentication


Protocol HTTPS <-------------> HTTP or HTTPS1

Authentication2

Authentication with Azure AD tenant3 <------------->

Anonymous, forms, basic digest, NTLM or

claims4

Authorization

User must have a Basic or Premium Azure AD license and be assigned5 for access to the

AAD App Proxy application endpoint


Notes:1. Claims-aware applications will require HTTPS. Basic and Forms application should use HTTPS to avoid

passing the user’s context (name/password) in the clear.2. SSO between the AAD App Proxy and the application is not supported for forms, basic digest or NTLM 3. If the Azure tenant is configured for federated SSO the user can be authenticated with another identity

provider. See Section 3.6 which shows Azure federated identity in action.4. Claims authentication when using AAD App Proxy preauthentication is detailed in Sections 3.4, 3.5 and

3.6. 5. A user can be assigned directly to an application or indirectly via groups. Groups may be simple groups,

self-service groups or dynamic groups (based on profile properties).

3.2.1 Preauthentication detailsThe swim lanes as depicted in Figure 3, show the protocol flow when a user attempts to access a website protected by the AAD App Proxy with preauthentication. For in-depth analysis of the protocol flow see the troubleshooting Section 4.In Figure 3 it is assumed that the user has not already authenticated to any websites published by the proxy.


0

Figure 3: Preauthentication flow

Protocol flow:1. Get request to published application. The AAD App Proxy checks for a valid

AzureAppProxyAccessCookie.2. If there is no valid cookie the user’s browser is redirected to Azure AD for

authentication. The redirect URL includes details of the Azure AD endpoint and the authentication method to be used.

a. The authentication method is Open ID Connect using an OAuth 2.0 code grant flow.

3. Azure AD requests the user’s name and password and authenticates the user.a. The interaction with Azure AD is slightly more complex. Based on the

user’s domain Azure AD willi. Check if the user is configured to use federated SSO, if this is

configured, redirect the user to their corporate STS where they will be required to login. For more details of this scenario see Section 3.6.

ii. If the user is not configured for federated SSO, display the Azure AD tenant branding page and prompt for login

4. Azure AD replies with a redirect to the application, an OAuth 2.0 code is appended to the reply URL. The code identifies that the user has been authenticated and can be used by the AAD App Proxy to obtain an access


0

token. Azure AD also returns a cookie that identifies that the user has been authenticated by Azure AD.

5. The user’s browser redirects to the application with the code in the URL.6. The AAD App Proxy sends a request to Azure AD to convert the code to an

access token. The token is in JWT format and includes the UPN of the user. Although not visible to the user, for background information, see Figure 4 for an example of a JWT.

7. The AAD App Proxy received the JWT from Azure AD and validates the token. The AAD App Proxy checks that the user is authorized for access to the application.

a. The user must be assigned for access through the AAD App Proxy to the application. A user can be assigned directly to an application or indirectly via groups. Groups may be simple groups, self-service groups or dynamic groups (based on profile properties).

b. The user must have an Azure AD Basic or Premium license.8. If the user is authenticated and authorized, the AAD App Proxy responds with

a redirect to the application and sets an AzureAppProxyAccessCookie cookie. 9. The user’s browser redirects to the app and sends the cookie. The cookie

identifies that the user is authenticated for access through the AAD App Proxy and the request is forwarded to the application.

10.If anonymous access is allowed to the application, the page is rendered.a. If authenticated access is required, this is now implemented using

whatever method has been chosen. More details later.

This interaction between the browser, AAD App Proxy, Azure AD and the application is complex dance. However the federation dance only happens the first time you access the application, subsequent HTTPS requests will include the AzureAppProxyAccessCookie and the AAD App Proxy will simply forward the request to the application. If the user accesses another application protected by the AAD App Proxy, when the user is redirected to authenticate to Azure AD, the Azure authentication cookie is passed identifying that the user is already authenticated. Provided the same authentication policies are configured for each application the user has SSO authentication through the AAD App Proxy to all published applications. As an example of an exception to this, one application may require stricter authentication such as MFA. Once the user is authenticated a check is made to see if the user is authorized before the request is forwarded through the AAD App Proxy to the application. Authorization through the AAD App Proxy is configured for each application.


0

Example JWT

{ "typ": "JWT", "alg": "RS256", "x5t": "MnC_VZcATfM5pOYiJHMba9goEKY", "kid": "MnC_VZcATfM5pOYiJHMba9goEKY"}{ "aud": "05020220-832c-47a1-b833-85716ab86e0a", "iss": "https://sts.windows.net/ab0****-****-****-a868-********/", "iat": 1435128748, "nbf": 1435128748, "exp": 1435132648, "ver": "1.0", "tid": "ab0****-****-****-a868-********", "oid": "9838bd80-6c40-4f9e-bfee-131d3d9e7df1", "upn": "[email protected]", "sub": "YqGvvSuawWNp5bnLoWvCmj1cwRC2Awdh23sohdCPnc8", "given_name": "Jill", "name": "Jill", "amr": [ "pwd" ], "unique_name": "[email protected]", "onprem_sid": "S-1-5-21-1944609542-1844729179-2744045708-6105", "nonce": "fee424be-270f-4c12-b9e4-1407ac3fd04f", "pwd_exp": "6091062"}

Figure 4: Example of JWT (tenant ID obfuscate)

There are three parts of a JWT: header, body and signature. As can be seen in Figure 4, the UPN of the user is contained in the body of the JWT. The audience (“aud”) for the token is the Azure AD MsolServicePrincipal that represents the published application. You can see the service principals using the Azure AD PowerShell command Get-MsolServicePrincipal, Figure 5.ExtensionData : System.Runtime.Serialization.ExtensionDataObjectAccountEnabled : TrueAddresses : {Microsoft.Online.Administration.RedirectUri}AppPrincipalId : 05020220-832c-47a1-b833-85716ab86e0aDisplayName : WindowsAuthProxyObjectId : 19a28874-725f-4d16-9f9c-dd9c3aefc987ServicePrincipalNames : {https://claimsapp-xtsad.msappproxy.net/windowsauth/, 05020220-832c-47a1-b833-85716ab86e0a}TrustedForDelegation : False

Figure 5: Viewing the Azure AD service principle


0

3.3 Kerberos authentication to the internal application

Figure 6: Kerberos authentication to the internal application

In this scenario, depicted in Figure 6, the AAD App Proxy preauthenticates the user and then uses Kerberos constrained delegation (KCD) to obtain a Kerberos token to authenticate to the application with the user’s identity. Refer to Table 4 below for details of the protocol, authentication and authorization options. For other details see Table 1: AAD App Proxy endpoint and application endpoint behaviors.


0

Table 4: Kerberos authentication to the internal application


Protocol HTTPS <-------------> HTTP or HTTPS

Authentication

Authentication against Azure AD tenant1

<-------------> Kerberos

Authorization

User must have a Basic or Premium Azure AD license and be assigned2 for access to the

AAD App Proxy endpoint


Notes:1. If the Azure tenant is configured for federated SSO the user can be authenticated against another

identity provider. See Section 3.6 which show Azure federated identity in action.2. A user can be assigned directly to an application or indirectly via groups. Groups may be simple groups,

self-service groups or dynamic groups (based on profile properties).

3.3.1 Kerberos configuration For Kerberos authentication to work to the internal application, the AAD App Proxy must be configured to use Integrated Windows Authentication as the internal authentication method, see Figure 7.

Figure 7: Internal authentication method

In addition to configuring the AAD App Proxy in Azure, the server(s) running the connector must be configured for Kerberos constrained delegation with protocol transition. This configuration is managed through the on-premises Active Directory computer object properties for each of the servers running a connector. Figure 8.


0

Figure 8: Enabling Kerberos delegation

3.3.2 Kerberos in a nutshell. Before getting onto the details of the AAD App Proxy and how it uses KCD, let’s sum up how the Kerberos authentication protocol works. In Figure 9 you can see, the initial user authentication followed by the user authenticating against the app1 web service.

Note: Web services are used in the illustrations show in this whitepaper. Regardless of the backend protocol (cifs, ldap, http, sql, etc) the Kerberos protocol flows are the similar. The only variation will be in how the session ticket is passed to the target application.


0

Figure 9: Accessing app1 using Kerberos

Protocol flow:1. An AS-REQ is sent to the KDC to request user authentication.2. The KDC returns an error as it requires the AS-REQ to be preauthenticated.

a. Preauthentication is performed by encrypting the client time with the user’s key.

b. The requirement for preauthentication can be disabled in the AD.3. An AS-REQ with preauthentication is sent to the KDC.4. The KDC validates the timestamp and returns a Ticket Granting Ticket (TGT).

a. The TGT is used to identify the user in all subsequent requests to the KDC.

5. A TGS-REQ is sent requesting a Session Ticket (ST) to app1, the TGT is included in the request to identify the user.

a. App1 is identified by a Service Principal Name (SPN).6. The KDC returns a ST (ST1) which is valid between the user and app1.7. An HTTP request is sent to app1 with ST1 encoded in the HTTP header. 8. APP1 validates the ST and renders the page.

As can be seen in the diagram the Kerberos tokens are cached on the client computer and can be used for subsequent interactions.


0

Constrained delegation within a domain

Cross-domain and cross–forest delegation were introduced in Server 2012, for more details see this whitepaper.

Constrained delegation allows a frontend service to access a backend service using the identity of a user that has already authenticated to the frontend service. Constrained delegation makes use of the Kerberos extension Service-for-User-to-Proxy (S4U2Proxy). This allows the service to request a session ticket to a backend system from a KDC by presenting the ST that originally authenticated the user to the service, see Figure 10.

Figure 10: Constrained delegation

The protocol flow follows on from step 7 in Figure 9: Accessing app1 using Kerberos. App1 now becomes the delegator:

7. The user authenticates to the delegator (app1) using ST1 (repeated from Figure 9).

8. The delegator (app1) uses ST1 to request a ST to app29. The KDC checks the request and issues ST2 for authentication to app2 using

the user’s identity.a. The KDC will only issue the session ticket if the request is for a service

in the Allowed To Delegate To (A2D2) list.b. A session ticket will not be issued if the user account is marked as

“Account is sensitive and cannot be delegated”.


http://aka.ms/KCDPaper

0

10.The delegator (app1) sends a HTTP request to app2 with ST2 encoded in the header

11.APP2 validates the ST and returns the results.

3.3.3 Kerberos authentication via the AAD App ProxyUsing constrained delegation the Kerberos Session Ticket (ST) that authenticates the user to the frontend service (delegator) is used to identify the user in the request for an ST to the backend server. The challenge with the AAD App Proxy (frontend service - delegator) is that the user authenticates to it via Azure AD and there is no Kerberos ST. As part of the authentication process the AAD App Proxy will receive a JWT as shown in step 7 or the preauthentication flow (Figure 3). The JWT includes the user’s UPN, see Figure 4.Although Kerberos authentication to the AAD App Proxy is not used, because we have the UPN of the user, Kerberos protocol transition can be used to switch from a non-Kerberos authentication mechanism to Kerberos. Delegation can then be used to backend systems. The use of protocol transition relies on the Kerberos extension Service-for-User-to-Self (S4U2Self), this allows a service to obtain a session ticket to itself with the identity of ANY user.In our example the AAD App Proxy can obtain an ST to itself with the identity of [email protected], the UPN in the JWT (Figure 4). This ST is as though Jill authenticated to the AAD App Proxy using Kerberos. The ST can then be used to request an ST to the internal app with Jill’s identity.This process relies on the fact that the UPN representing the user in Azure is also the UPN of the on-premises AD user. If an alternative login ID is used this will not be the case, see Section 3.3.4.Figure 11 illustrates the protocol flow after the user has been preauthenticated to the AAD App Proxy and authorized to access app1 through the AAD App Proxy. As proof of authentication and authorization an AzureAppProxyAccessCookie will have been set for access to the external application URL.


0

Figure 11: Kerberos protocol transition with constrained delegation

The protocol flow follows on from step 8 in Figure 3: Preauthentication flow.9. As the result of a redirect, an HTTP request is sent to app1 with the

AzureAppProxyAccessCookie set.10.To test the validity of the user account, an AS-REQ to authenticate the user

represented by the UPN, is sent to the KDC.a. The user can never be authenticated to the KDC as the user’s

password is not available, however the reply to the AS-REQ will indicate if the user’s account exists and is active.

11.An AS-REP indicating that preauthentication is required confirms that the account exists and is active.

a. Other error messages will indicate the account doesn’t exist or is disabled.

12.A TGS-REQ is made to the KDC to obtain an ST to the AAD App Proxy (self) using the user’s identity.

13.The session ticket to the AAD App Proxy with the user’s identity is returned and cached on the AAD App Proxy. This is shown as ST1.

14.A TGS-REQ is made to the KDC to obtain an ST to app1 with the user’s identity. ST1 is passed with the request.

15.The session ticket to app1 with the user’s identity is returned and cached on the AAD App Proxy. This is shown as ST2.


0

16.The AAD App Proxy redirects the user to the application.17.As the result of the redirect, an HTTP request is sent to app1 with the

AzureAppProxyAccessCookie set.18.The AAD App Proxy creates an HTTP connection to app1 and encodes ST2

into the HTTP header.19.The application validates the Kerberos token and returns the results.

In the troubleshooting section you will learn how to capture and view the Kerberos traffic.

3.3.4 Alternative login ID and delegate login identitiesThe user’s login name for Azure AD is stored in the UPN attribute. When synchronizing users from an on-premises AD in some instances it is not possible to use the user’s UPN from the on-premises AD. This could be due to the on-premises UPN using a non-routable domain such as .local. To avoid the need to update all the on-premises UPNs, the concept of an alternative login ID was introduced. This allowed an alternate on-premises AD attribute, such as the mail attribute, to be used to store the login name, this is synchronized to the Azure AD UPN attribute. The alternative attribute value can then be used to login.

The latest Azure AD Connect synchronization engine simplifies using an alternative login ID. In addition to managing the synchronization of an alternative attribute it also synchronizes the on-premises UPN and SAM account name to the Azure AD onPremisesUserPrincipalName and onPremisesSamAccountName attributes. These attributes are required as part of the AAD App Proxy configuration if an alternative login ID is being used.

With KCD the Kerberos ticket request must be made using the on-premises AD identity. If an alternative login ID has been used the Azure AD and on-premises AD identities will be different. For KCD to use the correct identity the AAD App Proxy will need to retrieve the appropriate identity from either the onPremisesUserPrincipalName or onPremisesSamAccountName Azure AD attributes. The attribute to be used is configured through the AAD App Proxy configuration UI. The options for selecting which attribute should be used for the KCD identity is shown in Table 5. For some Kerberos implementations it may be necessary to request the token using the username part of the UPN, this option can also be selected.


0

Table 5: Selecting the KCD identity

The KCD ID based on Delegated login identity (name shown in UI)

The Azure AD UPN User principal name

The on-premises UPN On-premises user principal name

The on-premises SAM account name On-premises SAM account name

The username part of the Azure AD UPN Username part of user principal name

The username part of the on-premises UPN Username part of on-premises user principal name


0

3.4 Publishing a claims-aware application

Figure 12: Publishing a claims-aware application

A claims-aware application can be published with preauthentication at the AAD App Proxy. Although during the preauthentication process the user authenticates to Azure AD and a JWT is produced containing claims about the user, none of that information is passed between the AAD App Proxy and the application. The application is responsible for implementing its own authentication process before allowing access to the user.A claims-aware application trusts a Security Token Service (STS) to provide proof of authentication of a user. The STS will provide proof of authentication in the form of a security token which contains claims about the user and is digitally signed. The application is configured to trust the digital signature. The format of the token will depend on the authentication protocol but will normally either be in SAML or JWT format.If the AAD App Proxy and the application trust different identity provides the use will be prompted to authenticate to Azure AD and then prompted to authenticate to the identity provider that is trusted by the claims-aware application, two logins will be required. This scenario is depicted in Figure 13 with the AAD App Proxy authenticating via Azure AD and the claims-aware application authenticating to the on-premises AD via AD FS.


0

Note: For this scenario to work for external users, the external users must be able to access the on-premises AD FS server via the Server 2012 R2 AD FS Web Application Proxy. Today the AAD App Proxy does not support the publishing of AD FS.

Figure 13: Using two different IdPs

The protocol flow is illustrated in Figure 14.Figure 14 shows the protocol flow for authentication to the application. In this illustration WS-Federation is shown but a similar flow would occur for other federated protocols. Figure 14 starts from step 9 after the preauthentication to the AAD App Proxy depicted in Figure 3.


0

Figure 14: Authenticating to app1, where app1 trusts AD FS as the IdP


AzureAppProxyAccessCookie set. The AAD App Proxy accepts the cookie as proof that the user has been preauthenticated and passes the request to the application.

10.The user has not previously authenticated to app1, consequently app1 redirects the user to the AD FS server that it trusts. The WS-Federation authentication string is included as part of the redirect URL. The redirect URL is shown in Figure 15.

a. wtrealm identifies the application (relying party) to AD FS.b. wctx is set by the application and returned, unchanged, to application

with the security token. The wctx parameter is used by the application to match the reply to the original request.

c. wct is a time stamp.d. wreply is appended by the AAD App Proxy. See Section 3.4.1 for more

details.11.The AD FS receives the request and goes through the process of

authenticating the user. The authentication flow will depend on the AD FS configuration, which is outside the scope of this document, but may include:

a. Home realm discovery if the AD FS server trusts more than one claims provider.

b. Forms authentication.


0

c. Multi-factor authentication.12.After the user is authenticated, the AD FS server will create a security token

based on the configured claim rules. The token will be returned in a web page that contains a hidden form that automatically (providing scripting is enabled) POSTs the form, including the token, to app1. See Figure 16. Along with returning the web page, the AD FS server sets a number of cookies which includes cookies identifying that the user is authenticated to the AD FS server.

13.The hidden form containing the security token is POSTed to the application. Included in the POST is the AzureAppProxyAccessCookie which allows access through the AAD App Proxy.

14.App1 validates the token and returns a redirect back to the application. Included in the redirect are FedAuth cookies that indicate the user is authenticated to the application.

15.A GET request is sent to the application. The request includes the AzureAppProxyAccessCookie and the FedAuth cookies. The application now identifies that the user is authenticated and renders the appropriate page.

https://adfs.xtseminars.com/adfs/ls/?wa=wsignin1.0&wtrealm=http://app1.xtseminars.com&wctx=rm=0&id=passive&ru=%2F&wct=2015-07-21T16:12:31Z&wreply=https://app1.xtseminars.com/?ClaimAwareAAD5F09D25F-4423-4C2C-AE2A-2B92511B0671=c5d2aea5-527f-4abf-b898-630756f621af

Figure 15: WS-Federation redirect to the AD FS server


0

Figure 16: Web page including hidden form

3.4.1 AD FS reply address (wreply)As seen in Figure 15 the WS-Federation redirect from the application to the AD FS server includes a wreply parameter. This parameter including its value is set by the AAD App Proxy.If the proxy was not being used the wreply parameter would not be included in the string. After the user is authenticated, the AD FS server will return the hidden form containing the token with a POST back URL as defined for the AD FS relying party default endpoint. See Figure 17 & Figure 18.


0

Figure 17: AD FS relying party endpoint

<form method="POST" name="hiddenform" action="https://app1.xtseminars.com:443/">

Figure 18: POST back URL from hidden form in Step 12 of Figure 14

Assuming the application is published externally through the AAD App Proxy, different URLs can be used for internal and external access. Internally the default POST endpoint URL will be used, externally the AAD App Proxy will add the appropriate wreply URL. This URL will define that the hidden form POST should be to the external AAD App Proxy endpoint for the application. Figure 19 shows the wreply parameter when app1 is published externally as proxyapp1.xtseminars.com.


0

https://adfs.example.com/adfs/ls/?wa=wsignin1.0&wtrealm=http://adfssts.xtseminars.com&wctx=rm=0&id=passive&ru=%2F&wct=2015-07-22T16:36:50Z&wreply=https://proxyapp1.xtseminars.com/?ClaimAwareAAD5F09D25F-4423-4C2C-AE2A-2B92511B0671=9d476a45-d49f-45c1-8dc7-5c8ec60d0a37

Figure 19: Redirect URL – with app1 published as proxyapp1.xtseminars.com

The AD FS server will not set the POST back URL based on the wreply parameter unless the AAD App Proxy endpoint is added as a relying party endpoint. See Figure 20 and Figure 21.

Figure 20: AAD App Proxy endpoint added as AD FS relying party endpoint

<form method="POST" name="hiddenform"


0

action="https://proxyapp1.xtseminars.com:443/?ClaimAwareAAD5F09D25F-4423-4C2C-AE2A-2B92511B0671=30d93c25-cd13-4f88-875c-263b51a98262">

Figure 21: POST back URL set via wreply parameter

3.4.2 SSO for published claims-aware applicationsIf SSO is to be implemented, the same identity provider (IdP) must be used to authenticate access to the AAD App Proxy and authenticate access to the claims-aware application. Once the user has authenticated to the AAD App proxy they will be in possession of an IdP authentication cookie. This cookie is passed to the IdP to provide SSO for the application. The AAD App Proxy automatically trusts the Azure AD. The options to implement SSO are:

The claims-aware application trusts Azure AD as the STS. The claims-aware application trusts an on-premises AD-FS server and the AD

FS server trusts Azure ADo This is a special case that uses a resource AD-FS server for claims

enrichment.o Also used if AD FS has already been implemented for applications

The claims-aware application trusts an on-premises AD FS server which authenticates users against the on-premises AD and the Azure tenant domain is configured for federated SSO with the on-premises AD FS server.

o In this configuration the user is authenticated by the on-premises AD, via the AD FS server, for both the AAD App Proxy preauthentication and claims-aware application.

Each of these SSO scenarios is explored in more detail in the following sections.


0

3.5 Publishing a claims-aware application that trusts the Azure AD

Figure 22: Publishing a claims-aware application that trusts the Azure AD

In this scenario, depicted in Figure 22, the AAD App Proxy preauthenticates the user and the claims-aware application is configured to trust the Azure AD. This is the recommended configuration if applicable. It allows the on-premises application to utilize all Azure AD capabilities.After the preauthentication at the AAD App Proxy (steps 1-9 Figure 3), app1 will redirect the user to Azure AD to obtain a security token that authenticates the user to APP1. When the authentication request is made to the Azure AD, cookies are passed with the request that indicate the user was already authenticated during the preauthentication sequence. Consequently the Azure AD immediately issues the token with no requirement for the user to login again. This provides SSO to the ADD App proxy and published claims-aware application. The only caveat to this is when the AAD App Proxy and the application have different authentication policies, for example the application requires MFA.If additional claims-aware applications that trust ADD are published through the AAD App Proxy, after the user has preauthenticated to the AAD because of the cookies the user will have SSO to all the published applications, subject to the authentication policies.Figure 23 shows the protocol flow for authentication to the application. In this illustration WS-Federation is shown but a similar flow would occur for other


0

federated protocols. Figure 23 starts from step 9 after the preauthentication depicted in Figure 3.

Figure 23: Authenticating to app1, where app1 trusts Azure AD as the IdP


AzureAppProxyAccessCookie set. The AAD App Proxy accepts the cookie as proof that the user has been preauthenticated and passes the request to the application.

10.The user has not previously authenticated to app1, consequently app1 redirects the user to Azure AD. The WS-Federation authentication string is included as part of the redirect URL.

11.Azure AD receives the request along with authentication cookies that were set during the preauthentication to the AAD App Proxy.

12.Azure AD validates the cookies and produces a SAML token for app1. The token is returned in a hidden form on a web page as previously discussed in the Section 3.4

a. Provided the authentication cookies are valid no additional authentication is required by the using. This provides SSO to the AAD


0

App Proxy and the application, subject to the AAD App Proxy and application having the same authentication policy.





0

3.5.1 Adding a resource AD FS server for claims enrichment

Figure 24: Adding a resource AD FS server for claims enrichment

This is a special case where the application trusts an AD FS server which in turn trusts Azure AD, see Figure 24. The advantage of this model is that the AD FS server can be used to enrich the claims in the SAML token before it is presented to the application. It also makes sense to use this model when there are applications that already work with AD FS.When supporting multiple claims-aware applications, the AD FS server can then be used to produce the appropriate claims set for each application.The protocol flow is similar to that shown in Figure 23 with some additional steps.

The application redirects to the AD FS server which in turn redirects to Azure AD.

Azure AD produces the SAML token which is trusted by the AD FS server. The token is POSTed to the AD FS server, after validation the AD FS server

creates a new token for the application based on the claim rules. The new token is POSTed to the application


0

The claims rules processed by AD FS can provide simple translation or create additional claims based on values stored in other attributes stores. This is illustrated in Figure 25. Using this method it is possible to create a security token with a rich set of claims targeted for specific applications.

Figure 25: Claims enrichment

Note: For this scenario to work for external users the external users must be able to access the on-premises AD FS server via the Server 2012 R2 AD FS Web Application Proxy. Today the Azure AD App Proxy does not support the publishing of AD FS.


0

3.6 Claims-aware application trusting ADFS with Azure AD Federated SSO

Figure 26: Claims-aware application trusting ADFS with Azure AD Federated SSO

Under standard operation a user is authenticated against Azure AD based on the user identity and password hash that is stored in Azure AD. A user can sign-in to the Azure AD using the same credentials as for their on-premises AD provided the user identity and password hash are synchronized between the on-premises AD and the Azure AD.Azure AD can be configured to federate with an on-premises AD FS, this is configured for all users within a domain (Azure AD UPN suffix). Once federation is enabled the Azure AD trusts the on-premises AD FS and a user in the federated domain will be redirected to the on-premises AD FS server to authenticate. Figure 26 shows the trust paths. The protocol flow for preauthentication to the AAD App Proxy is shown in Figure 27 and Figure 28.

Note: For this scenario to work for external users the external users must be able to access the on-premises AD FS server via the Server 2012 R2 AD FS Web Application Proxy. Today the Azure AD App Proxy does not support the publishing of AD FS.


0

Figure 27: Preauthentication with Azure AD federated SSO – part 1

Protocol flow:1. Get request to published application. The AAD App Proxy checks for a valid

AzureAppProxyAccessCookie.2. If there is no valid cookie the user’s browser is redirected to Azure AD for

authentication. The redirect URL includes details of the Azure AD endpoint and the authentication method to be used.

a. The authentication method is Open ID connect using an OAuth 2.0 code grant flow.

3. Azure AD receives the authentication request and prompts for the user’s name and password.

4. As soon as the username is entered, the domain is identified as a federated domain and a page is returned containing the details of the configured AD FS endpoint and the authentication string, show as string 2 in Figure 27. The username parameter is set to the entered value.

5. JavaScript running in the browser creates a GET request to the AD FS server using the details returned in Step 4.

6. The AD FS server authenticates the user against the AD and creates a security token for Azure AD which is proof of authentication. AD FS uses the rules as defined in the “Microsoft Office 365 Identity Platform” relying party trust. This trust was created when federated SSO was established. The token is returned via a hidden form on the webpage and authentication cookies are set.


0

The next part of the protocol flow is shown in Figure 28.

Figure 28: Preauthentication with Azure AD federated SSO – part 2

Protocol flow continued:7. The token is POSTed back to Azure AD and validated8. Azure replies to the user’s browser with a redirect to the application, an

OAuth 2.0 code is appended to the reply URL. The code identifies that the user has been authenticated and can be used by the AAD App Proxy to obtain an access token. Azure also returns a cookie that identifies that the user has been authenticated by Azure.

9. The user’s browser redirects to the application with the code in the URL.10.The AAD App Proxy sends a request to Azure AD to convert the code to an

access token. The token is in JWT format and includes the UPN of the user.11.The AAD App Proxy received the JWT from Azure AD and validates the token.

The AAD App Proxy checks that the user is authorized for access to the application.

a. The user must be assigned for access through the AAD App Proxy.b. The user must have an Azure AD Basic or Premium license.

12.If the user is authenticated and authorized, the AAD App Proxy responds with a redirect to the application and sets an AzureAppProxyAccessCookie cookie.

13.The user’s browser redirects to the app and sends the cookie. The cookie identifies that the user is authenticated for access through the AAD App Proxy and the request is forwarded to the application.


0

a. If anonymous access is allowed to the application, the page is rendered.

c. If authenticated access is required, this is now implemented using whatever method has been chosen. In this example authentication is against the corporate AD FS and AD.

Figure 29: Authentication to app1

Figure 29 shows the protocol flow for authentication to the application:14.The user has not previously authenticated to app1, consequently app1

redirects the user to the AD FS that it trusts. The WS-Federation authentication string is included as part of the redirect URL.

15.The AD FS receives the request along with the authentication cookies set in Step 6 above. The cookies are accepted as proof of authentication.

16.The AD FS server will create a security token based on the configured claim rules. The token will be returned in a hidden form on a web page.



0



As an alternative scenario it would be possible for the application to trust the Azure AD. A very similar flow would occur, this time the application would authenticate the user against Azure AD and the authentication cookies obtained in Step 8 above would be passed allowing automatic authentication. The advantage of the application trusting AD FS is that a much richer claims set can be produced.


0

4 TroubleshootingIn this section we will look at troubleshooting a range of scenarios. No two systems will be completely identical, consequently it is not possible to cover every eventuality that you might come across. However, this section will equip you with the tools and techniques to tackle most problems that you may encounter.As you will have seen in Section 3 there are many different scenarios and levels of complexity. This paper looks at issues involving the AAD App proxy and authentication flows with Azure AD and AD FS, it does not show you how to troubleshoot the applications or your AD FS installation. However some of the techniques and tools will help you with both.Before starting to troubleshoot your environment please review Section 3 for technical insight on the different possible scenarios.

You may weaken the security stance of your deployment if you make changes while trying to track down a problem. The performance may also be affected due to increased logging. Having completed the troubleshooting make sure that you disable any unnecessary changes and logging. And of course fully document and approve any changes that are necessary as a result of you troubleshooting investigations and remediation.

4.1 Troubleshooting checklist and signpostsRegardless of which of the scenarios shown in Section 3 that you have deployed, or maybe you even have a different set up, if you can’t gain full access to the application there are some fundamental troubleshooting steps that you should always begin with. The following table walks you through the major troubleshooting steps, more details for each step are given in the sections that follow. For more advanced troubleshooting use the tracing techniques given in Sections 4.8.5 & 4.9 and the insight gained from Section 3 to track down the problems.In the following table verify means “check and if the configuration/test is at fault remediate it”. The right-hand column of the table signposts the appropriate Section in this whitepaper if help is offered in tracking down and remediating the problem.Not all of the steps in the table will apply to your situation, but where they do, you need to verify the appropriate functionality and remediate if necessary.


0

Major

steps

Table 6: Troubleshooting steps and signpostsSee

section

1 Check you can directly access (not through the proxy) the application to be published from the internal network.

a) Verify the DNS name of the application resolves to an IP address. 4.3.1

b) Run a browser on the server(s) that are running the connector(s) and verify you can you access the application.

2 Verify the connector is functioning. 4.4.1

a) If necessary troubleshoot the connector. 4.4

3 Access the AAD App proxy configuration for the published application and record the following:

External URL: Preauthentication method: Certificate: Internal URL: Translate URL in header: yes/no Internal authentication method: Internal application SPN: Delegated login identity:

4.2.1

4 Verify the values that you recorded in Step 3 match your designed configuration. See step 7 for verifying the configuration

6 If using preauthentication, check that the user is authorized for access.

a) Verify that the user is directly or indirectly, through group membership, assign to access the published application through the AAD App Proxy.

4.2.2&

4.2.3

b) Verify the user has either an Azure AD basic or premium license.

4.2.2&

4.2.4


0

7 User the information collected in Step 3 and perform the following steps

a) Verify the DNS name in the External URL resolves to an IP address.

4.3.2

b) For passthrough or Azure Active Directory preauthentication verify that the authentication method for the application is supported.

4.5

c) If Azure Active Directory preauthentication is configured, confirm that immediately the browser connects to the external URL it is redirected to the Azure AD login.

4.9&

4.9.2

d) If using HTTPS and the URL is using a custom domain name, verify that a valid certificate has been uploaded to the portal.

4.6

e) Verify that the test you performed in Step 1 used the internal URL as defined in the configuration.

f) Verify if host header translation should be used. Incorrect setting may prevent access to the internal website.

4.7

g) If the internal authentication method is set for Integrated Windows Authentication (IWA), verify the internal app is configured for Kerberos.

4.5.3

h) If IWA is used, verify that the server(s) running the connector(s) is/are domain joined.

i) If IWA is used, verify and the server(s) running the connector are correctly configured for delegation.

4.8.1

j) If IWA is used, verify the correct application SPN has been set.

4.8.2

k) If IWA is used, verify the correct delegated login identity is selected.

4.8.3

8 After checking the configuration, if you cannot authenticate to a Kerberos application troubleshoot using a network trace.

4.8.5

9 If you cannot access a cross-platform Kerberos application, you 4.8.4


0

may require SPNEGO to be enabled.

10 If you cannot access part of the application, verify that all of the appropriate URLs are published.

4.2.5

11 If a claims aware application is failing to authenticate, use Fiddler to verify the authentication flow.

4.9

12 If you are having problems with setting or changing the URL for the application – verify the object naming in the Azure AD.

4.10

4.2 Publishing the applicationThe application is published through the Azure AD portal for details of publishing applications refer to: https://msdn.microsoft.com/en-us/library/azure/dn768219.aspx

4.2.1 Application configurationTo view the application configuration login to the classic Azure portal and view the Azure AD node. Depending on your environment you may have multiple Azure Active Directories, select the Azure AD where you have the AAD App Proxy configured and click Applications.You will see a list of published applications which can include web applications that have been published for Azure AD authentication and proxy applications that publish on-premises applications through the AAD App Proxy.Select the proxy application that you want to verify and click Configure.

4.2.2 Authorizing access through the proxyBefore a user can gain access through the proxy they must be both authorized and licensed. The authorization is checked in advance of the licensing. If a user is not authorized they will see an error page similar to that shown in Figure 30.


0

Figure 30: User not authorized for access

To make it easier to read, the error message is reproduced in Figure 31.

Azure AD Application ProxyStatus code: ForbiddenUrl: https://aadsts.xtseminars.com/?error=access_denied&error_description=AADSTS50105:+The+signed+in+user+'[email protected]'+is+not+assigned+to+a+role+for+the+application+'ab0a45c7-c085-4f3f-a868-62f3927926ef'# Trace+ID:+c8fc15e0-2d6f-49e8-b843-00a90032585f Correlation+ID:+7e8e28f0-5a5d-4409-a217-1e8363fda666 Timestamp:+2015-08-27+13:23:38Z&state=AppProxyState:{"IsMsofba":false,"OriginalQuery":""}TransactionID: 11cb1346-534e-4543-9b34-229c898b3b4dTimestamp: 8/27/2015 1:23:38 PM

Authorization failed. Make sure to assign the user with access to this application

Figure 31: Error message - user not authorized for access

The preauthentication flow diagram Section 3.2.1 is reproduced again in Figure 32. Step 3 sends the authentication request to the Azure AD. After the user is authenticated a check is made to verify that the user has been assigned to the application. If they haven’t been assigned, rather than returning the code as shown in Step 4, Azure AD redirects the browser to the URL shown in Figure 31. The proxy


0

receives the GET request and in response issues a 403 Forbidden and renders the webpage shown in Figure 30.Although the error message can look a little daunting with all the GUIDs, there is a very readable message stating that [email protected] is not assigned to the application. To learn how to assign a user to the proxy application refer to Section 4.2.3.

Figure 32: Preauthentication flow from Section 3.2.1

If the user is authorized but not licensed they will see are error page similar to Figure 30, but the error message will be as shown in Figure 33.


0

Azure AD Application ProxyStatus code: ForbiddenUrl: https://aadsts.xtseminars.com/?code=AAABAAAAiL9Kn2Z27UubvWFPbm0gLdKySDQvXbWkFhO0QW4d4AjCAN9lxS-fOaBulI05HQz86MpMcKHnDP7cpi7n7CcpxH1uZCVLK2Z5vyekLndYN0vAbQBmqLusqPVOa4VMbv90McHRIQLgNFIxqo00gnayvfTQpAiY6vIUUeVfQsEGL7G4_ybxlciNI536JQ-MpxfZG44sQ17cblc-KiF_6EnkRsBGUMlhkFjhEhwdtmEgOzH2b1KnnL30T2uJIRBIT-EKbKzitNZN-vxKSodgpzX7S21VNOSnH_OMkGLTwlcG8FPD9t_K0JTgfA0uN7qdLn2dA8F0pzjO-zCTIJylQHmAP43hdiUmOFOKxnvS6nBg3JIA2JNtNjincsAumG8xMAp10DexwBZpA5qoFuGrCXLMFsgqR6hFm_frPuI1XFh8U3TE7YOuFrGPG52_0iijd8FMm4IfAsOcTBynyvmfmaY5dUEbF4KG-eje_Fe3RaVWfc4YNDM3j6SCt9nAeiXWIGT-pEcvBMfHe8pzrhzNBu4Q9O2WnKJqaFX11thmr5rP-yY7N-58zx977ag7kWN1ixyBRd6za8q6htGVdacNKDiTW-RaTENiwRjfxwA0ffYqTJL1V30qU4gd7bfuNst6Qnhkq0R134m_fwjlWBIsnYBodhDHrXHaKimi7YMHdSxbVBsgAA&state=AppProxyState:{"IsMsofba":false,"OriginalQuery":""}&session_state=7a1dd3a2-1b4a-4eeb-be0f-52371cd6eea5TransactionID: e4879ded-0f8a-46d3-9f90-74f9de70b0f1Timestamp: 8/27/2015 2:42:55 PM

Authorization failed. Make sure that the user has a license for Azure Active Directory Premium or Basic

Figure 33: Error message - user authorized, but not licensed

In this scenario after authenticating the user the Azure AD is returning the OAuth 2.0 code that proxy uses to obtain a SWT to authenticate the user. This is shown as Step 5 in Figure 32. When the proxy receives the code, before it allows access, it validates that the user is licensed. If the user is not licensed the proxy issues a 403 Forbidden response and renders the error webpage.Despite the complexity of the URL in the error message it is very clearly indicated that the user doesn’t have a license. “Authorization failed. Make sure that the user has a license for Azure Active Directory Premium or Basic”. To learn how to assign a license to the user see Section 4.2.4.

4.2.3 Assigning a user to the proxy applicationTo assign a user to a proxy application login to the classic Azure portal and view the Azure Active Directory node. Depending on your environment you may have multiple Azure Active Directories, select the Azure AD where you have the Azure AD App Proxy configured and click Applications.You will see a list of published applications which can include web applications that have been published for Azure AD authentication and proxy applications that publish on-premises applications through the Azure AD App Proxy.


0

Select the proxy application that you want to assign to a user, scroll down the page and select the Assign accounts option. You can either directly assign the user or assign a group of which the user is a member. Groups may be simple groups, self-service groups or dynamic groups (based on profile properties).

4.2.4 Assigning a license to a userTo assign a license to a user you must have already signed up to Azure AD Basic or Premium. Login to the classic Azure portal and view the Azure Active Directory node. Depending on your environment you may have multiple Azure Active Directories, select the Azure AD where you have the Azure AD App Proxy configured and click Licenses. Assign a license to the user.

4.2.5 Verify published pathsWhen you publish an application, the external URL can be based simply on a Fully Qualified Domain Name (FQDN) such as https://app1.xtseminars.com or an FQDN and a path such as https://app1.xtseminars.com/two.If you publish the application with a URL which defines a path you will only be able to access paths that are stemmed from the URL. For example, if the published URL is https://app1.xtseminars.com/two you can access https://app1.xtseminars.com/two/three but not https://app1.xtseminars.com/one. To access https://app1.xtseminars.com/one you would need to specifically publish it.Depending on the browser that you are using it is not always easy to see what is going on. Figure 34 shows accessing the test site with Chrome, Figure 35 shows accessing a path that is not published. The error message is not very helpful!


0

Figure 34: Accessing the published site with Chrome

Figure 35: Accessing a site that is not published

The simplest way to troubleshoot this is to use the F12 key to turn on the developers tools, this is shown in Figure 36. We can now see that the request has generated a 404 status code. The HTTP code is returned by the proxy indicating that the page has not been found.


0

Figure 36: Using the developer tools

Using the developer tools you can immediately see that the error code is being returned from the URL you are attempting to access, this confirms that DNS has resolved the IP address and now it is a matter of troubleshooting why the page is not being returned. If you have performed Step 1 in Table 6: Troubleshooting steps and signposts, you will have confirmed that the application is working, so the problem must be due to the URL of the application not being published.F12 will also invoke developer tools on Microsoft Internet Explorer. If you want to do a more detailed trace see Section 4.9.


0

4.3 DNS name resolutionDNS name resolution is critical to the success of any deployment and it can be complex due to the fact that the Fully Qualified Domain Name (FQDN) of the application must be resolved to a different IP address from the Internet and the intranet. Depending on how the application is published the FQDN may be the same internally and externally or different. Regardless of the application FQDN when AD FS is introduced to support claims-aware applications the FQDN of the AD FS farm must be the same on both the Internet and intranet. However when resolving the FQDN of AD FS on the Internet it must resolve to the IP address of the Web Application Proxy farm and resolve on the intranet to the IP address of the AD FS farm.

4.3.1 Internal FQDN for the published application Use nslookup to verify the Fully Qualified Domain Name (FQDN) of the internal app can be resolved from the server(s) that are running the connector(s)

1. Run a command prompt and type nslookup app1.xtseminars.com. Where app1.xtseminars.com is the FQDN of the application.

a. Append a “dot” to the end of the FQDN so that nslookup only attempts to resolve the exact FQDN.

b. See Figure 37 for an example of using nslookup to resolve the FQDN2. You will see the IP address of the DNS server that the machine where you are

running the tests is using, verify that this is as expected. a. The name of the server will only be displayed when reverse lookup

records have been configured on the DNS server.3. If nslookup cannot resolve the FQDN, check the host (‘A’) record entry exists

on the DNS server.4. If the IP address is incorrect, check the IP address defined for the host (‘A’)

record entry on the DNS server.5. As a final test ping the FQDN. The app may not respond to the ping however

you will be able to see if the FQDN resolves to the correct IP address. a. If the IP address is wrong, probably a HOSTS file with an incorrect entry

is being used on the machine where you are running the tests.

C:\>nslookup app1.xtseminars.com.Server: UnKnownAddress: 10.50.0.11

Name: app1.xtseminars.com


0

Address: 10.50.0.13

>

Figure 37: Resolving the FQDN using nslookup

4.3.2 External FQDN for published applicationThere are two options for publishing the external URL of the application. The URL can be stemmed from the default domain msappproxy.net or a custom domain such as xtseminars.com. The URL is unique to the application and the tenant, either by using a URL with a custom domain name that is owned by the tenant or via an Azure generated URL which appends the tenant name to the name of the application. For example, Azure might generate the following URL https://app1-xtstest.msappproxy.net. App1 uniquely identifies the application within the tenant and this in combination with xtstest, the tenantID, makes the URL unique across all Azure AD tenants. URLs for multiple tenants can resolve to the same IP address and it is the HTTP host header that is used to route the request to the appropriate published application. When HTTPS is used the SSL traffic is terminated on the Azure AD App Proxy consequently the header can still be used for routing.When an application uses the default domain, the DNS records required to resolve the FQDN to an IP address are completely managed by Microsoft. When a custom domain name is used the external FQDN of the published application must be aliased to the Azure generated FQDN using a CNAME record. The tenant is responsible for publishing this DNS CNAME record in a publically available DNS server. The required CNAME record can be viewed in the portal, see Figure 38. Refer to Section 4.2.1 for help in locating the configuration settings in the Azure Portal.

Figure 38: CNAME required for the external FQDN


0

The Microsoft DNS uses a wildcard CNAME entry to resolve *. msappproxy.net to its alias. If you are using an Azure AD generated FQDN such as app1-xtstest.msappproxy.net, when testing, make sure you as using the correct hostname in the FQDN because any hostname that is used will look as though it resolves correctly.If you are using a custom domain name check that the CNAME entry, that you are responsible for, maps to the correct Azure generated FQDN alias.

There are a number of aliases involved in resolving the external FQDN of the publish application and these are best viewed using nslookup.

1. Run a command prompt and type nslookup app1.xtseminars.com. Where app1.xtseminars.com is the FQDN of the application.

a. Append a “dot” to the end of the FQDN so that nslookup only attempts to resolve the exact FQDN.

b. See Figure 39 for an example of using nslookup to resolve the FQDN2. You will see the IP address of the DNS server that the machine where you are

running the tests is using, verify that this is as expected. a. The name of the server will only be displayed when reverse lookup

records have been configured on the DNS server.3. The various aliases that are used are also displayed. They are resolved

through a series of CNAMES. In the example, xtstest is the Azure AD tenant name, the actual aliases that Microsoft uses may change, however you should see a similar pattern.

4. If the FQDN of your app does not resolve, verify that your CNAME DNS entry is correct.

5. To verify an individual CNAME you can use nslookup -type=cname app1-xtstest.xtseminars.com.

6. To see the resolution of the IP address and all the CNAMEs in one go use debug mode nslookup -debug app1-xtstest.xtseminars.com.

C:\> C:\>nslookup app1.xtseminars.com.Server: UnKnown


0

Address: 81.103.238.99

Name: cwap-cu-2.cloudapp.net

Address: 23.99.136.190

Aliases: app1.xtseminars.com

app1-xtstest.msappproxy.net

cwap-nam1-runtime.msappproxy.net

cwap-nam1-runtime-main.trafficmanager.net

C:\>nslookup -type=cname app1-xtstest.msappproxy.net

Server: UnKnown

Address: 144.19.27.1

Non-authoritative answer:

aadsts-xtstest.msappproxy.net canonical name = cwap-nam1-runtime.msappproxy.net

Figure 39: Resolving the FQDN with multiple aliases


0

4.3.3 Verifying the AD FS URLsIn order for authentication to work in combination with an on-premises AD FS farm the farm must be available from both the intranet and Internet.On the intranet the URL for the AD FS service should resolve to the load-balancer for the AD FS servers. On the Internet the URL for the AD FS service should resolve to the load-balancer for the web application proxies that are publishing the AD FS farm for Internet access. Currently the proxy role for AD FS cannot be performed by the Azure AD App proxy and should be implemented using the web application proxy which is installed as a role on Server 2012 R2 or a third-party equivalent.Use nslookup as shown in Section 4.3.1 to verify that the AD FS FQDN can be resolved on both the Internet and the intranet.To quickly test if the AD FS server is operational you can download the metadata using the appropriate URL, for example:

https://sts.xtseminars.com/federationmetadata/2007-06/federationmetadata.xml

You can verify the login is working using an IdP initiated login, for example: https://sts.example.com/adfs/ls/IdpinitiatedSignOn.aspx


0

4.4 The AAD App Proxy ConnectorThe AAD App Proxy connector communicates outbound from your intranet to the Azure Cloud. This means that you do not need to have any inbound ports enabled to the server(s) running the connector(s), but you do need the server(s) to be able to communicate on a number of outbound ports to the Cloud. Table 7 shows the required outbound ports.

Table 7: Required outbound ports for the connector

Port Number

Description

80 To enable outbound HTTP traffic for security validation.

443 To enable user authentication against Azure AD (required only for the Connector registration process)

10100 - 10120 To enable LOB HTTP responses sent back to the proxy

9352, 5671 To enable communication between the Connector toward the Azure service for incoming requests.

9350 Optional. To enable better performance for incoming requests.

8080 To enable the Connector bootstrap sequence and to enable Connector automatic update

9090 To enable Connector registration (required only for the Connector registration process)

9091 To enable Connector trust certificate automatic renewal


0

4.4.1 Checking the functioning of the connectorYou can view the operational status of the connectors that you have installed via the Azure portal. Login to the classic Azure portal and view the Azure Active Directory node. Depending on your environment you may have multiple Azure Active Directories, select the Azure AD where you have the Azure AD App Proxy configured and click Configure. Scroll down the page until you see the Application Proxy section and click View Connectors. The connector will show as Active or Inactive see Figure 40: Connector status

Figure 40: Connector status

Even if the connector is showing as active its operation may be block by an inaccessible port. If you get an error message similar to Figure 41 it indicates that the connector cannot communicate properly which may well be due to a blocked port.


0

This corporate app can't be accessed right now.Please try again later...

There may be a connectivity problem Refresh the page in a few minutes.

Azure AD Application ProxyStatus code: GatewayTimeoutUrl: https://pathsproxy-xtsad.msappproxy.net/two/three/default.aspxTransactionID: 85921d6a-90a5-4131-95e3-dbe78058f4f5Timestamp: 8/28/2015 2:01:51 PM

The connector has timed out.

Figure 41: Connector time out

You can check that the outbound ports are not blocked by accessing a webpage hosted by the AAD App Proxy product group. http://testport.cloudapp.net/. Make sure you run the test on the server(s) that are hosting the connector(s). Figure 42 shows the results when port 1010 is blocked.

Figure 42: Port 1010 blocked


0

There are two services that run the connector verify that both of them are running. Microsoft AAD Application Proxy Connector

o Manages the communication between the Cloud proxy service and the on-premises connector

Microsoft AAD Application Proxy Connector Updateo This service checks for updates every hour and automatically

downloads any changesIf both services are running and the outbound ports are open, but the connector still doesn’t seem to be functioning. Check the event logs, Section 4.4.2.If the event logs do not offer any insight into what could be wrong, completely remove the connector using Control Panel\Programs\Programs and Features and reinstall it from the Azure AD Portal. For help interpreting some of the installation event log messages see:

https://msdn.microsoft.com/en-us/library/azure/dn768218.aspx

4.4.2 Checking the connector event logsEach of the services that run the connector has its own event collection. See Figure 43. As you can see in the screenshot there is an admin and session log for each service. General function of the connector can be seen in the admin log and specifics relating to the sessions can be viewed in the session log. In the session log you will see the start of a session including the transaction and session IDs. The session log will then show you the host header translation, if any, and more details about the session. However, it does not necessarily show that a port is blocked and the connector cannot sent a reply to the request. Consequently always verify that the outbound ports are available using http://testport.cloudapp.net/ For help in reading some of the event log messages see:





0

Figure 43: The connector event logs


0

4.5 Authentication to the applicationThe application authentication method used must be supported by the Azure AD App Proxy. All of the authentication methods are mention for the different scenarios in Section 3 and are summarized here for you convenience.The proxy supports:

Anonymous access Forms authentication Basic authentication Digest authentication NTLM Kerberos authentication Claims authentication

With the exception of Kerberos all of the authentication methods listed are implemented through a direct interaction between the user, the browser and the application. Despite this “direct” interaction between the browser and the application remember that the proxy is acting as a man-in-the-middle and may impact the behavior. For a claims authentication the browser will also need to access the security token service, which may be Azure AD, AD FS or a third-party solution. See Sections 3.4, 3.5 and 3.6.As discussed in Section 3.3 Kerberos authentication to the application is implemented through the Azure AD App Proxy using Kerberos constrained delegation.If authentication is failing through the proxy, the first test is to verify that you can authenticate to the application from the intranet.

4.5.1 SSO AuthenticationCurrently the only way to implement SSO between the proxy and the application is to either user Kerberos or claims authentication for the application. See Section 3.3 for a discussion of Kerberos authentication and Sections 3.4, 3.5 & 3.6 for discussion of the options for implementing claims authentication.

4.5.2 NTLM AuthenticationAlthough NTLM can be used through the AAD App Proxy it should never be used except for down-level compatibility. Never use it without a full security assessment and review. When publishing applications that require Windows authentication you should always use Kerberos authentication. This will give you enhanced security and the advantage of having SSO between the Azure AD App Proxy preauthentication login and authentication to the application.


0

The only reason for using NTLM is to support Mac. In a situation where the internal and external URLs are the same, the browser might well be configured to have the internal (and therefore the external) URL as part of the internet zone. In this situation the browser will automatically attempt to log the user into the application. While this works on the intranet, the automatic login fails if coming through the proxy, and results in a 401. The user is not prompted for credentials and there is no way to login to the application. Make sure that the browser is not configured for automatic logon for the external URL published by the proxy. Check the browser configuration as shown in Figure 44.

Figure 44: Disable automatic logon

If the website is using HTTPS and extended protection, you cannot use Fiddler (see Section 4.9 for more details of Fiddler) for debugging a session. Fiddler intercepts the HTTPS traffic, breaking the channel binding, it will be seen as a man-in-the-middle attack and authentication will fail. If you are being prompted by the application for username and password and authentication fails despite using the correct user name and password, this could be due to Fiddler interception. Either stop using Fiddler or turn off extended protection while you are troubleshooting.

4.5.3 Kerberos authenticationIf the Azure AD App Proxy is configured for Windows Integrated Authentication (WIA), the proxy will use Kerberos Constrained Delegation with Protocol Transition (KCD) to access the internal application. For this to work it must be possible to


0

access the internal application using Kerberos. Review Section 3.3 for more details on Kerberos and KCD.The challenge with accessing a Windows application using Kerberos is that Windows uses negotiate (aka SPNEGO) and if the application is not configured correctly to use Kerberos, authentication will silently fallback to using NTLM.Before attempting to troubleshoot WIA on the proxy always confirm that you can authenticate to the internal application using Kerberos.

Validating Kerberos authentication - method 1Use Klist to enumerate Kerberos tickets that are held in the user’s cache. If a session ticket to the website exists the user has probably authenticated using Kerberos. See Figure 45, where the session ticket is identified by the SPN: HTTP/wia.xtseminars.com

Figure 45: Kerberos session ticket to wia.xtseminars.com


0

Validating Kerberos authentication - method 2Use Fiddler to capture an HTTP trace and examine the results. Examine the first request after authentication, it returns a 200 OK and the webpage. If the header value “Authorization: Negotiate” starts TIRM…, authentication is via NTLM, see Figure 46. If the header value starts YII…, authentication is via Kerberos, see Figure 47.

Figure 46: NTLM authentication

Figure 47: Kerberos authentication


0

Validating Kerberos authentication - method 3Check the security logs on the webserver, a logon event (4624) will show if NTLM or Kerberos has been used.

Validating Kerberos authentication - method 4Use a third party tool such as “Kerberos Authentication Tester” from Michel Barneveld (http://blog.michelbarneveld.nl), will indicate if the authentication was via NTLM or Kerberos. See Figure 48 & Figure 49. The tool can also be used to view the Kerberos tickets.

This whitepaper cannot not endorse the suitability of the tool for your environment. Downloading the tool, installing and using it should only be done at your own risk after you have evaluated and security checked the tool in a test environment.

Figure 48: Authentication via NTLM


0

Figure 49: Authentication via Kerberos

Troubleshooting Kerberos authenticationThe most likely cause of failing to authenticate against an application using Kerberos is due to the Service Principal Name (SPN) not being registered or registered against the wrong Active Directory security principal. The SPN should be registered against the account that is running the application, this maybe a computer, managed service, or user account. Use setspn.exe to verify the SPN registration, if you need more help refer to the Kerberos troubleshooting whitepaper that can be down loaded here: http://aka.ms/KCDPaper



0

4.6 CertificatesWhenever HTTPS is used, a valid certificate is required on the device that terminates the SSL traffic. When an external HTTPS URL is configured on the Azure AD App Proxy a certificate will need to be enabled for the proxy in the Azure Portal. If the external URL is based on the default msapproxy.net domain name a certificate maintained by Microsoft is automatically used. If you use a custom domain you will need to upload a certificate.Supported certificates

Single-name Wildcard SAN Self-signed Elliptic Curve Cryptography (ECC) certificates

o There is no explicit limitation on the signature methodsFor ease of maintenance and providing access to third-party users it recommended to use certificates that are purchased from a public issuing authority.

Table 8: Certificate troubleshooting tips

For a certificate issued by a public authority the most likely problem that can occur is that the certificate has expired. Verify the certificate validity via the Azure portal and if necessary upload a new certificate.

If you are issuing certificates from your own Certificate Authority (CA), in addition to deploying the issued certificate to the Azure portal make sure the CA root certificate and any intermediate certificates are deployed to the client machines.

If the certificate has Certificate Revocation List (CRL) Distribution Points defined, make sure that the publish paths are available to an external client. The CRLs could be made available via publishing the web server containing the CRLs via the Azure AD App Proxy with no preauthentication.

In addition to the certificates that are deployed to support the external URLs of the Azure AD App Proxy you will need to deploy and maintain certificates for your applications and if using claims authentication via AD FS you will need to manage its certificates.


0

4.7 Host header translationThe hostname of the server that is being accessed is included as part of the HTTP header. If multiple websites are published by a web server on the same IP address the hostname (FQDN) in the HTTP request can be used by the web server to route an incoming request to the appropriate website. In IIS this configuration is done as part of the site bindings, see Figure 50.

Figure 50: IIS site bindings

When the client sends an HTTP request to the external URL of the proxy, the HTTP host header will be set to the FQDN of the external URL. If host header translation is not enabled, when the proxy forwards the request to the internal URL the host header will still be set to the FQDN of the external URL. If the host header is used to bind to a site, the hostname in the HTTP header will not match the site hostname and access will fail.In general host header translation should be used which will allow site binding using the hostname. The default configuration has host header translation is enabled.Some applications such as SharePoint need the host header set to the FQDN of the external URL. This allows SharePoint to render pages with the correct URL links for external access. A whitepaper will be available shortly that discusses publishing SharePoint and Alternative Access Mapping (AAM).

4.8 Kerberos configurationReview section 3.3 for details on how Kerberos Constrained Delegation is used by the Azure AD App Proxy to authenticate to the internal applications that uses


0

Kerberos. If you need more help refer to the Kerberos troubleshooting whitepaper that can be down loaded here: http://aka.ms/KCDPaper

4.8.1 Configuring Kerberos delegation for the connectorAlthough it will be the server that is running the connector that implements KCD the configuration for KCD is set via the properties of the server’s computer account object in the on-premises AD. The delegation should be set as show in Figure 51. The “services to which this account can present credentials” are identified by the internal application SPN.

Figure 51: Properties of the computer object

4.8.2 Internal Application SPNThe Internal Application SPN that is defined in the Azure portal must be the same as the SPN registered against the account that is running the application, this maybe a computer, managed service, or user account. Use setspn.exe to verify the SPN registration.

4.8.3 Changing the delegated login identitySee Section 3.3.4 for details of using an alternative login ID and the use of the delegated login identity.



0

For KCD to work the Kerberos ticket request must be made using the on-premises AD identity of the user. If an alternative login ID has been used, the Azure AD and on-premises AD identities will be different. For KCD to succeed the Azure AD App Proxy will need to retrieve the appropriate identity from either the onPremisesUserPrincipalName or onPremisesSamAccountName Azure AD attributes.These attributes are populated by the “Azure AD Connect” synchronization engine. Make sure you are using the latest version of Azure AD Connect to synchronize your on-premises AD to Azure AD.Make sure you have chosen the correct delegated login identity:

The KCD ID based on Delegated login identity (name shown in UI)

The Azure AD UPN User principal name

The on-premises UPN On-premises user principal name

The on-premises SAM account name On-premises SAM account name

The username part of the Azure AD UPN Username part of user principal name

The username part of the on-premises UPN Username part of on-premises user principal name

See Section 4.8.5 Scenario 4 for help with troubleshooting using a network trace.

4.8.4 Enabling SPNEGOCurrently the connector authenticates directly with the internal application using Kerberos v5. This works well with Windows servers but some Kerberos implementations, for instance on Apache, require the use of SPNEGO. SPNEGO is a negotiation protocol that allows a client and server to negotiate the authentication protocol to be used. Widows Negotiate is Microsoft’s implementation of SPNEGO and has been traditionally used to negotiate between Kerberos and NTLM. To support other implementations of Kerberos, SPNEGO can be enabled via the registry. Despite being a negotiation mechanism the only authentication protocol that is supported by the connector in this configuration is Kerberos and SPNEGO is simply providing a wrapper that allows the third-party Kerberos implementation to work.To enable SPNEGO modify the registry on the server(s) running the connector(s). Run the following command at an administrative command prompt:REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft AAD App Proxy Connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1


0

You will need to restart the Microsoft AAD Application Proxy Connector service after making the registry change.

SPNEGO has been added after the initial release of the connector and because Windows servers should be able to work with it enabled, it is possible that SPNEGO will become enabled as the default.

The only way you can see the difference between SPNEGO being enabled or not enabled is to view the get request to the server and expand the Authorization: Negotiate node. Figure 52 shows the OID as Kerberos 5 and Figure 53 shows the OID as SPNEGO.

Figure 52: SPNEGO not enabled

Figure 53: SPNEGO enabled


0

4.8.5 Analyzing Kerberos trafficSometimes people spend hours/days trying to get something to work by changing different configuration values and stumbling around in the dark. In many instances a network trace will immediately provide you with answers. Most of the time you can gain the necessary insight into the problem through a simple capture and analysis without the need to drilldown into the minutiae of the trace. In the examples given in this section Wireshark is being used to perform the network capture, use whatever tool you are familiar with.In the captured example, a Kerberos application http://wia.xtseminars.com is published by the Azure AD App Proxy as https://wia.xtseminars.com. HTTPS is required on the external URL for preauthentication. The first traces have been captured when our user [email protected] has preauthenticated via Azure AD and successfully accessed the application. The capture has been taken on the server running the connector. The computers involved have the following IP addresses:

Computer IP address

Domain controller (KDC) 10.50.0.11

Server running the connector (addproxy1$) 10.50.0.50

Application - wia.xtseminars.com 10.50.0.13

The Azure AD App Proxy caches Kerberos tokens, consequently if the tokens are available from cache you will not see the traces as illustrated in the following discussion. The cache can take up to 18 minutes to fully clear.If you make changes, those changes may not be happen until the cache has flushed.


0

Figure 54: Kerberos traffic between the connector and the domain controller

Figure 54 shows the Kerberos traffic between the connector and the KDC. Frame 277 is where the connector get a session ticket to the application. Once the connector has the session ticket it can send a HTTP GET to the application with the session ticket in the header, this can be seen in Figure 55. The network traces match the flow shown in Figure 11 (Section 3.3.3 ) between the connector and the application and is described in the text that accompanies the figure.In Figure 55 you will notice that the header Authorization: Negotiate starts YII which indicates that it is a Kerberos header.

Figure 55: HTTP traffic to the internal application

The following traces show more details of the top-level trace shown in Figure 54. Before troubleshooting problems it is good to understand how to read a good trace, make sure you review section 3.3.3 to help you understand the traces. Figure 56 shows an AS-REQ to authenticate our user Jill, the request has been expanded and the user name is shown under the cname field. An AS-REP indicating that preauthentication is required confirms that the account exists and is active. Although the AS-REP is an error it is treated as a positive confirmation of the account being active. Other error messages will indicate the account doesn’t exist or is disabled.


0

Figure 56: AS-REQ for [email protected]

Figure 57 show that TGS-REQ for a ticket to self (the connector: addproxy1$). Although you cannot see the user on whose behalf the ticket is being requested in the TGS-REQ the username can be seen under the cname field in the TGS-REP, see Figure 58.


0

Figure 57: TGS-REQ for ticket to self (the connector: addproxy1$)

Figure 58: TGS-REP showing principal [email protected]

Figure 59 the TGS-REQ for a ticket to the application, identified by the SPN http/wia.xtseminars.co.uk. As before you cannot see the username in the request but it is visible in the reply.


0

Figure 59: TGS-REQ for ticket to http/wia.xtseminars.com

Once you understand the baseline performance it is easy to use the network trace to help identify and troubleshoot problems as the following scenarios illustrate.

Scenario 1After preauthenticating as [email protected] the proxy responds with the webpage as shown in Figure 60.

This corporate app can't be accessed.If you continue to get this error, contact your IT department.Azure AD Application ProxyStatus code: BadGatewayUrl: https://wia.xtseminars.com/TransactionID: 6a8b2990-a918-4c7c-9bfe-4868ad395fecTimestamp: 9/4/2015 1:08:41 PM

An error occurred. Check the Application Proxy Connector Event Log for reported errors

Figure 60: Scenario 1 - response after login as [email protected]


0

On checking the connector event log you see a warning and a red-eye. Both error messages are very similar and the text is shown in Figure 61.

Web Application Proxy encountered an unexpected error while processing the request.Error: Account restrictions are preventing this user from signing in. For example: blank passwords aren't allowed, sign-in times are limited, or a policy restriction has been enforced.

Figure 61: Scenario 1 - connector Admin event log

From the error message it is not intuitively obvious what is wrong. However a network trace as shown in Figure 62 immediately indicates the problem.

Figure 62: Network trace showing the account is disabled

Once Jill’s account is enabled in the AD everything works as planned. You might be wondering how Jill managed to preauthenticate if her AD account was disabled. The fact is that the synchronization from the on-premises AD to the Azure AD can take a number of hours. During that time Jill can preauthenticate with the Azure AD even though her on-premises AD account is disabled.


This corporate app can't be accessed, contact your IT department.Azure AD Application ProxyStatus code: BadGatewayUrl: https://wia.xtseminars.com/TransactionID: fccc014d-2d13-4ddd-8ec3-f45438d4ae52


0

Timestamp: 9/4/2015 1:49:50 PM

Incorrect Kerberos constrained delegation configuration in your on-premises Active Directory


On checking the connector event log you see a warning and a red-eye. On reviewing both messages the warning text is a little more informative and shown in Figure 64.

Microsoft AAD Application Proxy Connector cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: No credentials are available in the security package.


From the error message it is not intuitively obvious what is wrong. This time a network trace (Figure 65) shows that the TGS-REQ for a ticket to the application is missing.

Figure 65: TGS-REQ for the Kerberos session ticket to the application is missing.

According to the network trace things appear to be working, however the request for a session ticket to the application on behalf of the user is missing. What could block a request for a session ticket on behalf of Jill? The answer is the Jill’s account in the on-premises AD has been marked as “sensitive and cannot be delegated”

Scenario 3After preauthenticating as [email protected] the proxy responds with the webpage as shown in Figure 66


0

This corporate app can't be accessed, contact your IT department.Azure AD Application ProxyStatus code: BadGatewayUrl: https://wia.xtseminars.com/TransactionID: 26efb014-8f2e-4c5d-8552-914abb1a3cb9Timestamp: 9/4/2015 2:41:31 PM

The SPN provided in the published application in Azure AD doesn't match the SPN of the backend application that is configured for constrained delegation in your on-premises Active Directory.


From this we can see that there is something wrong with the SPN. On checking the connector event log you see a warning and a red-eye. On reviewing both messages the warning text is a little more informative and shown in Figure 67.

Microsoft AAD Application Proxy Connector cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: The specified target is unknown or unreachable


So it is clear that there is an SPN issue, but what SPN is being requested? This time a network trace (Figure 68) shows that the TGS-REQ for a ticket to the application is using a SPN of http/wias.xtseminars.com, an obvious typo but now we know what we are looking for.


0

Figure 68: TGS-REQ using the wrong SPN.

Although in this particular instance we might have been able to trace the problem using the error messages and checking the configuration. It is really useful to have a clear understanding of what SPN is being requested and the fact that the KRB Error shows that the service principal is unknown. The problem could be misconfiguration of the Azure AD App proxy or the fact that the SPN had not been correctly registered in the AD. If the SPN was not correctly registered in the AD you should chastise yourself for not testing the application from the intranet before publishing through the proxy!


0


This corporate app can't be accessed, contact your IT department.Azure AD Application ProxyStatus code: ForbiddenUrl: https://wia.xtseminars.com/TransactionID: 769c145c-1e4c-4d8e-bd75-155a3b026e2eTimestamp: 9/9/2015 11:29:54 AM

The user could not be authorized. Make sure the user is defined in your on-premises AD and that the user has access to the app in your on-premises AD


On checking the connector event log you see a warning and a red-eye. The accompanying text is shown in Figure 70.

Web Application Proxy encountered an unexpected error while processing the request.Error: The user name or password is incorrect.


Seeing as the user just successfully logged on to Azure AD using their username and password this might strike you as a strange message. However, if we consider that during KCD a Kerberos login is performed, we need to investigate what login name is being used to request the Kerberos token. A network trace (Figure 71) immediately shows us the problem. The wrong username is being used in the AS-REQ. The on-premises UPN should be [email protected] whereas [email protected] the alternative login ID is being used. The Azure AD App Proxy configuration needs to specify the “On-premises user principal name” as the delegated login identity. For more details on the alternative login ID and delegated login identity see Sections 3.3.4 & 4.8.3.


0

Figure 71: Invalid username

Use the techniques you have learned in this section to aid your troubleshooting endeavors.


0

4.9 Tracing with FiddlerThis section shows how Fiddler can be used to trace the authentication flows for the Azure AD preauthentication and claims aware applications. Fiddler is a free web debugging proxy which can be downloaded from http://www.telerik.com/fiddler. See the website and related resources for help and tutorials on using Fiddler. A book is available “Debugging with Fiddler” by Eric Lawrence who created the tool.

This whitepaper cannot not endorse the suitability of the tool for your environment. Downloading the tool, installing and using it should only be done at your own risk after you have evaluated and security checked the tool in a test environment.

Fiddler acts as a proxy and therefore a man-in-the-middle, using spoof certificates Fiddler can intercept and decrypt HTTPS traffic.

Fiddler can capture usernames and passwords and these can be saved in trace files. Make sure that you take the appropriate security precautions to protect credentials when using Fiddler.

This whitepaper shows the results obtained by using the tool. To understand how to use and configure the tool see the many online resources that are available, or you could always buy the book!

4.9.1 Why use Fiddler?If everything is working then there is no need to use Fiddler, however if things are not working as expected, Fiddler is an excellent tool to track down and locate problems. Section 3 showed many different scenarios and included the protocols flows, Fiddler can be used to confirm these.The most likely problems are due to incorrectly configuration and with Fiddler you can immediately see if URLs, relying party trust identifiers, wreply messages or claims are missing or misconfigured.It is recommended that you trace a working system to get familiar with the tool.

4.9.2 Preauthentication flowRefer to Section 3.2.1 to review the preauthentication flow, Figure 3 has been reproduced as Figure 72 to aid with the explanation given in this section. This


0

section shows you how Fiddler can be used to examine the exact details of the protocol flow.

Figure 72: Preauthentication flow (copy of Figure 3)

The complete authentication trace can be captured as shown in Figure 73, aadsts.xtseminars.com is a claims aware application and it triggers its own authentication. The left hand column in Fiddler shows the session numbering. In Figure 73 session # 10 is where the first GET is made to the application after preauthentication is complete. This corresponds to step 9 in Figure 72.


0

Figure 73: Complete authentication trace

The following figures go into the details of the sessions shown in the Fiddler trace.

Session #2


0

Figure 74: GET request & redirect response

Figure 74 shows the initial get request to the published external URL for the application. This is shown as Step 1 in Figure 72. This request is intercepted by the proxy and because there no cookie which identifies the request as being authenticated a redirect is returned, this is shown as Step 2 in Figure 72.An authentication string as shown in Figure 75 is appended to the URL. You can also see that an AzureAppProxyAnalysticCookie is set and this is used by Azure to track activity on the proxy.The details of the authentication string and the interaction with Azure AD is something that you have no control over and it is Microsoft’s responsibility to maintain and run this. However for those of you that are familiar with OAuth 2.0 and OpenID Connect, you can see that the response type=code. This means that Azure AD will return a code to the browser once the user is authenticated.

https://login.windows.net/ab0a45c7-c085-4f3f-a868-62f3927926ef/oauth2/authorize?response_type=code&


0

client_id=777259d2-af0b-4b8e-a905-1c4d35076c8f&scope=openid&nonce=ee217022-a31e-476e-a780-a8ba0c3d5b48&redirect_uri=https://aadsts.xtseminars.com/&state=AppProxyState:{"IsMsofba":false,"OriginalQuery":""}

Figure 75: Decoded - OpenID Connect authentication string

As we have no control over the behavior of Azure AD we are going to skip to where the user has completed authentication.

Session #8

Figure 76: The user has completed authentication

Figure 76 show the response after the user has completed authentication. This is shown as Step 4 in Figure 72. Notice the cookies that have been set, the authentication cookies will allow the browser to automatically authenticate to Azure


0

AD for as long as the cookie remain valid. The redirect is to the external URL of the application and includes a “code”.The redirect sends the code to the proxy, the proxy then communicates directly, via a back-channel, with Azure AD and obtains a token (JWT). Provided the token is valid it is proof that the user is authenticated. The Proxy sets the AzureAppProxyAccessCookie and redirects to the external URL of the application, this is shown in Figure 77.

Session #9

Figure 77: Setting the AzureAppProxyAccessCookie

The GET request to the application includes the AzureAppProxyAccessCookie, see Figure 78. The proxy see the request as authenticated and passes it on to the application, step 9 in Figure 72. The application then implements its own authentication mechanism.


0

Session #10

Figure 78: Get request passed to application

4.9.3 Claims aware applicationsThere are many different scenarios that can be traced for authentication of a claims-aware application and these are covered in Section 3. In this section we are going to look at tracing a claims-aware application that trusts Azure AD as its security token service (STS). Using similar techniques you can trace any of the scenarios shown in Section 3.

In this section we will follow on from the preauthentication that was traced in Section 4.9.2. The protocol flow diagram, Figure 23, from Section 3.5 is reproduced here for your convenience. Please review Section 3.5 for more details. The Fiddler session numbers are taken from Figure 73.


0

Figure 79: Authenticating to app1, where app1 trusts Azure AD as the IdP (copy of Figure 23)

After the get request is received by the application. The application checks for its own authentication cookies and if none are present redirects to the STS, Azure AD. This redirect is shown in Figure 80. As part of the redirect the authentication string for the application is included. This can be seen in Figure 81. The URL redirects to the Azure AD endpoint with a WSFederation authentication request see Section 3.4 for more details.


0

Session #10

Figure 80: Application redirecting to Azure AD

https://login.windows.net/ab0a45c7-c085-4f3f-a868-62f3927926ef/wsfed?wa=wsignin1.0&wtrealm=http://aadsts.xtseminars.com&wctx=rm=0&id=passive&ru=%2F&wct=2015-09-07T11:34:51Z&wreply=https://aadsts.xtseminars.com/?ClaimAwareAAD5F09D25F-4423-4C2C-AE2A-2B92511B0671=ae5af22e-ef79-4306-b143-c7ea9c227e00

Figure 81: Decoded application authentication string


0

The Azure AD reads the authentication string and redirects to login.microsoft.com. The subsequent get request includes the Azure AD authentication cookies because the user has already preauthenticated against Azure AD, see Figure 82.

Session #12

Figure 82: Azure Authentication cookies included

After validating the authentication cookies, Azure AD creates a SAML token containing the user’s claims and returns this in a hidden form as described in Section 3.4 and shown in Figure 16. The returned webpage can be viewed by clicking on the Fiddler WebView button, it will just show a submit button as the JavaScript will not run and automatically submit the hidden form. To see the raw data click TextView and “View in Notepad”, you will be able to see the claims in the SAML token as shown in Figure 83.


0

Figure 83: Viewing the claims

Alternatively you can add a Fiddler inspector that will display the SAML token. The inspector is referenced here: http://social.technet.microsoft.com/wiki/contents/articles/3590.fiddler-inspector-for-federation-messages.aspx and the results are shown in Figure 84.

Figure 84: Federation inspector


0

After the SAML token is returned the JavaScript runs and posts it to the application. The application validates the SAML token and extracts the claims and sets authentication cookies. A redirect then sends the request back to the application with the authentication cookies set. The users is seen as authenticated and the webpage rendered, see Figure 85.

Session #12

Figure 85: Authenticated to the application


0

4.10 Azure AD object naming for published applications

In this scenario the claims-aware application trusts the Azure AD to authenticate the user, this is shown in the following diagram, Figure 86.

Figure 86: Publishing a claims-aware application

The first task is to create an application in Azure to allow APP1 to authenticate against the Azure AD. This is done through the portal: select your Azure AD, select APPLICATIONS and ADD. Choose “Add an application my organization is developing”. In the ensuing dialogs, enter a suitable name and then the application URL and a unique application URI. Often the URL is used as the URI, after all it is unique. This is shown in Figure 87.


0

Figure 87: Creating the application in Azure

Once the application has been created in Azure, the application developer can pick up the appropriate configuration information from the Azure portal to complete the configuration of the application. Depending on the type of authentication the application is using this may involve getting the federation metadata URL, client ID and client secret. After the configuration is complete the application can be tested from the intranet.

Always test you application works on the intranet before attempting to publish through the AAD App Proxy.

After the application has been tested, it’s back to the Azure portal to create the AAD App Proxy. Select your Azure AD, select APPLICATIONS and ADD. Choose “Publish an application that will be accessible from outside your network”. In the ensuing dialog add a suitable name and the internal URL of your application. Figure 88. At this stage you cannot set the external URL, this has to be done once the AAD App Proxy has been created.


0

Figure 88: Creating the AAD App Proxy

Once the AAD App Proxy has been created select the object in the portal and click CONFIGURE. You can set the external URL. A SSL cert can be uploaded after the configuration is saved.

Figure 89: Changing the external URL

Click save and the update will fail, Figure 90. Sometimes you have to love Microsoft error messages!


0

Figure 90: Saving the changes

The problem is caused by a conflict in the Azure AD. When you create an application in the directory it is represented by a ServicePrincipal which you can view using PowerShell. Figure 91

Figure 91: Before changing the external URL of the AAD App Proxy

One of the ServicePrincipalNames for the application is derived from the applications URI https://aadsts.xtseminars.com and one of the ServicePrincipalNames for the AAD App Proxy is derived from the external URL https://aadstsproxy-xtsad.msappproxy.net/. If the proxy’s external URL is set to


0

https://aadsts.xtseminars.com there is a ServicePrincipalName conflict and the update is not performed.To solve the problem set the application URI to a different value. You could use http://aadsts.xtseminars.com (http rather than https).After setting the APP URI to http://aadsts.xtseminars.com, test the application from the intranet. You may see the error as shown in Figure 92. Of course you immediately know what the problem is! You forgot to tell your application developer to update the “realm” value in the application (if you remembered, well done). A request is being made to Azure to authenticate the user for https://aadsts.xtseminars.com and that application no longer exists in the Azure AD. The application is now identified by http://aadsts.xtseminars.com.

Figure 92: Authentication to the application fails

Once the application is fixed and tested on the intranet, it’s back to the portal to update the AAD App Proxy external URL. This time the update works and an SSL cert can be uploaded.


0

Figure 93: After changing the external URL of the AAD App Proxy


whitepaperdownload.microsoft.com › download › 3 › e › 3 › 3e335d… · web...

Documents