Understanding Microsoft Kerberos PAC Validation

[アーティクル]
04/24/2009

This blog post focuses on understanding Microsoft Kerberos PAC validation. It discusses the topic from inter-operability perspective with Windows operating systems. A SMB session establishment scenario is used to illustrate how PAC validation works.

Background

Impersonation enables a trusted identity to act on behalf of another identity to perform an action. The trusted identity is usually a service account that is granted a set of elevated privileges to access resources and executes tasks.

The Privilege Account Certificate (PAC) is an extension element of the authorization-data field contained in the client's Kerberos ticket. The PAC structure is defined in [MS-PAC] and conveys authorization data provided by domain controllers (DCs) in an Active Directory-enabled domain. It contains information such as security identifiers, group membership, user profile information, and password credentials. The illustration below shows the relationship between a Kerberos ticket and PAC.

Figure 1: PAC in Kerberos Protocol Extensions

MS-KILE specifies extensions that enable PAC support. The KDC generates the PAC under one of the following conditions:

- During an Authentication Service (AS) request (KERB-AS-REQ) that includes a KERB-PA-PAC-REQUEST PA-DATA as part of the pre-authentication data.

- During a Ticket Granting Service (TGS) request for a cross-realm referral TGT ([RFC4120]) when the client’s TGT does not include a PAC.

- During a TGS request when the client has domain local groups.

The KDC searches Active Directory for the user or computer account. It creates the PAC structure, including information such as direct and transitive group membership, and encodes it into the TGT in an AD-IF-RELEVANT element of the authorization data ([RFC4120] section 5.2.6). Another KDC may subsequently update the PAC when the client requests a TGS with additional server’s domain local groups. It should also be noted that the KDC default behavior is to generate a PAC, unless a client explicitly requests the PAC be excluded from the ticket through the use of KERB-PA-PAC-REQUEST.

PAC validation is a security feature that addresses PAC spoofing, preventing an attacker from gaining unauthorized access to a system or its resources by using a tampered PAC. This is critical in applications where user impersonation is utilized. PAC validation ensures the user presents exact authorization data as it was granted in the Kerberos ticket.

One key reason why a PAC should be verified as unaltered is to ensure that no additional privileges have been maliciously added to - or removed from - the ticket. This makes the PAC validation an important consideration when designing applications that impersonate users and access sensitive data, or applications that grant administrative privileges.

Kerberos PAC validation

Figure 2: Kerberos PAC validation

Note: The terms client and server refer to the definitions in Kerberos terminology.

The server’s OS performs Kerberos PAC validation to protect from a man in the middle attack tampering with the PAC structure. PAC validation is not required for Microsoft Kerberos Extensions [MS-KILE] protocol compliance. It is however an additional security measure designed to prevent the attack described above. In the simplest an OS can always validate the PAC signature. Since the PAC is encoded as an AD-IF-RELEVANT element of the AuthorizationData field of the ticket, the server can ignore the data if it does not consume the information in the PAC.

PAC validation occurs in the security context of the server’s process where the user is being impersonated. An application server that is interoperating with a Windows KDC through MS-KILE and MS-APDS will base its criteria upon which it will send PAC validation messages to the DC.

Note that there must be a trust relationship between the application server and the DC. In a single forest environment, the trust implicitly exists.

When the PAC validation occurs, the server encodes a KERB_VERIFY_PAC_REQUEST request message [MS-APDS] and transmits it to the DC through generic pass-through mechanism [MS-NRPC]. The DC decodes the request and extracts the server checksum and the KDC checksum values. If the checksum verification succeeds, the DC returns a success code to the server. An unsuccessful return code indicates that the PAC has been altered.

Performing PAC validation implies a cost in terms of response time and bandwidth usage. It requires bandwidth usage to transmit requests and responses between an application server and the DC. This may cause some performance issues in high volume application servers (KB906736). In such environments, user authentication may induce additional network delay and traffic for carrying PAC validation messages between the server and the DC.

Kerberos PAC validation in Windows

In Windows implementation, the application server derives the authorization data (PAC) and requests Windows OS to generate an access token . The access token encapsulates account's identity, group memberships, and system privileges, and is used to make authorization decisions.

Windows OS uses the identity of the application server to determine when it needs to validate the PAC. Services that are running as part of the Windows OS do not perform PAC validation. They carry out server signature verification on the PAC by using the long-term key that the KDC shares with the server.

The OS sends PAC Validation messages to the DC (through NRPC) when it wants to ensure the PAC has not been tampered. It involves the DC to validate the PAC when a non-privileged application attempts to authenticate a ticket.

Windows OS sends the PAC validation messages to the NetLogon service of the DC when the service does not have the TCB privilege and it is not a Service Control Manager (SCM) service. The Local Security Authority Subsystem Service (LSASS) process will send PAC validation messages to the DC when the LSA client (the application server) is not running in the context of local system, network service, or local service; or it does not have SeTCBprivilege (Act as part of the operating system).

User rights: Act as part of the operating system

This policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access is not limited to what is associated with the user by default. The calling process may request that arbitrary additional privileges be added to the access token. The calling process may also build an access token that does not provide a primary identity for auditing in the system event logs.

Note: SeTcbPrivilege enables to assign a user account the right to “Act as Part of the operating system”. Local system, network service and local service accounts are Windows-defined Service User Accounts. Each account has a set of specific privileges attached to it.

Windows Server 2003 SP2 has introduced the option for controlling PAC validation on a server-wide basis for application services that are authenticating users. The ValidateKdcPacSignature registry key was added to enable or disable PAC verification for services (KB 906736).

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]

“ValidateKdcPacSignature”=dword:00000001

When the value of this entry is 0, Kerberos does not perform PAC validation on a process that runs as a service. When the value of this entry is 1, Kerberos performs PAC validation as usual. You have to restart the computer after you modify this registry entry. When this entry is not present, the system behaves as if the entry is present and has a value of 1. The default value in Windows Server 2008 for this entry is 0.

In a nutshell, two main conditions prevent PAC validation from occurring in Windows OS:

- the application has the SeTcbPrivilege privilege (“Act as part of the operating system”);

- the application is a service and the ValidateKdcPacSignature registry key is set to disable PAC validation.

Example of SMB scenario in Windows

The client tries to access a Windows SMB share requiring Kerberos authentication. It sends the security token in the KRB_AP_REQ during session establishment. Windows SMB/CIFS server service requests the OS to create an access token. Now it needs to decide how to perform PAC validation.

Windows SMB/CIFS server service runs under Local System Account. In terms of Kerberos terminology, the SMB/CIFS service represents the application server. The Local System Account has SeTCBPrivilege (SE_TCB_NAME privilege enabled). As a result, Windows OS will not be sending PAC validation messages to the DC. Only the server signature in PAC_SIGNATURE_DATA will be checked to determine if the PAC is valid. This verification is done thanks to the long-term key that the KDC shares with the server. Typically, when you establish SMB_SESSION_SETUP to a Windows member server, the server signature of the PAC from KRB_AP_REQ in the KerberosToken is checked.

Note: You can use the Process Explorer tool to identify the service account of a running process and check if it has the SeTcbPrivilege.

Conclusion

PAC validation reinforces a more secure authorization environment in Kerberos authentication setting where impersonation occurs. From inter-operability standpoint, an application server that is inter-operating with a Windows DC needs to decide the criteria upon which it requires to initiate the exchange of PAC verification messages with the DC. There is an inherent cost of network delay and bandwidth usage when PAC validation occurs between the server and the DC.

Windows operating systems use the SeTcbPrivilege privilege or the ValidateKdcPacSignature registry key to control PAC validation. When deploying an application, careful assessment is needed before assigning the SeTcbPrivilege right to an account in order to disable PAC validation. The caveat is that the “Act as part of the operating system” (SeTcbPrivilege) right may give excessive privileges to an application that is impersonating clients.

On the other hand, the security context of the application – typically the security context token that includes a service relative identifier – determines whether the ValidateKdcPacSignature registry key can disable PAC validation. In a Windows trusted service security context, the PAC signature is always verified as a minimal validation.

References

[RFC4120] The Kerberos Network Authentication Service (V5)

[MS-KILE] Kerberos Protocol Extensions

[MS-PAC] Privilege Attribute Certificate Data Structure

[MS-SECO] Windows Security Overview

[MS-APDS] Authentication Protocol Domain Support Specification

[MS-NRPC] Netlogon Remote Protocol Specification

Additional details: Blog of Tim Springston.