Skip to content

Introduction

Integrating on-premises applications with cloud services can sometimes lead to unexpected authentication challenges. In this blog post, I'll explore a specific issue encountered when setting up Microsoft Entra ID Application Proxy (formerly Azure AD Application Proxy) to provide Single Sign-On (SSO) access to an internal IIS application using Kerberos Constrained Delegation (KCD). I'll delve into the problem, the troubleshooting steps taken, and the ultimate solution that resolved the authentication errors.

Scenario Overview

  • Application Proxy Connector Server: serv-app101
  • Backend IIS Application Server: serv-iis
  • Published Application URL: https://portal.domain.com
  • Authentication Method: Kerberos Constrained Delegation (KCD)
  • Users: Entra ID-synced Active Directory users

The goal was to allow Entra ID users to access the internal IIS application seamlessly via SSO, using the Application Proxy with KCD.

The Problem

After configuring the Application Proxy and publishing the internal application, users encountered the following issues:

  • Event ID 13019 in the Application Proxy Connector's event log:

  • Event ID 4769 in Security Event Log on corresponding Domain Controller:

  • User Access Error: "The user is not authorized to access the backend application."

Notably, users had been assigned to the Enterprise Application in Entra ID, and prior logins without Kerberos delegation worked seamlessly. The user credentials were confirmed to be correct, as users could successfully pre-authenticate to Entra ID.

Troubleshooting Steps

1. Verifying SPN Registration and Delegation Settings

I first ensured that the Service Principal Name (SPN) was correctly registered and that delegation settings were properly configured:

  • SPN Registration:
    • Verified that HTTP/portal.domain.com was registered on the serv-iis computer account, as IIS was running under the Network Service account.
    • Used the following command to confirm the SPN: setspn -L serv-iis
  • Delegation Settings:
    • Checked that serv-app101 was configured to trust for delegation to the HTTP/portal.domain.com SPN.

2. Checking for Duplicate SPNs

  • Ran the command to identify any duplicate SPNs: setspn -X
  • Confirmed that there were no duplicates causing conflicts.

3. Verifying IIS Authentication Settings

  • Ensured that Windows Authentication was enabled on the IIS application.
  • Confirmed that Negotiate was listed above NTLM in the Providers.

4. Testing Internal Access

  • Attempted to access https://portal.domain.com directly from within the internal network.
  • Verified that users could authenticate successfully without going through the Application Proxy.

5. Checking Network Connectivity and Time Synchronization

  • Confirmed that serv-app101 had network connectivity to serv-iis and the domain controllers on all ports required.
  • Ensured that all servers had synchronized clocks.

6. Reviewing Event Logs for Additional Clues

  • Enabled Kerberos logging to get detailed error messages.
  • Reviewed the Application and Security event logs on both serv-app101 and serv-iis.

Despite these efforts, the issue persisted. But I did find a couple of events that pointed me in the right direction. Especially Event ID 4769 in the Domain Controller's Security log which stated a Failure Code of 0x6. According to Microsoft the error code equals to KDC_ERR_C_PRINCIPAL_UNKNOWN, i.e. "Client not found in Kerberos database". And KDC_ERR_C_PRINCIPAL_UNKNOWN is actually an "Access is Denied" error for reading the TokenGroupsGlobalAndUniversal user-constructed attribute. By default, authenticated users have these permissions, whereas computer objects don't.

The Solution: Adding the Application Proxy Connector to the Windows Authorization Access Group

The breakthrough came with the realization that the Application Proxy Connector's computer account (serv-app101) lacked sufficient permissions to read certain user-constructed attributes required for Kerberos authentication.

Understanding the Root Cause

  • Kerberos Authentication Requirements:
    • Kerberos authentication requires the service requesting a ticket on behalf of a user to read the user's TokenGroupsGlobalAndUniversal attribute.
  • Permission Limitations:
    • By default, authenticated user accounts have permission to read this attribute.
    • Computer accounts, such as serv-app101, do not have this permission by default.

Granting Necessary Permissions

To resolve the issue, I added the serv-app101 computer account to the Windows Authorization Access Group, a built-in Active Directory group that grants permission to read the TokenGroupsGlobalAndUniversal user-constructed attribute.

Result

After adding serv-app101 to the Windows Authorization Access Group and allowing the changes to propagate, users were able to authenticate successfully via the Application Proxy with KCD enabled. The Event ID 13019 error ceased to appear in the event logs, confirming that the Application Proxy Connector could now retrieve Kerberos tickets on behalf of users.

Conclusion

When configuring Entra ID Application Proxy with Kerberos Constrained Delegation, it's crucial to ensure that the Application Proxy Connector's computer account has the necessary permissions to read user attributes required for Kerberos authentication.

Key Takeaways:

  • SPN Registration and Delegation Settings:
    • Always verify that SPNs are correctly registered and delegation settings are properly configured.
  • Permissions for Computer Accounts:
    • Be aware that computer accounts do not have the same default permissions as user accounts.
    • Grant necessary permissions (according to the least privilege principle) by adding the computer account to appropriate groups, such as the Windows Authorization Access Group.
  • Troubleshooting Approach:
    • Systematically check all aspects of the configuration, including network connectivity, authentication settings, and permissions.
    • Utilize event logs and enable verbose logging to uncover hidden issues.

By understanding the interplay between Active Directory permissions and Kerberos authentication requirements, administrators can effectively troubleshoot and resolve authentication issues in hybrid environments. Hope this helps.

Additional Resources

  • SPN Registration:
    • Verified that HTTP/portal.domain.com was registered on the serv-iis computer account, as IIS was running under the Network Service account.
    • Used the following command to confirm the SPN: setspn -L serv-iis
  • Delegation Settings:
    • Checked that serv-app101 was configured to trust for delegation to the HTTP/portal.domain.com SPN.

2. Checking for Duplicate SPNs

  • Ran the command to identify any duplicate SPNs: setspn -X
  • Confirmed that there were no duplicates causing conflicts.

3. Verifying IIS Authentication Settings

  • Ensured that Windows Authentication was enabled on the IIS application.
  • Confirmed that Negotiate was listed above NTLM in the Providers.

4. Testing Internal Access

  • Attempted to access https://portal.domain.com directly from within the internal network.
  • Verified that users could authenticate successfully without going through the Application Proxy.

5. Checking Network Connectivity and Time Synchronization

  • Confirmed that serv-app101 had network connectivity to serv-iis and the domain controllers on all ports required.
  • Ensured that all servers had synchronized clocks.

6. Reviewing Event Logs for Additional Clues

  • Enabled Kerberos logging to get detailed error messages.
  • Reviewed the Application and Security event logs on both serv-app101 and serv-iis.

Despite these efforts, the issue persisted. But I did find a couple of events that pointed me in the right direction. Especially Event ID 4769 in the Domain Controller's Security log which stated a Failure Code of 0x6. According to Microsoft the error code equals to KDC_ERR_C_PRINCIPAL_UNKNOWN, i.e. "Client not found in Kerberos database". And KDC_ERR_C_PRINCIPAL_UNKNOWN is actually an "Access is Denied" error for reading the TokenGroupsGlobalAndUniversal user-constructed attribute. By default, authenticated users have these permissions, whereas computer objects don't.

The Solution: Adding the Application Proxy Connector to the Windows Authorization Access Group

The breakthrough came with the realization that the Application Proxy Connector's computer account (serv-app101) lacked sufficient permissions to read certain user-constructed attributes required for Kerberos authentication.

Understanding the Root Cause

  • Kerberos Authentication Requirements:
    • Kerberos authentication requires the service requesting a ticket on behalf of a user to read the user's TokenGroupsGlobalAndUniversal attribute.
  • Permission Limitations:
    • By default, authenticated user accounts have permission to read this attribute.
    • Computer accounts, such as serv-app101, do not have this permission by default.

Granting Necessary Permissions

To resolve the issue, I added the serv-app101 computer account to the Windows Authorization Access Group, a built-in Active Directory group that grants permission to read the TokenGroupsGlobalAndUniversal user-constructed attribute.

Result

After adding serv-app101 to the Windows Authorization Access Group and allowing the changes to propagate, users were able to authenticate successfully via the Application Proxy with KCD enabled. The Event ID 13019 error ceased to appear in the event logs, confirming that the Application Proxy Connector could now retrieve Kerberos tickets on behalf of users.

Conclusion

When configuring Entra ID Application Proxy with Kerberos Constrained Delegation, it's crucial to ensure that the Application Proxy Connector's computer account has the necessary permissions to read user attributes required for Kerberos authentication.

Key Takeaways:

  • SPN Registration and Delegation Settings:
    • Always verify that SPNs are correctly registered and delegation settings are properly configured.
  • Permissions for Computer Accounts:
    • Be aware that computer accounts do not have the same default permissions as user accounts.
    • Grant necessary permissions (according to the least privilege principle) by adding the computer account to appropriate groups, such as the Windows Authorization Access Group.
  • Troubleshooting Approach:
    • Systematically check all aspects of the configuration, including network connectivity, authentication settings, and permissions.
    • Utilize event logs and enable verbose logging to uncover hidden issues.

By understanding the interplay between Active Directory permissions and Kerberos authentication requirements, administrators can effectively troubleshoot and resolve authentication issues in hybrid environments. Hope this helps.

Additional Resources