Understanding Kerberos Delegation: Purpose, Types, and Security Implications

A few days ago, while discussing Kerberos delegation with a friend and its potential to enhance security within systems using Active Directory, I decided to write this post to share my insights. Enjoy, and let’s dive in!

Kerberos delegation has been a critical part of Windows Server architecture. Yet, many engineers working with Active Directory may not fully understand its various implementations, their specific uses, and potential security risks. Often, Kerberos delegation is mistakenly conflated with delegated permissions. This post aims to clarify these concepts and highlight best practices for managing delegation securely.

What is Kerberos Delegation?

At its core, Kerberos delegation allows an application to access resources on behalf of a user, enabling seamless interaction between services across different servers. For instance, consider a web application that needs to access a SQL database. Instead of granting the web server’s service account direct access to the database, you can configure Kerberos delegation. When a user logs into the web application, the service account requests access to the SQL database on their behalf. This approach secures user access by ensuring that the web server’s service account does not have direct permissions to the database.

What is Service Principal Name (SPN)?

A Service Principal Name (SPN) is a unique identifier for a service instance in a network that uses Kerberos authentication. It allows clients to identify and authenticate the services they want to access, particularly in environments like Active Directory. Understanding SPNs is crucial for managing authentication and ensuring that services can communicate securely and effectively.

An SPN is a string that uniquely identifies a service running on a server. It consists of several components:

• Service Type: Indicates the type of service (e.g., HTTP, MSSQL, CIFS).
• Host Name: The fully qualified domain name (FQDN) or hostname of the server.
• Port Number: Optional; specifies the port on which the service is running. If omitted, the default port for the service type is used.

MSSQLSvc/myserver.example.com:1433

SPNs Important are important, because SPNs are integral to Kerberos authentication, allowing the Kerberos Key Distribution Center (KDC) to issue tickets that validate the identity of the service. By using SPNs, clients can ensure they are connecting to the correct service instance, mitigating the risk of man-in-the-middle attacks. So, SPNs play a crucial role in Kerberos delegation, allowing services to authenticate on behalf of users securely.

Configuring SPNs:

# Add an SPN
setspn -A MSSQLSvc/myserver.example.com:1433 DOMAIN\serviceAccount

# List SPN
setspn -L DOMAIN\serviceAccount

# Delete SPN
setspn -D MSSQLSvc/myserver.example.com:1433 DOMAIN\serviceAccount

Working with SPNs we may deal with common issues, such as, having multiple SPNs for the same service can cause authentication failures. If a service cannot find its corresponding SPN, clients may fail to authenticate. This often requires adding the appropriate SPN. SPNs issues can lead to failed Kerberos authentication attempts, resulting in access problems for users and applications.

Types of Kerberos Delegation

Over the years, several types of Kerberos delegation have evolved, each offering varying levels of security:

1. Unconstrained Delegation
2. Constrained Delegation
3. Resource-Based Constrained Delegation

Let’s dive deeper into each type.

Configuring Delegation in Active Directory

To configure delegation, navigate to the Delegation tab in Active Directory Users and Computers. Note that user accounts must have a Service Principal Name (SPN) set.

• The first option prevents an account from being trusted for delegation, ideal for sensitive or administrative accounts.
• The second option enables unconstrained delegation.
• The third option allows for constrained delegation.

Unconstrained Delegation

Unconstrained delegation is the original — and least secure — method of delegation. When this option is enabled, the userAccountControl attribute is modified to include the “TRUSTED_FOR_DELEGATION” flag. This allows a host to store a user’s Ticket Granting Ticket (TGT) in memory, enabling impersonation of that user for various services.

This put significant security risks. For example, if a privileged account authenticates to a server configured for unconstrained delegation, it can access any service within the domain as that user. Additionally, vulnerabilities like the “printer bug” can allow attackers to force privileged accounts to authenticate to their servers, compromising security.

Unconstrained delegation should be avoided whenever possible. Domain controllers are configured for unconstrained delegation by default, but their security is typically higher than other application servers.

Constrained Delegation

Constrained delegation allows administrators to specify which services an account can delegate to. This provides a more secure alternative to unconstrained delegation, limiting potential exposure in the event of a compromise.

When constrained delegation is configured, two things happen:

1. The userAccountControl attribute is updated with the “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION” flag.
2. The msDS-AllowedToDelegateTo attribute is populated with the SPN configured in the delegation tab.

However, constrained delegation has its own vulnerabilities. If an attacker compromises the plaintext password or NTLM hash of an account with constrained delegation, they can request TGTs and access services as that user.

Resource-Based Constrained Delegation

Resource-based constrained delegation allows resource owners to specify which objects can delegate access to them. This model enhances security by granting control to resource owners rather than requiring them to specify which accounts can delegate access.

To configure resource-based constrained delegation, use PowerShell to populate the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target resource with the SID of the delegating object.

Unfortunately, this configuration cannot be done through the Active Directory Users and Computers GUI.

Conclusion

Service Principal Names (SPN) are a fundamental component of Kerberos authentication in Active Directory environments. Proper configuration and management of SPNs are essential for ensuring secure and efficient service access. By understanding SPNs, we can better secure networks and troubleshoot authentication issues effectively.

Understanding and properly configuring Kerberos delegation is crucial for maintaining the security of your Active Directory environment. By choosing the right type of delegation and regularly auditing your configurations, you can mitigate risks while enabling necessary application functionality.