Edit

Share via

Troubleshoot Kerberos constrained delegation

  • Article

Single sign-on (SSO) methods vary between applications. Microsoft Entra application proxy provides Kerberos constrained delegation (KCD) by default. In application proxy, a user authenticates to a private application by using Kerberos.

This article describes how to troubleshoot the most common problems in KCD configuration. It includes diagnostic steps you can take for more complex implementations.

This article makes the following assumptions:

  • Microsoft Entra application proxy is deployed and has general access to non-KCD applications.

    For more information, see Get started with application proxy.

  • A published application is based on Internet Information Services (IIS) and the Microsoft implementation of Kerberos.

  • Server and application hosts are in a single Microsoft Entra domain.

    For more information on cross-domain and forest scenarios, see the white paper Understanding Kerberos constrained delegation with application proxy.

  • The application is published in a Microsoft Entra tenant with preauthentication enabled. Users are expected to authenticate by using forms-based authentication.

    Rich client authentication scenarios aren't covered in this article.

Considerations

The following list describes foundational considerations for KCD configuration and use with Microsoft Entra application proxy:

  • Basic misconfigurations or general mistakes cause most issues. Before you begin to troubleshoot, check all prerequisites in Use KCD SSO with application proxy.

  • Connector hosts aren't restricted to communicate with only a specific local site domain controller (DC). Check the DC you use because it might change.

  • Cross-domain scenarios rely on referrals that direct a connector host to DCs that might be outside of the local network perimeter. In these cases, it's equally important to send traffic onward to DCs that represent other respective domains. If you don't, delegation fails.

  • Avoid active Intrusion Prevention System (IPS) or Intrusion Detection System (IDS) devices between connector hosts and DCs. These devices are too intrusive and interfere with core Remote Procedure Call (RPC) traffic.

  • Test delegation in a simple scenario. The more variables you introduce in a scenario, the more complex configuration and troubleshooting is. To save time, limit your testing to a single connector. Add more connectors after the issue is resolved.

  • Environmental factors might contribute to the cause of an issue. To avoid these factors, minimize architecture as much as possible during testing. For example, misconfigured internal firewall access control lists (ACLs) are common. If possible, send all traffic from a connector directly to the DCs and back-end application.

  • The best place to position connectors is as close as possible to their targets. A firewall that sits inline when you test adds unnecessary complexity and can prolong your investigations.

  • What indicates a KCD problem? Several common errors indicate that KCD SSO is failing. The first signs of an issue appear in the browser.

    Both of the following screenshots show the same symptom of SSO failure: User access to the application is denied.

    Screenshot that shows an example of an incorrect KCD configuration error, with the error Incorrect Kerberos constrained delegation highlighted.

    Screenshot that shows an example of authorization failure because of missing permissions.

Troubleshoot

You can troubleshoot KCD problems in three stages. Check these parts of the KCD process in the following order:

  • Client preauthentication
  • The delegation service
  • The target application

Client preauthentication

Client preauthentication refers to an external user authenticating in an application via a browser. The ability to preauthenticate to Microsoft Entra ID is necessary for KCD SSO to work.

Test client preauthentication first, and resolve any issues. The preauthentication stage isn't related to KCD or to the published application. It's easy to correct any discrepancies by checking that the subject account exists in Microsoft Entra ID. Check that the application isn't unavailable or blocked. The error response in the browser typically is descriptive enough to explain the cause.

The delegation service

The Kerberos delegation service is the private network connector that gets a Kerberos service ticket from a Kerberos Key Distribution Center (KDC). The app user authenticates with the application via the ticket.

External communications between the client and the Azure front end have no effect on constrained delegation. These communications ensure only that KCD works. The application proxy service is given a valid user ID that gets a Kerberos ticket. Without this ID, KCD can't occur and SSO fails.

Browser error messages provide useful information about why sign-in fails. Record the values for TransactionID and Timestamp in the response to application sign-in. The information helps correlate the behavior to events that appear in the application proxy event log.

Screenshot that shows a Kerberos constrained delegation configuration error message.

The corresponding entries in the event log are event IDs 13019 or 12027. To view the connector event logs, go to Applications and Services Logs > Microsoft > Microsoft Entra private network > Connector > Admin.

To troubleshoot a constrained delegation issue:

  1. In your internal Domain Name System (DNS) for the application address, use an A record, not a CNAME record.
  2. Verify that the connector host is configured with permissions to delegate to the target account’s service principal name (SPN). Verify that Use any authentication protocol is selected. For more information, see SSO configuration.
  3. Verify that only one instance of the SPN exists in Microsoft Entra ID. To verify a single SPN, at a command prompt on any domain member host, run setspn -x.
  4. Check that a domain policy that limits the maximum size of issued Kerberos tokens is enforced. The policy stops the connector from getting a token if the token size exceeds a set maximum.
  5. Running a network trace that captures exchanges between the connector host and a domain KCD is the next best step to get more details about the issue. For more information, you can review the in-depth white paper Troubleshooting the Microsoft Entra application proxy.

If ticketing is working correctly, the logs likely show an event that indicates authentication failed because the application returned a 401 error. This event indicates that the target application rejected the ticket. Go to the next stage of troubleshooting.

The application

The target application consumes the Kerberos ticket that the connector provides. At this stage, it's expected that the connector sent a Kerberos service ticket to the back end. The ticket is a header in the first application request.

To troubleshoot an application issue:

  1. Use the application’s internal URL that's defined in the Azure portal to validate that the application is accessible directly from the browser on the connector host. If you can successfully sign in, the application is accessible.

  2. Verify that authentication between the browser and the application uses Kerberos. Use DevTools (select the F12 key) in Internet Explorer or use Fiddler from the connector host. Go to the application by using the internal URL. To make sure that either "Negotiate" or "Kerberos" is included, inspect the web authorization headers that are returned in the response from the application.

    The next Kerberos blob that returns in the response from the browser to the application starts with YII. These letters indicate that Kerberos is running. A response from Microsoft NT LAN Manager (NTLM) always starts with TlRMTVNTUAAB. The response reads NTLM Security Support Provider (NTLMSSP) when it's decoded from Base64. If you see TlRMTVNTUAAB at the start of the blob, Kerberos isn't available. If you don’t see TlRMTVNTUAAB, Kerberos likely is available.

    Note

    If you use Fiddler, you must temporarily disable extended protection on the application configuration in IIS.

    Screenshot that shows a browser network inspection dialog.

    The blob in this screenshot doesn't start with TIRMTVNTUAAB. So in this example, Kerberos is available, and the Kerberos blob doesn’t start with YII.

  3. On the IIS site, temporarily remove NTLM from the providers list. Access the app directly from Internet Explorer on the connector host. NTLM is no longer in the providers list, so you can access the application only by using Kerberos. If access fails, a problem with the application’s configuration is indicated. The application isn't processing Kerberos authentication.

  4. If Kerberos isn't available, check the application’s authentication settings in IIS. Make sure that Negotiate is listed at the top, and NTLM is just below it. If you see Not Negotiate, Kerberos or Negotiate, or PKU2U, continue only if Kerberos is functional.

    Screenshot that shows Windows authentication providers.

  5. With Kerberos and NTLM in place, in the portal, temporarily disable preauthentication for the application. Try to access the application in a browser by using the external URL. You're prompted to authenticate. Use the same account that you used in a previous step. If you can't authenticate and sign in, there's a problem with the back-end application, not with KCD.

  6. Re-enable preauthentication in the portal. Authenticate through Azure by attempting to connect to the application via its external URL. If SSO fails, you see a "forbidden" error message in the browser and event ID 13022 in the log:

    Microsoft Entra private network connector can't authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.

    Screenshot that shows an HTTP 401 forbidden error message.

  7. Check the IIS application. Make sure that the configured application pool and the SPN are configured to use the same account in Microsoft Entra ID. In IIS, go to the folder as shown in the following screenshot:

    Screenshot that shows an IIS application configuration dialog.

    Check the identity, and then make sure this account is configured with the SPN. At a command prompt, for example, run setspn –q http/spn.contoso.com.

    Screenshot that shows the SetSPN command window.

  8. In the portal, check the defined SPN against the application settings. Make sure that the application’s app pool uses the same SPN that is set for the target Microsoft Entra account.

  9. In IIS, select the Configuration Editor option for the application. Go to system.webServer/security/authentication/windowsAuthentication. Make sure that the value for UseAppPoolCredentials is True.

    Screenshot that shows the IIS configuration app pools credential option.

    Change the value to True if needed. Remove all cached Kerberos tickets from the back-end server by running the following command:

    Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}

  10. If Kernel mode is enabled, Kerberos operations improve. But the ticket for the requested service also must be decrypted by using the machine account. This account is also called the Local system. Set this value to True to break KCD when the application is hosted across more than one server in a farm.

  11. As another check, disable extended protection. In some test scenarios, extended protection broke KCD when it was enabled in specific configurations. In those cases, an application was published as a subfolder of the default website. This application is configured for anonymous authentication only. All the dialogs are inactive, with no available selections, which suggests that child objects wouldn't inherit any active settings. We recommend that you test, but don’t forget to restore this value to enabled if possible.

    This extra check puts you on track to use your published application. You can generate more connectors that are also configured to delegate. For more information, read the more in-depth technical walkthrough Troubleshooting the Microsoft Entra application proxy.

If you still can't resolve the application authentication issue, create a support ticket directly in the portal.

Other scenarios

Microsoft Entra application proxy requests a Kerberos ticket before it sends a request to an application. Some applications don't support this method of authenticating. These applications are set up to respond to more conventional authentication steps. The first request is anonymous, which allows the application to respond with the authentication types that it supports through a 401 error. You can set up this type of Kerberos negotiation by completing the steps described in Kerberos constrained delegation for SSO.

Multi-hop authentication is commonly used when an application is tiered. The tiers include a back end and a front end. Both tiers require authentication. For example, you can create a tiered application by using SQL Server Reporting Services. For more information, see How to configure Kerberos constrained delegation for web enrollment proxy pages.

Related content