Troubleshooting "KDC_ERR_C_PRINCIPAL_UNKNOWN" in S4U2Self Requests on Windows Server

Table of Contents

When application servers on Windows Server need to perform authorization checks for users who are not directly logged on to the server, they often rely on advanced Kerberos features like Service for User to Self (S4U2Self). This mechanism allows a service to obtain a Kerberos service ticket for itself, but acting on behalf of another user. This ticket contains the user’s authorization data, such as security identifiers (SIDs) and group memberships, which can then be used for local access checks via APIs like AuthZ. However, this process can sometimes fail with the error KDC_ERR_C_PRINCIPAL_UNKNOWN, preventing the application from correctly identifying and authorizing the user.

This issue typically arises in scenarios where an application server accepts user identities through means other than standard Kerberos logon to the server machine. Common examples include web servers like Internet Information Services (IIS) configured to accept user certificates for authentication, or custom line-of-business applications that handle user authentication internally and then need to verify user roles based on Active Directory group memberships using the AuthZ API. The server, needing to understand the user’s security context for local resource access or role determination, initiates an S4U2Self request to a Key Distribution Center (KDC), typically a domain controller. If this request fails, the user may be unable to access the application’s resources or functionality.

Symptoms: Identifying the KDC_ERR_C_PRINCIPAL_UNKNOWN Error¶

Identifying this specific issue often involves capturing and analyzing network traffic between the application server and the domain controllers. Network trace tools such as Microsoft Network Monitor or Wireshark are essential for this diagnostic step. By filtering the traffic for the Kerberos protocol (typically UDP or TCP port 88), administrators can observe the sequence of requests and responses exchanged during the S4U2Self process.

Initially, you might observe several TGS-REQ (Ticket Granting Service Request) packets containing PaData Type PA-PAC-REQUEST (type 128). These requests are part of the standard Kerberos exchange flow and might fail with transient errors such as KDC_ERR_C_PRINCIPAL_UNKNOWN (error code 6) or KDC_ERR_PREAUTH_REQUIRED (error code 25). Error code 6 in this context usually indicates that the specific domain controller contacted does not host the user’s account, prompting the client (the application server) to try a different DC. Error code 25 is also standard and indicates that pre-authentication data is required, which is part of how the S4U2Self process validates the user’s identity context. These initial errors, while present in the trace, are generally not fatal and the client is expected to retry or contact a different KDC.

The critical symptom occurs with the final TGS-REQ packet specifically formatted for S4U2Self. This request will contain PaData Type PA-FOR-USER (type 129). In this packet, the SName field will represent the Service Principal Name (SPN) of the application server performing the request, and the PaForUser structure within the PaData will contain the User Principal Name (UPN) or other identifier of the user whose security context the server is attempting to obtain. The client initiating this request is the application server itself. When this specific PA-FOR-USER request is sent to a reachable and authoritative KDC (a domain controller in the user’s domain or a trusted domain), and it fails with the error KDC_ERR_C_PRINCIPAL_UNKNOWN (error code 6), this indicates a fatal issue preventing the S4U2Self process from completing successfully. This is the key diagnostic indicator of the problem described in this article.

Analyzing the network trace frame by frame, especially using tools that can reassemble Kerberos messages spanning multiple packets (like Network Monitor 3.x or Wireshark with appropriate dissectors), is crucial. The focus should be on the TGS-REQ with PA-FOR-USER and the corresponding TGS-REP from the KDC. The error code 6 in the TGS-REP to this specific request confirms the presence of this issue. Other error codes on this final request would suggest different underlying problems.

Cause: Permission Denied to Access User Attributes¶

While the error message KDC_ERR_C_PRINCIPAL_UNKNOWN literally translates to “client principal unknown to KDC,” in the specific context of a failing S4U2Self request containing PA-FOR-USER, this error code often masks a more specific underlying problem: an access denied error when the KDC attempts to read necessary user attributes on behalf of the requesting service.

The S4U2Self process requires the KDC to gather specific information about the target user to construct the authorization data (including SIDs and group memberships) that will be included in the service ticket issued to the calling service. A critical piece of information needed for this is the user’s group membership information, particularly universal and global group memberships which are essential for authorization checks across domains within a forest or via trusts. Active Directory Domain Controllers compute this information dynamically and make it available through constructed attributes like TokenGroupsGlobalAndUniversal.

Accessing these constructed attributes, or the underlying data required to compute them, requires specific permissions on the user object within Active Directory. By default, standard security principals have certain read permissions on user objects. Historically, the Authenticated Users security group is granted permissions sufficient to read many user attributes, including those necessary for the KDC to fulfill standard requests and construct necessary authorization data for features like S4U2Self.

However, Active Directory permissions are hierarchical and can be modified at various levels (domain, Organizational Unit, individual object). If the default permissions on user objects have been altered or removed, specifically the permissions that allow reading the data required to compute TokenGroupsGlobalAndUniversal, the KDC, acting on behalf of the service account making the S4U2Self request, will encounter an access denied error. Although the underlying issue is a permission problem, the Kerberos protocol in this specific S4U2Self context returns the generic KDC_ERR_C_PRINCIPAL_UNKNOWN error (code 6) rather than a more explicit access denied error. This is because from the KDC’s perspective, it cannot fully “know” or process the principal (the user) in the context requested by the service if it lacks the permissions to retrieve all required attributes.

Resolution: Granting Necessary Access via Windows Authorization Access Group¶

The standard and recommended solution to address this specific KDC_ERR_C_PRINCIPAL_UNKNOWN error in S4U2Self requests is to ensure that the security principal performing the S4U2Self request (typically the service account under which the application server is running) has sufficient permissions to read the necessary user attributes. The most straightforward way to achieve this is by adding the service account to the built-in Windows Authorization Access Group.

The Windows Authorization Access Group (WAAAG) is a special-purpose security group in Active Directory designed to grant read access to calculated attributes on user and computer objects that are needed by authorization components, including those used in S4U2Self and other authorization scenarios. By default, this group is granted “Read Property” permissions on user and computer objects specifically allowing access to attributes like TokenGroupsGlobalAndUniversal.

Steps to Resolve:

1. Identify the Service Account: Determine which Active Directory user or computer account the application server or the specific application pool/service that performs the S4U2Self request is running under. This could be a dedicated service account, Network Service, Local System, or even a user account if the application is configured that way. If it’s a built-in account like Network Service or Local System, the identity that needs permissions is the computer account of the server itself (DOMAIN\ServerName$).
2. Locate the Windows Authorization Access Group: Open “Active Directory Users and Computers” on a domain controller or a management workstation. The Windows Authorization Access Group is located in the Builtin container in the domain where the user accounts reside.
3. Add the Service Account: Right-click the Windows Authorization Access Group, select “Properties,” go to the “Members” tab, and click “Add.” Add the service account identified in step 1 to this group. If it’s a computer account, remember to click “Object Types” and select “Computers.”
4. Apply Changes: Click “OK” to save the changes.
5. Restart the Service: For the permission change to take effect, the service or application pool running on the server under that account typically needs to be restarted. This ensures that the service account’s Kerberos ticket (or other credentials cache) is refreshed to include the new group membership. In some cases, a server reboot might be necessary, especially if the service runs under a built-in account or if the account is heavily cached.

By adding the service account to the Windows Authorization Access Group, you grant it the default necessary permissions to read the constructed user attributes required by the KDC during the S4U2Self process. This should allow the KDC to successfully build the authorization data for the user and issue the service ticket to the application server.

Considerations:

• Permissions Changes: If the default permissions on the Windows Authorization Access Group itself, or the permissions granted to it on user objects, have been explicitly modified or removed from their defaults, simply adding the account to the group may not be sufficient. In such rare cases, you might need to investigate the NTFS and Active Directory permissions on user objects to ensure the WAAAG still has the required read access, or manually grant read permissions for the relevant attributes (like TokenGroupsGlobalAndUniversal) to the service account or a custom group containing it. However, modifying default AD schema or object permissions requires extreme caution.
• Nested Groups: Ensure that group policy or other scripts aren’t removing accounts from WAAAG or altering its permissions after you’ve made the change.
• Replication: Allow sufficient time for Active Directory replication to occur if you are making changes on a domain controller and the application server is authenticating to a different DC.

Adding the service account to WAAAG is generally a safe and effective way to restore the required read permissions for S4U2Self scenarios without granting excessive privileges.

More Information and Related Concepts¶

Understanding the context of S4U2Self requests and related technologies provides further clarity on this issue.

S4U2Self vs. S4U2Proxy: S4U2Self is one part of the Kerberos constrained delegation framework, sometimes referred to as Service for User (S4U). S4U2Self allows a service (Service A) to obtain a service ticket for itself (Service A), acting on behalf of an arbitrary user. This ticket is primarily for Service A to perform local authorization checks based on the user’s identity. S4U2Proxy (Service for User to Proxy), the other part, allows Service A to obtain a service ticket to access a different service (Service B), still acting on behalf of the original user. This is true delegation. The issue described here specifically relates to the S4U2Self part, focusing on the server’s ability to get a ticket representing the user for its own use.

Certificate Logon and S4U2Self: When a web server like IIS is configured for certificate authentication, the user presents a certificate instead of a password or Kerberos ticket initially. After validating the certificate, IIS (or the underlying Windows security subsystem) needs to obtain a Windows security context for that user to perform access checks on local resources (like files, directories, or application functions protected by ACLs). It does this by mapping the certificate to an Active Directory user account and then performing an S4U2Self request to get a service ticket containing the user’s authorization data. If the KDC cannot read the user’s group memberships due to the permission issue, the S4U2Self request fails, and the user cannot log on or access resources despite presenting a valid certificate. This scenario highlights why the problem is independent of the Public Key Infrastructure (PKI) setup itself – the PKI successfully authenticated the user; the failure occurs after authentication, during the authorization data retrieval step via Kerberos.

AuthZ API and Authorization Checks: The AuthZ (Authorization) API on Windows is a set of functions that allow applications to perform access checks based on a security context (represented by an access token) against secured objects. Applications that use the AuthZ API for role-based authorization often need to know all the groups a user is a member of to evaluate permissions correctly. S4U2Self provides the mechanism for a server application to obtain an access token for a user authenticated by a non-Kerberos method, making it possible to use the AuthZ API to perform these checks using the user’s full group membership list obtained from Active Directory. If S4U2Self fails, the server cannot get the user’s access token and thus cannot perform granular authorization checks using the AuthZ API.

Cross-Forest Scenarios: This issue is not limited to users and servers within the same Active Directory domain or forest. If a user from Forest A authenticates to a server in Forest B (where a trust exists), the server in Forest B needs to obtain the user’s authorization data from a KDC in Forest A (via the trust path) using S4U2Self. The same permission requirement applies: the KDC in Forest A, when processing the S4U2Self request originating from Forest B, needs permission to read the user’s attributes in Forest A. Adding the Forest B server’s computer account (or service account) to the Windows Authorization Access Group in Forest A is typically required in this cross-forest scenario, in addition to ensuring the trust is correctly configured and potentially enabling selective authentication if desired.

Selective Authentication: If a trust relationship uses selective authentication, the service account performing the S4U2Self request (or the computer account if running under Network Service/Local System) must have the “Allowed to Authenticate” permission explicitly granted on the user object in the trusted forest. However, this permission is different from the permission required to read the TokenGroupsGlobalAndUniversal attribute. The KDC_ERR_C_PRINCIPAL_UNKNOWN error related to attribute access due to WAAAG permissions is distinct from failures caused by missing “Allowed to Authenticate” permissions in selective authentication scenarios, though both can prevent successful S4U2Self.

Access Token Limitations: It’s important to note that the access token obtained via a successful S4U2Self request is primarily intended for authorization checks on the server that initiated the request. This token does not automatically grant the server the ability to impersonate the user for delegation to other services (which would require S4U2Proxy and potentially Kerberos constrained delegation configuration). The KDC_ERR_C_PRINCIPAL_UNKNOWN error discussed here occurs at an earlier stage, preventing even the basic authorization token for the local server from being generated.

Visualizing the Kerberos S4U2Self Flow¶

Understanding the Kerberos exchange helps visualize where the error occurs. Here is a simplified flow:

```mermaid
sequenceDiagram
participant AppServer as Application Server
participant KDC as Key Distribution Center (Domain Controller)

Note over AppServer: User authenticated via non-Kerberos method (e.g., Certificate)
AppServer->KDC: TGS-REQ (PaData: PA-FOR-USER [User's UPN], SName: AppServer's SPN)
Note over KDC: KDC receives request, validates AppServer's identity
Note over KDC: KDC attempts to read User's attributes (e.g., TokenGroupsGlobalAndUniversal) to build auth data
alt KDC has permission to read attributes
    KDC-->AppServer: TGS-REP (Service Ticket for AppServer, containing User's auth data)
    Note over AppServer: AppServer uses ticket/auth data for local authorization checks
else KDC lacks permission to read attributes (e.g., WAAAG issue)
    KDC-->AppServer: TGS-REP (Error: KDC_ERR_C_PRINCIPAL_UNKNOWN - Code 6)
    Note over AppServer: S4U2Self failed, authorization checks impossible
end

```

This diagram illustrates that the KDC_ERR_C_PRINCIPAL_UNKNOWN error specifically happens when the KDC is processing the PA-FOR-USER request and fails to gather the necessary user attribute data, which it needs to generate the authorization data within the service ticket.

Conclusion¶

The KDC_ERR_C_PRINCIPAL_UNKNOWN error encountered during S4U2Self requests on Windows Server, particularly those containing the PA-FOR-USER PaData type, is a strong indicator of a permissions issue preventing the Key Distribution Center from reading essential user attributes like TokenGroupsGlobalAndUniversal. This typically occurs when the default permissions allowing access to these constructed attributes have been altered. The most effective resolution is to add the service account performing the S4U2Self requests to the Windows Authorization Access Group, which is specifically designed to grant the necessary read permissions for such scenarios. By ensuring the service account has this membership and restarting the relevant service, administrators can often resolve this error and allow applications relying on S4U2Self for authorization to function correctly.

Have you encountered this specific KDC_ERR_C_PRINCIPAL_UNKNOWN error in your environment? What steps did you take to troubleshoot and resolve it? Share your experiences or questions in the comments below.