Configure Kerberos constrained delegation (KCD) in Microsoft Entra Domain Services
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.
Microsoft Entra Domain Services managed domains are more securely locked down than traditional on-premises AD DS environments, so use a more secure resource-based KCD.
This article shows you how to configure resource-based Kerberos constrained delegation in a Domain Services managed domain.
Prerequisites
To complete this article, you need the following resources:
- An active Azure subscription.
- If you don't have an Azure subscription, create an account.
- A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.
- A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.
- A Windows Server management VM that is joined to the Domain Services managed domain.
- If needed, complete the tutorial to create a Windows Server VM and join it to a managed domain then install the AD DS management tools.
- A user account that's a member of the Microsoft Entra DC administrators group in your Microsoft Entra tenant.
Kerberos constrained delegation overview
Kerberos delegation lets one account impersonate another account to access resources. For example, a web application that accesses a back-end web component can impersonate itself as a different user account when it makes the back-end connection. Kerberos delegation is insecure as it doesn't limit what resources the impersonating account can access.
Kerberos constrained delegation (KCD) restricts the services or resources that a specified server or application can connect when impersonating another identity. Traditional KCD requires domain administrator privileges to configure a domain account for a service, and it restricts the account to run on a single domain.
Traditional KCD also has a few issues. For example, in earlier operating systems, the service administrator had no useful way to know which front-end services delegated to the resource services they owned. Any front-end service that could delegate to a resource service was a potential attack point. If a server that hosted a front-end service configured to delegate to resource services was compromised, the resource services could also be compromised.
In a managed domain, you don't have domain administrator privileges. As a result, traditional account-based KCD can't be configured in a managed domain. Resource-based KCD can instead be used, which is also more secure.
Resource-based KCD
Windows Server 2012 and later gives service administrators the ability to configure constrained delegation for their service. This model is known as resource-based KCD. With this approach, the back-end service administrator can allow or deny specific front-end services from using KCD.
Resource-based KCD is configured using PowerShell. You use the Set-ADComputer or Set-ADUser cmdlets, depending on whether the impersonating account is a computer account or a user account / service account.
Configure resource-based KCD for a computer account
In this scenario, let's assume you have a web app that runs on the computer named contoso-webapp.aaddscontoso.com.
The web app needs to access a web API that runs on the computer named contoso-api.aaddscontoso.com in the context of domain users.
Complete the following steps to configure this scenario:
Create a custom OU. You can delegate permissions to manage this custom OU to users within the managed domain.
Domain-join the virtual machines, both the one that runs the web app, and the one that runs the web API, to the managed domain. Create these computer accounts in the custom OU from the previous step.
Note
The computer accounts for the web app and the web API must be in a custom OU where you have permissions to configure resource-based KCD. You can't configure resource-based KCD for a computer account in the built-in Microsoft Entra DC Computers container.
Finally, configure resource-based KCD using the Set-ADComputer PowerShell cmdlet.
From your domain-joined management VM and logged in as user account that's a member of the Microsoft Entra DC administrators group, run the following cmdlets. Provide your own computer names as needed:
$ImpersonatingAccount = Get-ADComputer -Identity contoso-webapp.aaddscontoso.com Set-ADComputer contoso-api.aaddscontoso.com -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount
Configure resource-based KCD for a user account
In this scenario, let's assume you have a web app that runs as a service account named appsvc. The web app needs to access a web API that runs as a service account named backendsvc in the context of domain users. Complete the following steps to configure this scenario:
Create a custom OU. You can delegate permissions to manage this custom OU to users within the managed domain.
Domain-join the virtual machines that run the backend web API/resource to the managed domain. Create its computer account within the custom OU.
Create the service account (for example, appsvc) used to run the web app within the custom OU.
Note
Again, the computer account for the web API VM, and the service account for the web app, must be in a custom OU where you have permissions to configure resource-based KCD. You can't configure resource-based KCD for accounts in the built-in Microsoft Entra DC Computers or Microsoft Entra DC Users containers. This also means that you can't use user accounts synchronized from Microsoft Entra ID to set up resource-based KCD. You must create and use service accounts specifically created in Domain Services.
Finally, configure resource-based KCD using the Set-ADUser PowerShell cmdlet.
From your domain-joined management VM and logged in as user account that's a member of the Microsoft Entra DC administrators group, run the following cmdlets. Provide your own service names as needed:
$ImpersonatingAccount = Get-ADUser -Identity appsvc Set-ADUser backendsvc -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount
Next steps
To learn more about how delegation works in Active Directory Domain Services, see Kerberos Constrained Delegation Overview.