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 theserv-iis
computer account, as IIS was running under the Network Service account. - Used the following command to confirm the SPN:
setspn -L serv-iis
- Verified that
- Delegation Settings:
- Checked that
serv-app101
was configured to trust for delegation to theHTTP/portal.domain.com
SPN.
- Checked that
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 toserv-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
andserv-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
- Enable Kerberos event logging - Windows Server | Microsoft Learn
- Configure KCD for Application Proxy applications with SSO
- 4769(S, F) A Kerberos service ticket was requested. - Windows 10 | Microsoft Learn
- KDC_ERR_C_PRINCIPAL_UNKNOWN in S4U2Self request - Windows Server | Microsoft Learn
- Understanding the Windows Authorization Access Group
- SPN Registration:
- Verified that
HTTP/portal.domain.com
was registered on theserv-iis
computer account, as IIS was running under the Network Service account. - Used the following command to confirm the SPN:
setspn -L serv-iis
- Verified that
- Delegation Settings:
- Checked that
serv-app101
was configured to trust for delegation to theHTTP/portal.domain.com
SPN.
- Checked that
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 toserv-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
andserv-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
- Enable Kerberos event logging - Windows Server | Microsoft Learn
- Configure KCD for Application Proxy applications with SSO
- 4769(S, F) A Kerberos service ticket was requested. - Windows 10 | Microsoft Learn
- KDC_ERR_C_PRINCIPAL_UNKNOWN in S4U2Self request - Windows Server | Microsoft Learn
- Understanding the Windows Authorization Access Group