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. Simply put, it is used to verify the identity of a user or host. Kerberos is designed to provide strong authentication for client/server applications by using secret-key cryptography. Yes, Kerberos has been around now for a long period of time, to be precise since Windows Server 2000. 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.
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) then builds on this mechanism to define specific resources that can be accessed in the context of the user.
This topic is mostly misunderstood and some even confuse 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). As against giving the service account running the web server access to the database directly, you can allow that service account to be delegated 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 allows the user to get access to the content in the database that they’ve been provisioned to. 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 instance, you have an IIS website, and the application pool account is configured 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: Constrained entities can be abused if one of their delegation entries is sensitive. One common way it can be abused is if attackers are able to compromise the plaintext password or NTLM hash of a user account configured for constrained delegation. Using a tool like Kekeo, they are able to request a TGT for the account they have the password for, execute the TGS request for any user (as long as the user is not marked ‘Sensitive’), and then inject the ticket and access the service they requested as that user. 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): Resource-based constrained entities can be abused if the entity itself is sensitive. You can leverage Rubeus to abuse RBCD
How to create a Kerberos delegation
Unconstrained Delegation
This form of delegation was introduced by Microsoft in Windows Server 2000. It is also referred to as a 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 unconstrained delegation configured, the ticket-granting ticket (TGT) for that account gets stored in memory so that the host with unconstrained delegation configured can impersonate that user later, if needed.
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. Specifically, it is included in the part of the ticket encrypted with the service owner key. Thus, upon receiving the TGS, it can access the client TGT.
This type of delegation is not considered secure because an administrator cannot control the services that the server can access using the client identity.Attackers can compromise credentials when unconstrained delegation is configured. Imagine a situation where a domain administrator uses an IIS website that has its application pool account set for unconstrained delegation. If Windows Authentication is enabled on the site, it will be able to get a service ticket from a domain controller and authenticate to any service it likes as a domain admin. While that service should probably be a database, if the website or database is compromised.
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 whitelisted third-party services
Constrained Delegation
Kerberos constrained delegation was introduced in Windows Server 2003 to provide a safer form of delegation that could be used by services. It enables you to configure which services an account can be delegated to. I.e, constrained delegation allows system administrators to limit the services to which an impersonated account can connect to. This in turn limits the potential exposure if a compromise were to occur. When it is configured, constrained delegation restricts the services to which the specified server can act on the behalf of a user.
By supporting constrained delegation across domains in Windows Server 2012, front-end services can be configured to use constrained delegation to authenticate to servers in other domains. This provides support for across domains service solutions by using an existing Kerberos infrastructure. Kerberos constrained delegation can be managed by domain administrators or service administrators.
Note: With traditional Kerberos constrained delegation (KCD), this was not possible and it was restricted to a single domain.
When constrained delegation is set on an account, two things happen under 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. 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. This form of delegation was introduced in Windows Server 2012 and later and it enables administrators to configure constrained delegation for their service. 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 receives a request from a frontend server to grant access on behalf of another user, the AD Key Distribution Center (KDC) checks the security descriptor in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the security principal running the backend service, and if it matches the descriptor under which the frontend service runs, access is granted.
Resource-based constrained delegation is managed using Windows PowerShell.How then can Kerberos create a whitelist 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. The Resource-based KCD can be configured using PowerShell as mentioned above. 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. The service ticket can be presented by the client user or obtained through S4U2Self extension.
- 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 allow constrained delegation to be configured on the back-end service’s account, which can be in another domain.
RECAP: The first option prevents the configuration of Kerberos delegation of any sort. The second option enables you to configure an account for unconstrained delegation, while the last option enables you to configure an account for constrained delegation. Resource-based constrained delegation is managed using Windows PowerShell.
How can we identify Existing Kerberos Delegation?
In order to determine already configured delegation in your environment. The script below will identify accounts with unconstrained, constrained and resource-based constrained delegation configured, highlighting information and potential warnings about the configurations it lists. 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 finds user accounts, computer accounts, and managed service accounts that are 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. Sensitive accounts that are added to the Protected Users group are also blocked from using Kerberos delegation. But NTLM authentication and cached logons are also blocked for members of this group.
Microsoft suggests enabling Kerberos auditing in advanced audit policy on all domain controllers and monitoring tickets from delegated accounts to unsanctioned services. Finally, set outbound firewall rules on servers using the unconstrained delegated account.
I hope you found this blog post helpful. Please let me know in the comment session if you have any questions.