Kerberos is a network authentication protocol that enables clients, nodes, and services communicating over a network to connect to one another in a secure manner. In simple terms, it verifies the identity of a user or host. In this article, we shall discuss ‘Kerberos Delegation: A Comprehensive Guide”. You may also want to learn about SPNs, here are some guides: How to add, reset and delete SPNs, and FindDomainForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x0000054B, unable to locate an account.
Kerberos accomplishes robust authentication for client/server applications through the utilization of secret-key cryptography. Yes, Kerberos has been around now for a long period of time, to be precise since Windows Server 2000.
For an overview of Kerberos, please see this link. Kerberos delegation enables applications to request end-user access credentials to access resources on behalf of the originating user.
In short, Kerberos delegation enables an application to access resources hosted on a different server.
Here are some Kerberos-related guides: How to configure a service account for Kerberos delegation, Service Principal Name: How to add, reset and delete SPNs, and what is Pass the Hash Attack and how to mitigate the attack.
Why Kerberos Delegation?
As you run applications, there may be a need for those applications to access resources in the context of a different user. Active Directory Domain Services (AD DS) supports a mechanism called Kerberos delegation that enables this use-case.
Kerberos-constrained delegation (KCD) further improves this mechanism by creating user-specific resources that users can access within their respective contexts.
Many often misconstrue this topic, with some even conflating it with “Permission Delegation.”Here is an example of a Kerberos delegation. “When an application (E.g. MBAM Administration and Monitoring Website and the Self-Service Portal) accesses resources hosted on a different server (MSSQL database).
Instead of directly granting the service account running the web server access to the database, you can enable delegation of that service account to the MSSQL server service.
Once a user logs into the website, the service account will request access to the SQL server service on behalf of that user. This grants the user access to the content within the database for which they have been provisioned.
You may want to learn how this was implemented in this guide “MBAM components: How to deploy Microsoft BitLocker Administration and Monitoring Tool“.
What risk does unsecured Kerberos delegation pose to an organization?
Unsecure Kerberos delegation gives an entity the ability to impersonate you for any other chosen service. For example, consider an IIS website where the application pool account is set up with unconstrained delegation.
The IIS website also has Windows Authentication enabled, which allows native Kerberos authentication, and the site uses a back-end SQL Server for business data. With your “Domain-Admin account“, you can browse to the IIS website and authenticate to it.
The website, using unconstrained delegation can get a service ticket from a domain controller to the SQL service, and do so in your name.
Kerberos delegation types and Risks they Pose
The main issue with Kerberos delegation is that you need to trust the application to always do the right thing. Malicious actors can instead force the application to do the wrong thing.
The risk is clear and the possibilities with unsecure delegation are nearly endless. The following is a description of the risk posed by different delegation types:
- Unconstrained delegation: Any service can be abused if one of its delegation entries is sensitive.
- Constrained delegation exposes constrained entities to abuse if any of their delegation entries are sensitive. A common method of abuse arises when attackers successfully compromise the plaintext password or NTLM hash of a user account configured for constrained delegation.
By employing a tool like Kekeo, attackers can request a TGT for the account possessing the password, perform TGS requests for any user (except those marked as ‘Sensitive’), and subsequently inject the ticket, enabling access to the requested service under that user’s identity.
You may want to see Active Directory Authentication methods: How do Kerberos and NTLM work, what is Pass the Hash Attack, and how to mitigate the attack? - Resource-based constrained delegation (RBCD): Abusers can exploit resource-based constrained entities if the entity itself holds sensitivity. You can leverage Rubeus to abuse RBCD
How to create a Kerberos delegation
Unconstrained Delegation
Microsoft introduced this delegation form in Windows Server 2000, often referred to as Full Delegation. This is the first implementation of delegation, and also the least secure.
Under the hood, when unconstrained delegation is configured, the userAccountControl attribute of the object gets updated to include the “TRUSTED_FOR_DELEGATION” flag. When an object authenticates to a host with configured unconstrained delegation, the host stores the ticket-granting ticket (TGT) for that account in memory, enabling later impersonation of the user if necessary.
In this sort of delegation, the service acquires a valid TGT for the client in the following way. The client sends the TGT to the service. When the client requests a TGS for a service which has Unconstrained Delegation active.
Then the KDC includes a TGT (of the client) inside the TGS. More precisely, it’s the segment of the ticket encrypted with the service owner key that includes it. Thus, upon receiving the TGS, it can access the client TGT.
Risks involved
This type of delegation is not considered secure because an administrator cannot control the services that the server can access using the client identity.
Configuring unconstrained delegation exposes the potential for attackers to compromise credentials. Imagine a situation where a domain administrator uses an IIS website that has its application pool account set for unconstrained delegation.
Enabling Windows Authentication on the site empowers it to obtain a service ticket from a domain controller and authenticate as a domain admin to any desired service. However, if the website or database becomes compromised, that chosen service may require reevaluation, typically aiming for a database.
How to Configure an Unconstrained Delegation
To configure delegation on a computer or user account, use the Delegation tab in Active Directory Users and Computers, as shown below. For Unconstrained delegation, see the image below.
In addition to Unconstrained, there are 2 more kinds of delegation which we will be discussing below. In any of these Contrained delegation or Role based Contrained delegation (RBCD), the delegation is constrained to only some allowlisted third-party services
Constrained Delegation
Windows Server 2003 introduced Kerberos constrained delegation as a more secure delegation option suitable for services. It enables the configuration of services to which an account can be delegated.
In other words, system administrators can utilize constrained delegation to restrict the services that an impersonated account can connect to. This in turn limits the potential exposure if a compromise were to occur. When configured, constrained delegation confines the specified server’s ability to act on behalf of a user to specific services.
Windows Server 2012 supports constrained delegation across domains, allowing front-end services to configure constrained delegation for authenticating to servers in different domains.
This provides support for across domains service solutions by using an existing Kerberos infrastructure. Domain administrators or service administrators can manage Kerberos constrained delegation.
Note: With traditional Kerberos constrained delegation (KCD), this was not possible and it was restricted to a single domain.
When setting constrained delegation on an account, two things occur behind the hood:
- The userAccountControl attribute for the object gets updated with the “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION” flag.
- The msDS-AllowedToDelegateTo attribute gets populated with the SPN configured on the delegation tab.
Note that user accounts must have a servicePrincipalName (SPN) set. After you have the SPN configured, you should set up constrained delegation on the SPN.
Here is a practical use case (MBAM 2.5 requies SPN to be configured before configuring constrained delegation). In order not to miss things up, at the end of this guide, I will throw more light on SPN.
How to Configure a Constrained Delegation
To configure constrained delegation, follow these steps:
- Go to Active Directory, and find the app pool credentials that you configured for MBAM websites in the previous steps.
- Right-click the credentials, and then select properties.
- Select the delegation tab.
- Select the option for Kerberos authentication.
Kindly have a look on how to configure Kerberos Contrained Delegation.
Resource Based Constrained Delegation
As described above, Kerberos delegation has evolved. Microsoft introduced this delegation form in Windows Server 2012 and beyond, empowering administrators to configure constrained delegation for their services. This model is known as resource-based KCD.
With resource-based constrained delegation, administrators can restrict the usage of the client identity by the services. In this delegation method, the client does not forward TGT to the server. The services specify who they trust and who can delegate authentication to them.
This improves on the constrained delegation model by removing the dependency on SPNs, and the need for domain admin rights, allows the resource owner to control delegation, and provides for cross-domain delegation. It works on computer accounts, user accounts, and service accounts.
Instead of using an allowed list of SPNs, Windows Server 2012 controls delegation using security descriptors. Backend server administrators define which security principals can request Kerberos tickets for another user.
When a backend service gets a request from a frontend server to grant access on another user’s behalf, the AD Key Distribution Center (KDC) examines the security descriptor in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the security principal operating the backend service. If the descriptor aligns with that of the frontend service, access is authorized.
Resource-based constrained delegation is managed using Windows PowerShell.
How then can Kerberos create a allowlist of services?
Kerberos is unable by itself to create special tickets to implement delegation for specific groups of services. For this reason, Microsoft implemented 2 Kerberos extensions that allow it to obtain this desired behavior.
Constrained delegation uses Kerberos protocol extensions called Service for User (S4U) that allow a service to obtain a Kerberos service ticket on behalf of a user. This help restrict which entries can impersonate the web service account.
You can configure the Resource-based KCD using PowerShell, as mentioned earlier. Below are the two Kerberos extensions
- Service for User to Proxy (S4U2Proxy): This extension allows a service to obtain a service ticket to another service on behalf of a client user. To perform S4U2proxy, a service needs a service ticket itself. As mentioned earlier, you have the ability to configure the Resource-based KCD using PowerShell.
- Service for User to Self (S4U2Self): This extension allows a service to get a service ticket to itself on behalf of a client user.
These extensions enable configuring constrained delegation on the account of the back-end service, which may reside in another domain.
RECAP: The first option prevents the configuration of Kerberos delegation of any sort. The second choice allows you to set up an account for unconstrained delegation, granting broad access.
Conversely, the final option permits configuring an account specifically for constrained delegation, ensuring controlled and limited access. Managing resource-based constrained delegation is done through Windows PowerShell.
How can we identify Existing Kerberos Delegation?
In order to determine already configured delegation in your environment. The provided script helps identify accounts configured for unconstrained, constrained, and resource-based constrained delegation. It highlights pertinent information and potential warnings related to the listed configurations..
You should check that unconstrained delegation isn’t being used in your domain. Microsoft has a PowerShell script that you can use to find accounts that are set up for unconstrained delegation.
The script identifies user accounts, computer accounts, and managed service accounts configured for all types of delegation. We have the script embedded in this guide “how to Configure Kerberos Delegation in Windows Server“.
Attackers can discover computers on a domain with an unconstrained delegation property set using the Active Directory PowerShell module cmdlet, Get-ADComputer
Get-ADComputer -Filter {TrustedForDelegation -eq $true -and primarygroupid -eq 515} -Properties trustedfordelegation,serviceprincipalname,description
Detecting Active Directory exposures at an early stage can massively reduce the impact of an attack.
Block Kerberos delegation
Account(s) can be configured in Active Directory Users and Computers (ADUC) to block all kinds of delegation using the ‘Account is sensitive and cannot be delegated’ flag. You could set this flag for sensitive accounts, like domain administrators.
Adding sensitive accounts to the Protected Users group also prevents them from utilizing Kerberos delegation. Members of this group additionally face blocked NTLM authentication and cached logons.
Microsoft recommends activating Kerberos auditing in advanced audit policies across all domain controllers. Additionally, it’s advisable to monitor tickets issued to delegated accounts for unapproved services. Finally, set outbound firewall rules on servers using the unconstrained delegated account.
I hope you found this blog post on ‘Kerberos Delegation: A Comprehensive Guide” helpful. Please let me know in the comment session if you have any questions.
