Whitepaper



-123825-914400Whitepaper00WhitepaperTroubleshooting the Azure Active Directory Application ProxyOctober 2015Prepared forMicrosoftAuthorJohn Craddock, XTSeminars LtdIdentity and security architectjohncra@xtseminars.co.ukTable of Contents TOC \o "1-3" \h \z \u List of Figures PAGEREF _Toc433191146 \h 6List of Tables PAGEREF _Toc433191147 \h 101Purpose of this whitepaper PAGEREF _Toc433191148 \h 111.1Naming PAGEREF _Toc433191149 \h 111.2What is not covered PAGEREF _Toc433191150 \h 111.3How to use this document for troubleshooting PAGEREF _Toc433191151 \h 112Introduction PAGEREF _Toc433191152 \h 122.1What is the AAD App Proxy? PAGEREF _Toc433191153 \h 122.2Relationship of Azure AD and on-premises AD PAGEREF _Toc433191154 \h 122.2.1No relationship between Azure AD and on-premises AD PAGEREF _Toc433191155 \h 122.2.2On-premises AD users synchronized in to Azure AD and UPN used for identity PAGEREF _Toc433191156 \h 122.2.3On-premises AD users synchronized in to Azure AD and an alternative attribute used for identity PAGEREF _Toc433191157 \h 122.2.4Federated SSO PAGEREF _Toc433191158 \h 133AAD App Proxy scenarios PAGEREF _Toc433191159 \h 143.1Passthrough (no preauthentication) PAGEREF _Toc433191160 \h 163.2Azure AD preauthentication PAGEREF _Toc433191161 \h 173.2.1Preauthentication details PAGEREF _Toc433191162 \h 183.3Kerberos authentication to the internal application PAGEREF _Toc433191163 \h 223.3.1Kerberos configuration PAGEREF _Toc433191164 \h 233.3.2Kerberos in a nutshell. PAGEREF _Toc433191165 \h 243.3.3Kerberos authentication via the AAD App Proxy PAGEREF _Toc433191166 \h 273.3.4Alternative login ID and delegate login identities PAGEREF _Toc433191167 \h 293.4Publishing a claims-aware application PAGEREF _Toc433191168 \h 313.4.1AD FS reply address (wreply) PAGEREF _Toc433191169 \h 353.4.2SSO for published claims-aware applications PAGEREF _Toc433191170 \h 383.5Publishing a claims-aware application that trusts the Azure AD PAGEREF _Toc433191171 \h 393.5.1Adding a resource AD FS server for claims enrichment PAGEREF _Toc433191172 \h 423.6Claims-aware application trusting ADFS with Azure AD Federated SSO PAGEREF _Toc433191173 \h 444Troubleshooting PAGEREF _Toc433191174 \h 494.1Troubleshooting checklist and signposts PAGEREF _Toc433191175 \h 494.2Publishing the application PAGEREF _Toc433191176 \h 524.2.1Application configuration PAGEREF _Toc433191177 \h 524.2.2Authorizing access through the proxy PAGEREF _Toc433191178 \h 524.2.3Assigning a user to the proxy application PAGEREF _Toc433191179 \h 554.2.4Assigning a license to a user PAGEREF _Toc433191180 \h 564.2.5Verify published paths PAGEREF _Toc433191181 \h 564.3DNS name resolution PAGEREF _Toc433191182 \h 594.3.1Internal FQDN for the published application PAGEREF _Toc433191183 \h 594.3.2External FQDN for published application PAGEREF _Toc433191184 \h 604.3.3Verifying the AD FS URLs PAGEREF _Toc433191185 \h 634.4The AAD App Proxy Connector PAGEREF _Toc433191186 \h 644.4.1Checking the functioning of the connector PAGEREF _Toc433191187 \h 654.4.2Checking the connector event logs PAGEREF _Toc433191188 \h 674.5Authentication to the application PAGEREF _Toc433191189 \h 694.5.1SSO Authentication PAGEREF _Toc433191190 \h 694.5.2NTLM Authentication PAGEREF _Toc433191191 \h 694.5.3Kerberos authentication PAGEREF _Toc433191192 \h 714.6Certificates PAGEREF _Toc433191193 \h 754.7Host header translation PAGEREF _Toc433191194 \h 764.8Kerberos configuration PAGEREF _Toc433191195 \h 774.8.1Configuring Kerberos delegation for the connector PAGEREF _Toc433191196 \h 774.8.2Internal Application SPN PAGEREF _Toc433191197 \h 774.8.3Changing the delegated login identity PAGEREF _Toc433191198 \h 784.8.4Enabling SPNEGO PAGEREF _Toc433191199 \h 784.8.5Analyzing Kerberos traffic PAGEREF _Toc433191200 \h 804.9Tracing with Fiddler PAGEREF _Toc433191201 \h 914.9.1Why use Fiddler? PAGEREF _Toc433191202 \h 914.9.2Preauthentication flow PAGEREF _Toc433191203 \h 924.9.3Claims aware applications PAGEREF _Toc433191204 \h 974.10Azure AD object naming for published applications PAGEREF _Toc433191205 \h 103List of Figures TOC \h \z \c "Figure" Figure 1: Publishing an application with no preauthentication PAGEREF _Toc433191206 \h 16Figure 2: Publishing an application with preauthentication PAGEREF _Toc433191207 \h 17Figure 3: Preauthentication flow PAGEREF _Toc433191208 \h 19Figure 4: Example of JWT (tenant ID obfuscate) PAGEREF _Toc433191209 \h 21Figure 5: Viewing the Azure AD service principle PAGEREF _Toc433191210 \h 21Figure 6: Kerberos authentication to the internal application PAGEREF _Toc433191211 \h 22Figure 7: Internal authentication method PAGEREF _Toc433191212 \h 23Figure 8: Enabling Kerberos delegation PAGEREF _Toc433191213 \h 24Figure 9: Accessing app1 using Kerberos PAGEREF _Toc433191214 \h 25Figure 10: Constrained delegation PAGEREF _Toc433191215 \h 26Figure 11: Kerberos protocol transition with constrained delegation PAGEREF _Toc433191216 \h 28Figure 12: Publishing a claims-aware application PAGEREF _Toc433191217 \h 31Figure 13: Using two different IdPs PAGEREF _Toc433191218 \h 32Figure 14: Authenticating to app1, where app1 trusts AD FS as the IdP PAGEREF _Toc433191219 \h 33Figure 15: WS-Federation redirect to the AD FS server PAGEREF _Toc433191220 \h 34Figure 16: Web page including hidden form PAGEREF _Toc433191221 \h 35Figure 17: AD FS relying party endpoint PAGEREF _Toc433191222 \h 36Figure 18: POST back URL from hidden form in Step 12 of Figure 14 PAGEREF _Toc433191223 \h 36Figure 19: Redirect URL – with app1 published as proxyapp1. PAGEREF _Toc433191224 \h 37Figure 20: AAD App Proxy endpoint added as AD FS relying party endpoint PAGEREF _Toc433191225 \h 37Figure 21: POST back URL set via wreply parameter PAGEREF _Toc433191226 \h 38Figure 22: Publishing a claims-aware application that trusts the Azure AD PAGEREF _Toc433191227 \h 39Figure 23: Authenticating to app1, where app1 trusts Azure AD as the IdP PAGEREF _Toc433191228 \h 40Figure 24: Adding a resource AD FS server for claims enrichment PAGEREF _Toc433191229 \h 42Figure 25: Claims enrichment PAGEREF _Toc433191230 \h 43Figure 26: Claims-aware application trusting ADFS with Azure AD Federated SSO PAGEREF _Toc433191231 \h 44Figure 27: Preauthentication with Azure AD federated SSO – part 1 PAGEREF _Toc433191232 \h 45Figure 28: Preauthentication with Azure AD federated SSO – part 2 PAGEREF _Toc433191233 \h 46Figure 29: Authentication to app1 PAGEREF _Toc433191234 \h 47Figure 30: User not authorized for access PAGEREF _Toc433191235 \h 53Figure 31: Error message - user not authorized for access PAGEREF _Toc433191236 \h 53Figure 32: Preauthentication flow from Section 3.2.1 PAGEREF _Toc433191237 \h 54Figure 33: Error message - user authorized, but not licensed PAGEREF _Toc433191238 \h 55Figure 34: Accessing the published site with Chrome PAGEREF _Toc433191239 \h 57Figure 35: Accessing a site that is not published PAGEREF _Toc433191240 \h 57Figure 36: Using the developer tools PAGEREF _Toc433191241 \h 58Figure 37: Resolving the FQDN using nslookup PAGEREF _Toc433191242 \h 60Figure 38: CNAME required for the external FQDN PAGEREF _Toc433191243 \h 61Figure 39: Resolving the FQDN with multiple aliases PAGEREF _Toc433191244 \h 62Figure 40: Connector status PAGEREF _Toc433191245 \h 65Figure 41: Connector time out PAGEREF _Toc433191246 \h 66Figure 42: Port 1010 blocked PAGEREF _Toc433191247 \h 66Figure 43: The connector event logs PAGEREF _Toc433191248 \h 68Figure 44: Disable automatic logon PAGEREF _Toc433191249 \h 70Figure 45: Kerberos session ticket to wia. PAGEREF _Toc433191250 \h 71Figure 46: NTLM authentication PAGEREF _Toc433191251 \h 72Figure 47: Kerberos authentication PAGEREF _Toc433191252 \h 72Figure 48: Authentication via NTLM PAGEREF _Toc433191253 \h 73Figure 49: Authentication via Kerberos PAGEREF _Toc433191254 \h 74Figure 50: IIS site bindings PAGEREF _Toc433191255 \h 76Figure 51: Properties of the computer object PAGEREF _Toc433191256 \h 77Figure 52: SPNEGO not enabled PAGEREF _Toc433191257 \h 79Figure 53: SPNEGO enabled PAGEREF _Toc433191258 \h 80Figure 54: Kerberos traffic between the connector and the domain controller PAGEREF _Toc433191259 \h 81Figure 55: HTTP traffic to the internal application PAGEREF _Toc433191260 \h 82Figure 56: AS-REQ for jill@xtseminars.co.uk PAGEREF _Toc433191261 \h 83Figure 57: TGS-REQ for ticket to self (the connector addproxy1$) PAGEREF _Toc433191262 \h 83Figure 58: TGS-REP showing principal jill@xtseminars.co.uk PAGEREF _Toc433191263 \h 84Figure 59: TGS-REQ for ticket to http/wia. PAGEREF _Toc433191264 \h 84Figure 60: Scenario 1 - response after login as jill@xtseminars.co.uk PAGEREF _Toc433191265 \h 85Figure 61: Scenario 1 - connector Admin event log PAGEREF _Toc433191266 \h 85Figure 62: Network trace showing the account is disabled PAGEREF _Toc433191267 \h 85Figure 63: Scenario 2 - response after login as jill@xtseminars.co.uk PAGEREF _Toc433191268 \h 86Figure 64: Scenario 2 - connector Admin event log PAGEREF _Toc433191269 \h 86Figure 65: TGS-REQ for the Kerberos session ticket to the application is missing. PAGEREF _Toc433191270 \h 87Figure 66: Scenario 3 - response after login as jill@xtseminars.co.uk PAGEREF _Toc433191271 \h 87Figure 67: Scenario 3 - connector Admin event log PAGEREF _Toc433191272 \h 88Figure 68: TGS-REQ using the wrong SPN. PAGEREF _Toc433191273 \h 88Figure 69: Scenario 4 - response after login as mike@xtseminars.co.uk PAGEREF _Toc433191274 \h 89Figure 70: Scenario 4 - connector Admin event log PAGEREF _Toc433191275 \h 89Figure 71: Invalid username PAGEREF _Toc433191276 \h 90Figure 72: Preauthentication flow (copy of Figure 3) PAGEREF _Toc433191277 \h 92Figure 73: Complete authentication trace PAGEREF _Toc433191278 \h 93Figure 74: GET request & redirect response PAGEREF _Toc433191279 \h 94Figure 75: Decoded - OpenID Connect authentication string PAGEREF _Toc433191280 \h 95Figure 76: The user has completed authentication PAGEREF _Toc433191281 \h 95Figure 77: Setting the AzureAppProxyAccessCookie PAGEREF _Toc433191282 \h 96Figure 78: Get request passed to application PAGEREF _Toc433191283 \h 97Figure 79: Authenticating to app1, where app1 trusts Azure AD as the IdP (copy of Figure 23) PAGEREF _Toc433191284 \h 98Figure 80: Application redirecting to Azure AD PAGEREF _Toc433191285 \h 99Figure 81: Decoded application authentication string PAGEREF _Toc433191286 \h 99Figure 82: Azure Authentication cookies included PAGEREF _Toc433191287 \h 100Figure 83: Viewing the claims PAGEREF _Toc433191288 \h 101Figure 84: Federation inspector PAGEREF _Toc433191289 \h 101Figure 85: Authenticated to the application PAGEREF _Toc433191290 \h 102Figure 86: Publishing a claims-aware application PAGEREF _Toc433191291 \h 103Figure 87: Creating the application in Azure PAGEREF _Toc433191292 \h 104Figure 88: Creating the AAD App Proxy PAGEREF _Toc433191293 \h 105Figure 89: Changing the external URL PAGEREF _Toc433191294 \h 105Figure 90: Saving the changes PAGEREF _Toc433191295 \h 106Figure 91: Before changing the external URL of the AAD App Proxy PAGEREF _Toc433191296 \h 106Figure 92: Authentication to the application fails PAGEREF _Toc433191297 \h 107Figure 93: After changing the external URL of the AAD App Proxy PAGEREF _Toc433191298 \h 108List of Tables TOC \h \z \c "Table" Table 1: AAD App Proxy endpoint and application endpoint behaviors PAGEREF _Toc433191299 \h 15Table 2: No preauthentication PAGEREF _Toc433191300 \h 16Table 3: AAD App Proxy preauthentication PAGEREF _Toc433191301 \h 18Table 4: Kerberos authentication to the internal application PAGEREF _Toc433191302 \h 23Table 5: Selecting the KCD identity PAGEREF _Toc433191303 \h 30Table 6: Troubleshooting steps and signposts PAGEREF _Toc433191304 \h 50Table 7: Required outbound ports for the connector PAGEREF _Toc433191305 \h 64Table 8: Certificate troubleshooting tips PAGEREF _Toc433191306 \h 75Purpose 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 REF _Ref427757678 \r \h 3 of this whitepaper will give you detailed background of the different scenarios in which the Azure AD Application Proxy can be deployed. Section REF _Ref429584336 \r \h 4 provides you with tools and technical details that will allow you to succinctly troubleshoot problems. NamingThroughout the rest of this document the Azure AD Application Proxy is referred to as the AAD App Proxy.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. 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 REF _Ref427757678 \r \h 3 and then Section REF _Ref429584336 \r \h 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 REF _Ref427757678 \r \h 3 and focus on the sections that are appropriate to your scenario and then choose the appropriate steps from REF _Ref433199120 \h \* MERGEFORMAT Table 6 in Section REF _Ref429584336 \r \h 4.Once you are more familiar with troubleshooting, just dip in to the appropriate sections as necessary.IntroductionWhat 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. 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.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.On-premises AD users synchronized in to Azure AD and UPN used for identityUsers 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.On-premises AD users synchronized in to Azure AD and an alternative attribute used for identityThe 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 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 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.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.AAD App Proxy scenarios REF _Ref422988842 \h \* MERGEFORMAT Table 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. Table 1: AAD App Proxy endpoint and application endpoint behaviorsAAD App Proxy endpointConnectorApplication endpointProtocol1HTTP or HTTPS<------------->HTTP or HTTPSURL2 FQDN FQDN5<------------->http: custom URLhttps: custom URLThe URL6 can contain a hostname, IP address or FQDNAuthenticationNone or Authentication against Azure AD tenant7<------------->Anonymous, forms, basic digest, NTLM8, Kerberos9 or claimsHost header translationExternal FQDN<- Optional10,11 ->Internal FQDNNotes: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.All published URLs can include a path. The external and internal paths must be the same.When the URL is stemmed on 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).SSL for the domain is automatically supported through a Microsoft certificate.SSL for custom domains requires an appropriate certificate to be uploaded to Azure AD.The internal port to be used can be defined as part of the URL. For example the Azure tenant is configured for federated SSO the user can be authenticated against another identity provider. 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.Kerberos authentication requires the on-premises AAD App Proxy connector to be domain joined and configured for Kerberos Constrained Delegation The default is for translation it to be enabled.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: and ).Passthrough (no preauthentication)Figure SEQ Figure \* MERGEFORMAT 1: Publishing an application with no preauthenticationIn this scenario depicted in REF _Ref422988966 \h \* MERGEFORMAT 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 REF _Ref422989109 \h \* MERGEFORMAT Table 2 below for details of the protocol, authentication and authorization options. For other details see REF _Ref422989957 \h \* MERGEFORMAT Table 1: AAD App Proxy endpoint and application endpoint behaviors.Table 2: No preauthenticationAAD App Proxy endpointConnectorApplication endpointProtocolHTTP or HTTPS1<------------->HTTP or HTTPS1AuthenticationNone<------------->Anonymous, forms, basic digest, NTLM2 or claims3AuthorizationNone4 (Any user can access the endpoint)<------------->Controlled by applicationNotes: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.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.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.The user must have a Basic or Premium license, usage can be monitored and enforced if necessary.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.Azure AD preauthenticationFigure SEQ Figure \* MERGEFORMAT 2: Publishing an application with preauthenticationThis scenario is depicted in REF _Ref422989180 \h \* MERGEFORMAT Figure 2, app1 is published to the external network with preauthentication at the AAD App Proxy. Refer to REF _Ref422989921 \h \* MERGEFORMAT Table 3 below for details of the protocol, authentication and authorization options. For other details see REF _Ref422989957 \h \* MERGEFORMAT Table 1: AAD App Proxy endpoint and application endpoint behaviors.Table 3: AAD App Proxy preauthentication AAD App Proxy endpointConnectorApplication endpointProtocolHTTPS<------------->HTTP or HTTPS1Authentication2Authentication with Azure AD tenant3<------------->Anonymous, forms, basic digest, NTLM or claims4 AuthorizationUser must have a Basic or Premium Azure AD license and be assigned5 for access to the AAD App Proxy application endpoint<------------->Controlled by applicationNotes: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.SSO between the AAD App Proxy and the application is not supported for forms, basic digest or NTLM If the Azure tenant is configured for federated SSO the user can be authenticated with another identity provider. See Section REF _Ref427576441 \r \h 3.6 which shows Azure federated identity in action.Claims authentication when using AAD App Proxy preauthentication is detailed in Sections REF _Ref425419785 \r \h 3.4, REF _Ref428867413 \r \h 3.5 and REF _Ref427576441 \r \h 3.6. 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).Preauthentication detailsThe swim lanes as depicted in REF _Ref422990129 \h \* MERGEFORMAT 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 REF _Ref429584336 \r \h 4.In REF _Ref422990129 \h \* MERGEFORMAT Figure 3 it is assumed that the user has not already authenticated to any websites published by the proxy.Figure SEQ Figure \* MERGEFORMAT 3: Preauthentication flowProtocol flow:Get request to published application. The AAD App Proxy checks for a valid AzureAppProxyAccessCookie.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.The authentication method is Open ID Connect using an OAuth 2.0 code grant flow.Azure AD requests the user’s name and password and authenticates the user.The interaction with Azure AD is slightly more complex. Based on the user’s domain Azure AD willCheck 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 REF _Ref427576441 \r \h 3.6.If the user is not configured for federated SSO, display the Azure AD tenant branding page and prompt for login 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 token. Azure AD also returns a cookie that identifies that the user has been authenticated by Azure AD.The user’s browser redirects to the application with the code in the URL.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 REF _Ref422990429 \h \* MERGEFORMAT Figure 4 for an example of a JWT.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.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).The user must have an Azure AD Basic or Premium license.If the user is authenticated and authorized, the AAD App Proxy responds with a redirect to the application and sets an AzureAppProxyAccessCookie cookie. 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.If anonymous access is allowed to the application, the page is rendered.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.Example JWT{ "typ": "JWT", "alg": "RS256", "x5t": "MnC_VZcATfM5pOYiJHMba9goEKY", "kid": "MnC_VZcATfM5pOYiJHMba9goEKY"}{ "aud": "05020220-832c-47a1-b833-85716ab86e0a", "iss": "****-****-****-a868-********/", "iat": 1435128748, "nbf": 1435128748, "exp": 1435132648, "ver": "1.0", "tid": "ab0****-****-****-a868-********", "oid": "9838bd80-6c40-4f9e-bfee-131d3d9e7df1", "upn": "jill@xtseminars.co.uk", "sub": "YqGvvSuawWNp5bnLoWvCmj1cwRC2Awdh23sohdCPnc8", "given_name": "Jill", "name": "Jill", "amr": [ "pwd" ], "unique_name": "jill@xtseminars.co.uk", "onprem_sid": "S-1-5-21-1944609542-1844729179-2744045708-6105", "nonce": "fee424be-270f-4c12-b9e4-1407ac3fd04f", "pwd_exp": "6091062"}Figure SEQ Figure \* MERGEFORMAT 4: Example of JWT (tenant ID obfuscate)There are three parts of a JWT: header, body and signature. As can be seen in REF _Ref422990429 \h \* MERGEFORMAT 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, REF _Ref422990443 \h \* MERGEFORMAT Figure 5.ExtensionData : System.Runtime.Serialization.ExtensionDataObjectAccountEnabled : TrueAddresses : {Microsoft.Online.Administration.RedirectUri}AppPrincipalId : 05020220-832c-47a1-b833-85716ab86e0aDisplayName : WindowsAuthProxyObjectId : 19a28874-725f-4d16-9f9c-dd9c3aefc987ServicePrincipalNames : {, 05020220-832c-47a1-b833-85716ab86e0a}TrustedForDelegation : FalseFigure SEQ Figure \* MERGEFORMAT 5: Viewing the Azure AD service principleKerberos authentication to the internal applicationFigure SEQ Figure \* MERGEFORMAT 6: Kerberos authentication to the internal applicationIn this scenario, depicted in REF _Ref422990183 \h \* MERGEFORMAT 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 REF _Ref422990005 \h \* MERGEFORMAT Table 4 below for details of the protocol, authentication and authorization options. For other details see REF _Ref422990019 \h Table 1: AAD App Proxy endpoint and application endpoint behaviors.Table 4: Kerberos authentication to the internal applicationAAD App Proxy endpointConnectorApplication endpointProtocolHTTPS<------------->HTTP or HTTPSAuthenticationAuthentication against Azure AD tenant1<------------->Kerberos AuthorizationUser must have a Basic or Premium Azure AD license and be assigned2 for access to the AAD App Proxy endpoint<------------->Controlled by applicationNotes:If the Azure tenant is configured for federated SSO the user can be authenticated against another identity provider. See Section REF _Ref427576441 \r \h 3.6 which show Azure federated identity in action.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).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 REF _Ref422990214 \h \* MERGEFORMAT Figure 7. Figure SEQ Figure \* MERGEFORMAT 7: Internal authentication methodIn 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. REF _Ref422990236 \h \* MERGEFORMAT Figure 8.Figure SEQ Figure \* MERGEFORMAT 8: Enabling Kerberos delegationKerberos 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 REF _Ref422990263 \h \* MERGEFORMAT 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.Figure SEQ Figure \* MERGEFORMAT 9: Accessing app1 using KerberosProtocol flow:An AS-REQ is sent to the KDC to request user authentication.The KDC returns an error as it requires the AS-REQ to be preauthenticated. Preauthentication is performed by encrypting the client time with the user’s key.The requirement for preauthentication can be disabled in the AD.An AS-REQ with preauthentication is sent to the KDC.The KDC validates the timestamp and returns a Ticket Granting Ticket (TGT).The TGT is used to identify the user in all subsequent requests to the KDC.A TGS-REQ is sent requesting a Session Ticket (ST) to app1, the TGT is included in the request to identify the user.App1 is identified by a Service Principal Name (SPN).The KDC returns a ST (ST1) which is valid between the user and app1.An HTTP request is sent to app1 with ST1 encoded in the HTTP header. 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.Constrained delegation within a domainCross-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 REF _Ref422990302 \h \* MERGEFORMAT Figure 10. Figure SEQ Figure \* MERGEFORMAT 10: Constrained delegationThe protocol flow follows on from step 7 in REF _Ref422990366 \h \* MERGEFORMAT Figure 9: Accessing app1 using Kerberos. App1 now becomes the delegator:The user authenticates to the delegator (app1) using ST1 (repeated from REF _Ref422990263 \h Figure 9).The delegator (app1) uses ST1 to request a ST to app2The KDC checks the request and issues ST2 for authentication to app2 using the user’s identity.The KDC will only issue the session ticket if the request is for a service in the Allowed To Delegate To (A2D2) list.A session ticket will not be issued if the user account is marked as “Account is sensitive and cannot be delegated”.The delegator (app1) sends a HTTP request to app2 with ST2 encoded in the headerAPP2 validates the ST and returns the results.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 ( REF _Ref422990129 \h \* MERGEFORMAT Figure 3). The JWT includes the user’s UPN, see REF _Ref422990429 \h \* MERGEFORMAT 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 jill@xtseminars.co.uk, the UPN in the JWT ( REF _Ref422990429 \h \* MERGEFORMAT 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 REF _Ref429588242 \r \h 3.3.4. REF _Ref422990624 \h \* MERGEFORMAT 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. Figure SEQ Figure \* MERGEFORMAT 11: Kerberos protocol transition with constrained delegationThe protocol flow follows on from step 8 in REF _Ref422996235 \h \* MERGEFORMAT Figure 3: Preauthentication flow.As the result of a redirect, an HTTP request is sent to app1 with the AzureAppProxyAccessCookie set.To test the validity of the user account, an AS-REQ to authenticate the user represented by the UPN, is sent to the KDC.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.An AS-REP indicating that preauthentication is required confirms that the account exists and is active. Other error messages will indicate the account doesn’t exist or is disabled.A TGS-REQ is made to the KDC to obtain an ST to the AAD App Proxy (self) using the user’s identity.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.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.The session ticket to app1 with the user’s identity is returned and cached on the AAD App Proxy. This is shown as ST2.The AAD App Proxy redirects the user to the application.As the result of the redirect, an HTTP request is sent to app1 with the AzureAppProxyAccessCookie set.The AAD App Proxy creates an HTTP connection to app1 and encodes ST2 into the HTTP header.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.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 REF _Ref429572251 \h \* MERGEFORMAT 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.Table 5: Selecting the KCD identityThe KCD ID based onDelegated login identity (name shown in UI)The Azure AD UPNUser principal nameThe on-premises UPNOn-premises user principal nameThe on-premises SAM account nameOn-premises SAM account nameThe username part of the Azure AD UPNUsername part of user principal nameThe username part of the on-premises UPNUsername part of on-premises user principal namePublishing a claims-aware applicationFigure SEQ Figure \* MERGEFORMAT 12: Publishing a claims-aware applicationA 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 REF _Ref424917190 \h \* MERGEFORMAT 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.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 SEQ Figure \* MERGEFORMAT 13: Using two different IdPs The protocol flow is illustrated in REF _Ref425238438 \h \* MERGEFORMAT Figure 14. REF _Ref425238438 \h \* MERGEFORMAT 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. REF _Ref425238438 \h \* MERGEFORMAT Figure 14 starts from step 9 after the preauthentication to the AAD App Proxy depicted in REF _Ref422990129 \h \* MERGEFORMAT Figure 3.Figure SEQ Figure \* MERGEFORMAT 14: Authenticating to app1, where app1 trusts AD FS as the IdP The protocol flow follows on from step 8 in REF _Ref422996235 \h \* MERGEFORMAT Figure 3: Preauthentication flow.As the result of a redirect, an HTTP request is sent to app1 with the AzureAppProxyAccessCookie set. The AAD App Proxy accepts the cookie as proof that the user has been preauthenticated and passes the request to the application.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 REF _Ref425314456 \h \* MERGEFORMAT Figure 15.wtrealm identifies the application (relying party) to AD FS.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.wct is a time stamp.wreply is appended by the AAD App Proxy. See Section REF _Ref425315039 \r \h 3.4.1 for more details.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:Home realm discovery if the AD FS server trusts more than one claims provider.Forms authentication.Multi-factor authentication.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 REF _Ref425322561 \h \* MERGEFORMAT 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.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.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. 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. SEQ Figure \* MERGEFORMAT 15: WS-Federation redirect to the AD FS server Figure SEQ Figure \* MERGEFORMAT 16: Web page including hidden form AD FS reply address (wreply)As seen in REF _Ref425314456 \h \* MERGEFORMAT 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 REF _Ref425316379 \h \* MERGEFORMAT Figure 17 & REF _Ref425317151 \h \* MERGEFORMAT Figure 18.Figure SEQ Figure \* MERGEFORMAT 17: AD FS relying party endpoint <form method="POST" name="hiddenform" action="">Figure SEQ Figure \* MERGEFORMAT 18: POST back URL from hidden form in Step 12 of REF _Ref425238438 \h 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. REF _Ref425350513 \h \* MERGEFORMAT Figure 19 shows the wreply parameter when app1 is published externally as proxyapp1.. SEQ Figure \* MERGEFORMAT 19: Redirect URL – with app1 published as proxyapp1. 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 REF _Ref425406908 \h \* MERGEFORMAT Figure 20 and REF _Ref425407238 \h \* MERGEFORMAT Figure 21.Figure SEQ Figure \* MERGEFORMAT 20: AAD App Proxy endpoint added as AD FS relying party endpoint<form method="POST" name="hiddenform" action="">Figure SEQ Figure \* MERGEFORMAT 21: POST back URL set via wreply parameterSSO 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 ADThis is a special case that uses a resource AD-FS server for claims enrichment.Also used if AD FS has already been implemented for applicationsThe 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.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. Publishing a claims-aware application that trusts the Azure ADFigure SEQ Figure \* MERGEFORMAT 22: Publishing a claims-aware application that trusts the Azure ADIn this scenario, depicted in REF _Ref424905310 \h \* MERGEFORMAT 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 REF _Ref422990129 \h \* MERGEFORMAT 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. REF _Ref425433664 \h \* MERGEFORMAT 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 federated protocols. REF _Ref425433664 \h \* MERGEFORMAT Figure 23 starts from step 9 after the preauthentication depicted in REF _Ref422990129 \h \* MERGEFORMAT Figure 3.Figure SEQ Figure \* MERGEFORMAT 23: Authenticating to app1, where app1 trusts Azure AD as the IdP The protocol flow follows on from step 8 in REF _Ref422996235 \h \* MERGEFORMAT Figure 3: Preauthentication flow.As the result of a redirect, an HTTP request is sent to app1 with the AzureAppProxyAccessCookie set. The AAD App Proxy accepts the cookie as proof that the user has been preauthenticated and passes the request to the application.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. Azure AD receives the request along with authentication cookies that were set during the preauthentication to the AAD App Proxy.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 REF _Ref425419785 \n \h 3.4Provided the authentication cookies are valid no additional authentication is required by the using. This provides SSO to the AAD App Proxy and the application, subject to the AAD App Proxy and application having the same authentication policy.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.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. 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.Adding a resource AD FS server for claims enrichmentFigure SEQ Figure \* MERGEFORMAT 24: Adding a resource AD FS server for claims enrichmentThis is a special case where the application trusts an AD FS server which in turn trusts Azure AD, see REF _Ref427575101 \h \* MERGEFORMAT 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 REF _Ref425433664 \h \* MERGEFORMAT 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 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 REF _Ref425433296 \h \* MERGEFORMAT Figure 25. Using this method it is possible to create a security token with a rich set of claims targeted for specific applications. Figure SEQ Figure \* MERGEFORMAT 25: Claims enrichmentNote: 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.Claims-aware application trusting ADFS with Azure AD Federated SSOFigure SEQ Figure \* MERGEFORMAT 26: Claims-aware application trusting ADFS with Azure AD Federated SSOUnder 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. REF _Ref425438459 \h \* MERGEFORMAT Figure 26 shows the trust paths. The protocol flow for preauthentication to the AAD App Proxy is shown in REF _Ref427729993 \h \* MERGEFORMAT Figure 27 and REF _Ref427729839 \h \* MERGEFORMAT 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.Figure SEQ Figure \* MERGEFORMAT 27: Preauthentication with Azure AD federated SSO – part 1Protocol flow:Get request to published application. The AAD App Proxy checks for a valid AzureAppProxyAccessCookie.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.The authentication method is Open ID connect using an OAuth 2.0 code grant flow.Azure AD receives the authentication request and prompts for the user’s name and password. 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 REF _Ref427729993 \h \* MERGEFORMAT Figure 27. The username parameter is set to the entered value.JavaScript running in the browser creates a GET request to the AD FS server using the details returned in Step 4. 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.The next part of the protocol flow is shown in REF _Ref427729839 \h \* MERGEFORMAT Figure 28.Figure SEQ Figure \* MERGEFORMAT 28: Preauthentication with Azure AD federated SSO – part 2Protocol flow continued:The token is POSTed back to Azure AD and validatedAzure 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.The user’s browser redirects to the application with the code in the URL.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.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.The user must be assigned for access through the AAD App Proxy.The user must have an Azure AD Basic or Premium license.If the user is authenticated and authorized, the AAD App Proxy responds with a redirect to the application and sets an AzureAppProxyAccessCookie cookie. 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.If anonymous access is allowed to the application, the page is rendered.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 SEQ Figure \* MERGEFORMAT 29: Authentication to app1 REF _Ref427750633 \h Figure 29 shows the protocol flow for authentication to the application: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. The AD FS receives the request along with the authentication cookies set in Step 6 above. The cookies are accepted as proof of authentication.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. 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.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. 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.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. 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 REF _Ref427757709 \r \h 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 REF _Ref427757678 \r \h 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.Troubleshooting checklist and signpostsRegardless of which of the scenarios shown in Section REF _Ref427757709 \r \h 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 REF _Ref428254911 \r \h 4.8.5 & REF _Ref429647594 \r \h 4.9 and the insight gained from Section REF _Ref427757678 \r \h 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.MajorstepsTable 6: Troubleshooting steps and signpostsSee section1Check you can directly access (not through the proxy) the application to be published from the internal network.Verify the DNS name of the application resolves to an IP address. REF _Ref428342298 \r \h 4.3.1Run a browser on the server(s) that are running the connector(s) and verify you can you access the application.2Verify the connector is functioning. REF _Ref428862758 \r \h 4.4.1If necessary troubleshoot the connector. REF _Ref428862765 \r \h 4.43Access 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/noInternal authentication method:Internal application SPN:Delegated login identity: REF _Ref428253205 \r \h \* MERGEFORMAT 4.2.14Verify the values that you recorded in Step 3 match your designed configuration. See step 7 for verifying the configuration6If using preauthentication, check that the user is authorized for access.Verify that the user is directly or indirectly, through group membership, assign to access the published application through the AAD App Proxy. REF _Ref428253232 \r \h \* MERGEFORMAT 4.2.2& REF _Ref428452897 \r \h 4.2.3Verify the user has either an Azure AD basic or premium license. REF _Ref428253232 \r \h \* MERGEFORMAT 4.2.2& REF _Ref428529232 \r \h 4.2.47User the information collected in Step 3 and perform the following stepsVerify the DNS name in the External URL resolves to an IP address. REF _Ref428529365 \r \h 4.3.2For passthrough or Azure Active Directory preauthentication verify that the authentication method for the application is supported. REF _Ref428862866 \r \h 4.5If Azure Active Directory preauthentication is configured, confirm that immediately the browser connects to the external URL it is redirected to the Azure AD login. REF _Ref429647782 \r \h 4.9& REF _Ref428960439 \r \h 4.9.2If using HTTPS and the URL is using a custom domain name, verify that a valid certificate has been uploaded to the portal. REF _Ref429060059 \r \h 4.6Verify that the test you performed in Step 1 used the internal URL as defined in the configuration.Verify if host header translation should be used. Incorrect setting may prevent access to the internal website. REF _Ref429041736 \r \h 4.7If the internal authentication method is set for Integrated Windows Authentication (IWA), verify the internal app is configured for Kerberos. REF _Ref429059396 \r \h \* MERGEFORMAT 4.5.3If IWA is used, verify that the server(s) running the connector(s) is/are domain joined.If IWA is used, verify and the server(s) running the connector are correctly configured for delegation. REF _Ref428254482 \r \h 4.8.1If IWA is used, verify the correct application SPN has been set. REF _Ref429060175 \r \h 4.8.2If IWA is used, verify the correct delegated login identity is selected. REF _Ref428254611 \r \h \* MERGEFORMAT 4.8.38After checking the configuration, if you cannot authenticate to a Kerberos application troubleshoot using a network trace. REF _Ref428254911 \r \h \* MERGEFORMAT 4.8.59If you cannot access a cross-platform Kerberos application, you may require SPNEGO to be enabled. REF _Ref428255015 \r \h \* MERGEFORMAT 4.8.410If you cannot access part of the application, verify that all of the appropriate URLs are published. REF _Ref428255844 \r \h \* MERGEFORMAT 4.2.511If a claims aware application is failing to authenticate, use Fiddler to verify the authentication flow. REF _Ref429647942 \r \h 4.912If you are having problems with setting or changing the URL for the application – verify the object naming in the Azure AD. REF _Ref428255987 \r \h \* MERGEFORMAT 4.10Publishing the applicationThe application is published through the Azure AD portal for details of publishing applications refer to: 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.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 REF _Ref428450541 \h \* MERGEFORMAT Figure 30.Figure SEQ Figure \* MERGEFORMAT 30: User not authorized for accessTo make it easier to read, the error message is reproduced in REF _Ref428450573 \h \* MERGEFORMAT Figure 31.Azure AD Application ProxyStatus code: ForbiddenUrl: 'harry@xtseminars.co.uk'+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 PMAuthorization failed. Make sure to assign the user with access to this applicationFigure SEQ Figure \* MERGEFORMAT 31: Error message - user not authorized for accessThe preauthentication flow diagram Section REF _Ref428451371 \r \h \* MERGEFORMAT 3.2.1 is reproduced again in REF _Ref428451738 \h \* MERGEFORMAT 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 REF _Ref428450573 \h \* MERGEFORMAT Figure 31. The proxy receives the GET request and in response issues a 403 Forbidden and renders the webpage shown in REF _Ref428450541 \h \* MERGEFORMAT Figure 30.Although the error message can look a little daunting with all the GUIDs, there is a very readable message stating that harry@ is not assigned to the application. To learn how to assign a user to the proxy application refer to Section REF _Ref428452897 \r \h \* MERGEFORMAT 4.2.3.Figure SEQ Figure \* MERGEFORMAT 32: Preauthentication flow from Section REF _Ref428451371 \r \h 3.2.1If the user is authorized but not licensed they will see are error page similar to REF _Ref428450541 \h \* MERGEFORMAT Figure 30, but the error message will be as shown in REF _Ref428453172 \h \* MERGEFORMAT Figure 33.Azure AD Application ProxyStatus code: ForbiddenUrl: :{"IsMsofba":false,"OriginalQuery":""}&session_state=7a1dd3a2-1b4a-4eeb-be0f-52371cd6eea5TransactionID: e4879ded-0f8a-46d3-9f90-74f9de70b0f1Timestamp: 8/27/2015 2:42:55 PMAuthorization failed. Make sure that the user has a license for Azure Active Directory Premium or BasicFigure SEQ Figure \* MERGEFORMAT 33: Error message - user authorized, but not licensedIn 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 REF _Ref428451738 \h \* MERGEFORMAT 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 REF _Ref428529562 \r \h \* MERGEFORMAT 4.2.4.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.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).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.Verify published pathsWhen you publish an application, the external URL can be based simply on a Fully Qualified Domain Name (FQDN) such as or an FQDN and a path such as 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 you can access but not . To access 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. REF _Ref428527646 \h \* MERGEFORMAT Figure 34 shows accessing the test site with Chrome, REF _Ref428527649 \h \* MERGEFORMAT Figure 35 shows accessing a path that is not published. The error message is not very helpful!Figure SEQ Figure \* MERGEFORMAT 34: Accessing the published site with ChromeFigure SEQ Figure \* MERGEFORMAT 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 REF _Ref428528255 \h \* MERGEFORMAT 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.Figure SEQ Figure \* MERGEFORMAT 36: Using the developer toolsUsing 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 REF _Ref428528984 \h \* MERGEFORMAT 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 REF _Ref429647594 \r \h \* MERGEFORMAT 4.9.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.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)Run a command prompt and type nslookup app1.. Where app1. is the FQDN of the application.Append a “dot” to the end of the FQDN so that nslookup only attempts to resolve the exact FQDN.See REF _Ref428352182 \h \* MERGEFORMAT Figure 37 for an example of using nslookup to resolve the FQDNYou 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. The name of the server will only be displayed when reverse lookup records have been configured on the DNS server.If nslookup cannot resolve the FQDN, check the host (‘A’) record entry exists on the DNS server.If the IP address is incorrect, check the IP address defined for the host (‘A’) record entry on the DNS server.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. 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..Server: UnKnownAddress: 10.50.0.11Name: app1.Address: 10.50.0.13>Figure SEQ Figure \* MERGEFORMAT 37: Resolving the FQDN using nslookupExternal FQDN for published applicationThere are two options for publishing the external URL of the application. The URL can be stemmed from the default domain or a custom domain such as . 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 . 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 REF _Ref428292384 \h \* MERGEFORMAT Figure 38. Refer to Section REF _Ref428253205 \r \h 4.2.1 for help in locating the configuration settings in the Azure Portal.Figure SEQ Figure \* MERGEFORMAT 38: CNAME required for the external FQDNThe Microsoft DNS uses a wildcard CNAME entry to resolve *. to its alias. If you are using an Azure AD generated FQDN such as app1-xtstest., 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. Run a command prompt and type nslookup app1.. Where app1. is the FQDN of the application.Append a “dot” to the end of the FQDN so that nslookup only attempts to resolve the exact FQDN.See REF _Ref428436000 \h Figure 39 for an example of using nslookup to resolve the FQDNYou 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. The name of the server will only be displayed when reverse lookup records have been configured on the DNS server.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.If the FQDN of your app does not resolve, verify that your CNAME DNS entry is correct.To verify an individual CNAME you can use nslookup -type=cname app1-xtstest..To see the resolution of the IP address and all the CNAMEs in one go use debug mode nslookup -debug app1-xtstest..C:\> C:\>nslookup app1..Server: UnKnownAddress: 81.103.238.99Name: cwap-cu-2.Address: 23.99.136.190Aliases: app1. app1-xtstest. cwap-nam1-runtime. cwap-nam1-runtime-main.C:\>nslookup -type=cname app1-xtstest.Server: UnKnownAddress: 144.19.27.1Non-authoritative answer:aadsts-xtstest. canonical name = cwap-nam1-runtime.Figure SEQ Figure \* MERGEFORMAT 39: Resolving the FQDN with multiple aliasesVerifying 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 REF _Ref428342298 \r \h 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: can verify the login is working using an IdP initiated login, for example: 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. REF _Ref428538942 \h \* MERGEFORMAT Table 7 shows the required outbound ports. Table SEQ Table \* ARABIC 7: Required outbound ports for the connector Port NumberDescription 80To enable outbound HTTP traffic for security validation.443To enable user authentication against Azure AD (required only for the Connector registration process)10100 - 10120To enable LOB HTTP responses sent back to the proxy9352, 5671To enable communication between the Connector toward the Azure service for incoming requests.9350Optional. To enable better performance for incoming requests.8080To enable the Connector bootstrap sequence and to enable Connector automatic update9090To enable Connector registration (required only for the Connector registration process)9091To enable Connector trust certificate automatic renewalChecking 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 REF _Ref428539169 \h \* MERGEFORMAT Figure 40: Connector statusFigure SEQ Figure \* MERGEFORMAT 40: Connector statusEven if the connector is showing as active its operation may be block by an inaccessible port. If you get an error message similar to REF _Ref428539595 \h \* MERGEFORMAT Figure 41 it indicates that the connector cannot communicate properly which may well be due to a blocked port.This corporate app can't be accessed right now.Please try again later...There may be a connectivity problemRefresh the page in a few minutes.Azure AD Application ProxyStatus code: GatewayTimeoutUrl: : 85921d6a-90a5-4131-95e3-dbe78058f4f5Timestamp: 8/28/2015 2:01:51 PMThe connector has timed out.Figure SEQ Figure \* MERGEFORMAT 41: Connector time outYou can check that the outbound ports are not blocked by accessing a webpage hosted by the AAD App Proxy product group. . Make sure you run the test on the server(s) that are hosting the connector(s). REF _Ref428539866 \h \* MERGEFORMAT Figure 42 shows the results when port 1010 is blocked.Figure SEQ Figure \* MERGEFORMAT 42: Port 1010 blockedThere are two services that run the connector verify that both of them are running.Microsoft AAD Application Proxy ConnectorManages the communication between the Cloud proxy service and the on-premises connectorMicrosoft AAD Application Proxy Connector UpdateThis 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 REF _Ref428549555 \r \h 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: the connector event logsEach of the services that run the connector has its own event collection. See REF _Ref428548000 \h \* MERGEFORMAT 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 For help in reading some of the event log messages see: SEQ Figure \* MERGEFORMAT 43: The connector event logsAuthentication 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 REF _Ref427757678 \r \h 3 and are summarized here for you convenience.The proxy supports:Anonymous accessForms authenticationBasic authenticationDigest authenticationNTLMKerberos authenticationClaims authenticationWith 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 REF _Ref425419785 \r \h \* MERGEFORMAT 3.4, REF _Ref428867413 \r \h \* MERGEFORMAT 3.5 and REF _Ref427576441 \r \h \* MERGEFORMAT 3.6.As discussed in Section REF _Ref428866605 \r \h \* MERGEFORMAT 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. 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 REF _Ref428866605 \r \h 3.3 for a discussion of Kerberos authentication and Sections REF _Ref425419785 \r \h 3.4, REF _Ref428954414 \r \h 3.5 & REF _Ref427576441 \r \h 3.6 for discussion of the options for implementing claims authentication.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.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 REF _Ref428987356 \h Figure 44.Figure SEQ Figure \* MERGEFORMAT 44: Disable automatic logonIf the website is using HTTPS and extended protection, you cannot use Fiddler (see Section REF _Ref429647594 \r \h 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.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 access the internal application using Kerberos. Review Section REF _Ref428866605 \r \h 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 REF _Ref429055292 \h Figure 45, where the session ticket is identified by the SPN: HTTP/wia.Figure SEQ Figure \* MERGEFORMAT 45: Kerberos session ticket to wia.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 REF _Ref429053716 \h \* MERGEFORMAT Figure 46. If the header value starts YII…, authentication is via Kerberos, see REF _Ref429055601 \h \* MERGEFORMAT Figure 47.Figure SEQ Figure \* MERGEFORMAT 46: NTLM authenticationFigure SEQ Figure \* MERGEFORMAT 47: Kerberos authenticationValidating 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 (), will indicate if the authentication was via NTLM or Kerberos. See REF _Ref429657279 \h \* MERGEFORMAT Figure 48 & REF _Ref429657290 \h \* MERGEFORMAT 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 SEQ Figure \* MERGEFORMAT 48: Authentication via NTLMFigure SEQ Figure \* MERGEFORMAT 49: Authentication via KerberosTroubleshooting 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: 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 domain name a certificate maintained by Microsoft is automatically used. If you use a custom domain you will need to upload a certificate.Supported certificatesSingle-nameWildcardSANSelf-signedElliptic Curve Cryptography (ECC) certificatesThere 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 SEQ Table \* ARABIC 8: Certificate troubleshooting tipsFor 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.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 REF _Ref429035337 \h \* MERGEFORMAT Figure 50.Figure SEQ Figure \* MERGEFORMAT 50: IIS site bindingsWhen 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).Kerberos configurationReview section REF _Ref428866605 \r \h \* MERGEFORMAT 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 Kerberos. If you need more help refer to the Kerberos troubleshooting whitepaper that can be down loaded here: 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 REF _Ref429061019 \h \* MERGEFORMAT Figure 51. The “services to which this account can present credentials” are identified by the internal application SPN.Figure SEQ Figure \* MERGEFORMAT 51: Properties of the computer objectInternal 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. Changing the delegated login identitySee Section REF _Ref429078757 \r \h 3.3.4 for details of using an alternative login ID and the use of the delegated login identity.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 onDelegated login identity (name shown in UI)The Azure AD UPNUser principal nameThe on-premises UPNOn-premises user principal nameThe on-premises SAM account nameOn-premises SAM account nameThe username part of the Azure AD UPNUsername part of user principal nameThe username part of the on-premises UPNUsername part of on-premises user principal nameSee Section REF _Ref428254911 \r \h 4.8.5 Scenario 4 for help with troubleshooting using a network trace.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 1You 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. REF _Ref429490860 \h Figure 52 shows the OID as Kerberos 5 and REF _Ref429490861 \h Figure 53 shows the OID as SPNEGO.Figure SEQ Figure \* MERGEFORMAT 52: SPNEGO not enabledFigure SEQ Figure \* MERGEFORMAT 53: SPNEGO enabledAnalyzing 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 is published by the Azure AD App Proxy as . HTTPS is required on the external URL for preauthentication. The first traces have been captured when our user jill@xtseminars.co.uk 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:ComputerIP addressDomain controller (KDC)10.50.0.11Server running the connector (addproxy1$)10.50.0.50Application - wia.10.50.0.13The 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.Figure SEQ Figure \* MERGEFORMAT 54: Kerberos traffic between the connector and the domain controller REF _Ref429132406 \h \* MERGEFORMAT 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 REF _Ref429132871 \h \* MERGEFORMAT Figure 55. The network traces match the flow shown in REF _Ref422990624 \h \* MERGEFORMAT Figure 11 (Section REF _Ref429134040 \r \h \* MERGEFORMAT 3.3.3 ) between the connector and the application and is described in the text that accompanies the figure.In REF _Ref429132871 \h \* MERGEFORMAT Figure 55 you will notice that the header Authorization: Negotiate starts YII which indicates that it is a Kerberos header.Figure SEQ Figure \* MERGEFORMAT 55: HTTP traffic to the internal applicationThe following traces show more details of the top-level trace shown in REF _Ref429132406 \h \* MERGEFORMAT Figure 54. Before troubleshooting problems it is good to understand how to read a good trace, make sure you review section REF _Ref429134129 \r \h 3.3.3 to help you understand the traces. REF _Ref429133510 \h \* MERGEFORMAT 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.Figure SEQ Figure \* MERGEFORMAT 56: AS-REQ for jill@xtseminars.co.uk REF _Ref429134598 \h \* MERGEFORMAT 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 REF _Ref429135160 \h \* MERGEFORMAT Figure 58. Figure SEQ Figure \* MERGEFORMAT 57: TGS-REQ for ticket to self (the connector: addproxy1$)Figure SEQ Figure \* MERGEFORMAT 58: TGS-REP showing principal jill@xtseminars.co.uk REF _Ref429135312 \h \* MERGEFORMAT 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.Figure SEQ Figure \* MERGEFORMAT 59: TGS-REQ for ticket to http/wia.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 jill@xtseminars.co.uk the proxy responds with the webpage as shown in REF _Ref429153465 \h \* MERGEFORMAT 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: : 6a8b2990-a918-4c7c-9bfe-4868ad395fecTimestamp: 9/4/2015 1:08:41 PMAn error occurred. Check the Application Proxy Connector Event Log for reported errorsFigure SEQ Figure \* MERGEFORMAT 60: Scenario 1 - response after login as jill@xtseminars.co.ukOn 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 REF _Ref429153466 \h \* MERGEFORMAT 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 SEQ Figure \* MERGEFORMAT 61: Scenario 1 - connector Admin event logFrom the error message it is not intuitively obvious what is wrong. However a network trace as shown in REF _Ref429153467 \h Figure 62 immediately indicates the problem.Figure SEQ Figure \* MERGEFORMAT 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. Scenario 2After preauthenticating as jill@xtseminars.co.uk the proxy responds with the webpage as shown in REF _Ref429153503 \h \* MERGEFORMAT Figure 63.This corporate app can't be accessed, contact your IT department.Azure AD Application ProxyStatus code: BadGatewayUrl: : fccc014d-2d13-4ddd-8ec3-f45438d4ae52Timestamp: 9/4/2015 1:49:50 PMIncorrect Kerberos constrained delegation configuration in your on-premises Active DirectoryFigure SEQ Figure \* MERGEFORMAT 63: Scenario 2 - response after login as jill@xtseminars.co.ukOn 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 REF _Ref429153525 \h \* MERGEFORMAT 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.Figure SEQ Figure \* MERGEFORMAT 64: Scenario 2 - connector Admin event logFrom the error message it is not intuitively obvious what is wrong. This time a network trace ( REF _Ref429153539 \h \* MERGEFORMAT Figure 65) shows that the TGS-REQ for a ticket to the application is missing.Figure SEQ Figure \* MERGEFORMAT 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 jill@xtseminars.co.uk the proxy responds with the webpage as shown in REF _Ref429153589 \h \* MERGEFORMAT Figure 66This corporate app can't be accessed, contact your IT department.Azure AD Application ProxyStatus code: BadGatewayUrl: : 26efb014-8f2e-4c5d-8552-914abb1a3cb9Timestamp: 9/4/2015 2:41:31 PMThe 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. Figure SEQ Figure \* MERGEFORMAT 66: Scenario 3 - response after login as jill@xtseminars.co.ukFrom 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 REF _Ref429153627 \h \* MERGEFORMAT 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 unreachableFigure SEQ Figure \* MERGEFORMAT 67: Scenario 3 - connector Admin event logSo it is clear that there is an SPN issue, but what SPN is being requested? This time a network trace ( REF _Ref429153708 \h \* MERGEFORMAT Figure 68) shows that the TGS-REQ for a ticket to the application is using a SPN of http/wias., an obvious typo but now we know what we are looking for.Figure SEQ Figure \* MERGEFORMAT 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! Scenario 4After preauthenticating as mike@xtseminars.co.uk the proxy responds with the webpage as shown in REF _Ref429568796 \h \* MERGEFORMAT Figure 69.This corporate app can't be accessed, contact your IT department.Azure AD Application ProxyStatus code: ForbiddenUrl: : 769c145c-1e4c-4d8e-bd75-155a3b026e2eTimestamp: 9/9/2015 11:29:54 AMThe 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 ADFigure SEQ Figure \* MERGEFORMAT 69: Scenario 4 - response after login as mike@xtseminars.co.ukOn checking the connector event log you see a warning and a red-eye. The accompanying text is shown in REF _Ref429568905 \h \* MERGEFORMAT Figure 70.Web Application Proxy encountered an unexpected error while processing the request.Error: The user name or password is incorrect.Figure SEQ Figure \* MERGEFORMAT 70: Scenario 4 - connector Admin event logSeeing 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 ( REF _Ref429569159 \h \* MERGEFORMAT Figure 71) immediately shows us the problem. The wrong username is being used in the AS-REQ. The on-premises UPN should be mike@xtseminars.local whereas mike@xtseminars.co.uk 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 REF _Ref429078757 \r \h \* MERGEFORMAT 3.3.4 & REF _Ref428254611 \r \h \* MERGEFORMAT 4.8.3. Figure SEQ Figure \* MERGEFORMAT 71: Invalid usernameUse the techniques you have learned in this section to aid your troubleshooting endeavors.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 . 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!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 REF _Ref427757678 \r \h 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.Preauthentication flowRefer to Section REF _Ref428451371 \r \h \* MERGEFORMAT 3.2.1 to review the preauthentication flow, REF _Ref422990129 \h \* MERGEFORMAT Figure 3 has been reproduced as REF _Ref429388900 \h \* MERGEFORMAT Figure 72 to aid with the explanation given in this section. This section shows you how Fiddler can be used to examine the exact details of the protocol flow. Figure SEQ Figure \* MERGEFORMAT 72: Preauthentication flow (copy of REF _Ref422990129 \h Figure 3)The complete authentication trace can be captured as shown in REF _Ref429401471 \h \* MERGEFORMAT Figure 73, aadsts. is a claims aware application and it triggers its own authentication. The left hand column in Fiddler shows the session numbering. In REF _Ref429401471 \h \* MERGEFORMAT Figure 73 session # 10 is where the first GET is made to the application after preauthentication is complete. This corresponds to step 9 in REF _Ref429388900 \h \* MERGEFORMAT Figure 72.Figure SEQ Figure \* MERGEFORMAT 73: Complete authentication traceThe following figures go into the details of the sessions shown in the Fiddler trace.Session #2Figure SEQ Figure \* MERGEFORMAT 74: GET request & redirect response REF _Ref429401472 \h \* MERGEFORMAT Figure 74 shows the initial get request to the published external URL for the application. This is shown as Step 1 in REF _Ref429388900 \h \* MERGEFORMAT 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 REF _Ref429388900 \h \* MERGEFORMAT Figure 72.An authentication string as shown in REF _Ref429401704 \h \* MERGEFORMAT 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.:{"IsMsofba":false,"OriginalQuery":""}Figure SEQ Figure \* MERGEFORMAT 75: Decoded - OpenID Connect authentication stringAs we have no control over the behavior of Azure AD we are going to skip to where the user has completed authentication.Session #8Figure SEQ Figure \* MERGEFORMAT 76: The user has completed authentication REF _Ref429401470 \h \* MERGEFORMAT Figure 76 show the response after the user has completed authentication. This is shown as Step 4 in REF _Ref429388900 \h \* MERGEFORMAT Figure 72. Notice the cookies that have been set, the authentication cookies will allow the browser to automatically authenticate to Azure 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 REF _Ref429404000 \h \* MERGEFORMAT Figure 77.Session #9Figure SEQ Figure \* MERGEFORMAT 77: Setting the AzureAppProxyAccessCookieThe GET request to the application includes the AzureAppProxyAccessCookie, see REF _Ref429407120 \h \* MERGEFORMAT Figure 78. The proxy see the request as authenticated and passes it on to the application, step 9 in REF _Ref429388900 \h \* MERGEFORMAT Figure 72. The application then implements its own authentication mechanism.Session #10Figure SEQ Figure \* MERGEFORMAT 78: Get request passed to applicationClaims aware applicationsThere are many different scenarios that can be traced for authentication of a claims-aware application and these are covered in Section REF _Ref427757678 \r \h 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 REF _Ref427757678 \r \h 3.In this section we will follow on from the preauthentication that was traced in Section REF _Ref428960439 \r \h \* MERGEFORMAT 4.9.2. The protocol flow diagram, REF _Ref425433664 \h \* MERGEFORMAT Figure 23, from Section REF _Ref428867413 \r \h \* MERGEFORMAT 3.5 is reproduced here for your convenience. Please review Section REF _Ref428867413 \r \h \* MERGEFORMAT 3.5 for more details. The Fiddler session numbers are taken from REF _Ref429401471 \h \* MERGEFORMAT Figure 73.Figure SEQ Figure \* MERGEFORMAT 79: Authenticating to app1, where app1 trusts Azure AD as the IdP (copy of REF _Ref425433664 \h 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 REF _Ref429464176 \h \* MERGEFORMAT Figure 80. As part of the redirect the authentication string for the application is included. This can be seen in REF _Ref429464862 \h \* MERGEFORMAT Figure 81. The URL redirects to the Azure AD endpoint with a WSFederation authentication request see Section REF _Ref425419785 \r \h \* MERGEFORMAT 3.4 for more details.Session #10Figure SEQ Figure \* MERGEFORMAT 80: Application redirecting to Azure AD SEQ Figure \* MERGEFORMAT 81: Decoded application authentication stringThe Azure AD reads the authentication string and redirects to login.. The subsequent get request includes the Azure AD authentication cookies because the user has already preauthenticated against Azure AD, see REF _Ref429466194 \h \* MERGEFORMAT Figure 82.Session #12Figure SEQ Figure \* MERGEFORMAT 82: Azure Authentication cookies includedAfter 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 REF _Ref425419785 \r \h \* MERGEFORMAT 3.4 and shown in REF _Ref425322561 \h \* MERGEFORMAT 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 REF _Ref429467752 \h \* MERGEFORMAT Figure 83.Figure SEQ Figure \* MERGEFORMAT 83: Viewing the claimsAlternatively you can add a Fiddler inspector that will display the SAML token. The inspector is referenced here: and the results are shown in REF _Ref429468016 \h \* MERGEFORMAT Figure 84.Figure SEQ Figure \* MERGEFORMAT 84: Federation inspectorAfter 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 REF _Ref429468616 \h \* MERGEFORMAT Figure 85.Session #12Figure SEQ Figure \* MERGEFORMAT 85: Authenticated to the applicationAzure AD object naming for published applicationsIn this scenario the claims-aware application trusts the Azure AD to authenticate the user, this is shown in the following diagram, REF _Ref422990683 \h \* MERGEFORMAT Figure 86.Figure SEQ Figure \* MERGEFORMAT 86: Publishing a claims-aware applicationThe 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 REF _Ref422990696 \h \* MERGEFORMAT Figure 87.Figure SEQ Figure \* MERGEFORMAT 87: Creating the application in AzureOnce 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. REF _Ref422990715 \h \* MERGEFORMAT Figure 88. At this stage you cannot set the external URL, this has to be done once the AAD App Proxy has been created.Figure SEQ Figure \* MERGEFORMAT 88: Creating the AAD App ProxyOnce 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 SEQ Figure \* MERGEFORMAT 89: Changing the external URLClick save and the update will fail, REF _Ref422990801 \h \* MERGEFORMAT Figure 90. Sometimes you have to love Microsoft error messages!Figure SEQ Figure \* MERGEFORMAT 90: Saving the changesThe 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. REF _Ref422990835 \h \* MERGEFORMAT Figure 91Figure SEQ Figure \* MERGEFORMAT 91: Before changing the external URL of the AAD App ProxyOne of the ServicePrincipalNames for the application is derived from the applications URI and one of the ServicePrincipalNames for the AAD App Proxy is derived from the external URL . If the proxy’s external URL is set to 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 rather than https).After setting the APP URI to , test the application from the intranet. You may see the error as shown in REF _Ref429490256 \h \* MERGEFORMAT 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 and that application no longer exists in the Azure AD. The application is now identified by SEQ Figure \* MERGEFORMAT 92: Authentication to the application failsOnce 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. Figure SEQ Figure \* MERGEFORMAT 93: After changing the external URL of the AAD App Proxy ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download