Kerberos is an open authentication protocol based on UDP that allows users to securely do Single Sign-On (SSO). Kerberos is enabled by default on the Windows Servers when Active Directory (AD) is used. All the Blue Coat ProxySG are Kerberos capable when correctly configured with an IWA realm.

The Kerberos error message "KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN" occurs on the client side when it is trying to retrieve a Kerberos ticket-granting ticket (TGT) from the Active Directory Domain Controller when authenticating against the proxy. The consequence of this error message is that the SSO fails and the users are requested to enter manually the credentials in the web browser.

This specific error has been documented on Microsoft's side since early 2023. Here are the key details:

• Microsoft URL: https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kdc-err-c-principal-unknown-s4u2self-request
  
  
• Cause:
  
  
  • The Kerberos error is actually an Access is Denied error for reading this attribute. The S4U2Self request is accessing the TokenGroupsGlobalAndUniversal user-constructed attribute and requires permission to do so. By default, authenticated users have these permissions.
    
    

Other documented causes for this error are:

• when the Domain Controllers have DNS resolution issues. "S_PRINCIPAL_UNKNOWN" means that the Kerberos Service Principal is unknown or cannot be resolved. All the DNS servers of the network must have proper DNS records of the Blue Coat ProxySG. This means that all must have the Fully Qualified Domain Name (FQDN) of the Blue Coat ProxySG pointing to an IP address and the reverse DNS records as well.
  
  
• when the Active Directory forest functional level is quite old (2003 and lower) and not very compatible with the recent Kerberos clients. The UDP packets sent by the Windows Server can be malformed and unreadable by the Kerberos client. In this situation, the error message "KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN" comes after another error message: "KRB5KRB_ERR_RESPONSE_TOO_BIG".
  
  

Here is the documented resolution from Microsoft:

• If these permissions have been changed or otherwise revoked, you need to add the requesting accounts to the Windows Authorization Access Group. By default, this group has the required access on all user and computer accounts. If you have also changed the permissions of Windows Authorization Access Group, you need to construct the permissions or use a custom group to grant the permissions.

Other documented resolutions (prior to the Microsoft article in 2023):

• Verify that the Blue Coat ProxySG is correctly populated in the DNS Servers of all the Domain Controllers in the network. DNS name resolution and reverse IP resolution must be tested on each and every Domain Controller. In the same vein, all of the Domain Controllers must have an FQDN that can be resolvable by the Blue Coat ProxySG to prevent additional issues.
• If facing the error "KRB5KRB_ERR_RESPONSE_TOO_BIG" as shown in the picture above, the solution recommended by Microsoft is to force Kerberos over TCP in place of the default protocol UDP. Please refer to the official Microsoft documentation.

Workaround

Upgrading the AD to a higher functional level of can be helpful as this Kerberos server/client compatibility problem should be fixed with the forest functional level 2008 and higher.