How to Configure Kerberos Constrained Delegation on Windows Server 2012 R2

Kerberos delegation allows a service running under a specific account to impersonate a user and access other network resources on their behalf. Unconstrained delegation is dangerous because a compromised account can be used to impersonate any user to any service in the domain. Constrained Delegation (KCD) limits which services a delegating account can access on behalf of users, and Resource-Based Constrained Delegation (RBCD), introduced in Windows Server 2012, moves the delegation configuration to the target resource rather than the delegating account. This guide covers configuring both traditional KCD and RBCD on Windows Server 2012 R2.

Prerequisites

  • Active Directory domain with Windows Server 2012 R2 domain controllers
  • Domain Admin access
  • RSAT (Remote Server Administration Tools) with the Active Directory module installed
  • Clear understanding of the service account and target service SPNs involved in the delegation scenario

Step 1: Understand Delegation Types

Before configuring delegation, understand the three types:

  • Unconstrained Delegation — The delegating account can impersonate users to any service in the domain. Extremely dangerous. Identify and eliminate all unconstrained delegation.
  • Constrained Delegation (KCD) — The delegating account can only impersonate users to a specific list of services defined by an administrator on the delegating account.
  • Resource-Based Constrained Delegation (RBCD) — The target resource controls which accounts are permitted to delegate to it, via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

Step 2: Audit Existing Unconstrained Delegation

Identify all accounts with unconstrained delegation configured—these represent high-risk targets:

Import-Module ActiveDirectory

# Find all user accounts with unconstrained delegation (TrustedForDelegation = True)
Get-ADUser -Filter { TrustedForDelegation -eq $true } -Properties TrustedForDelegation |
    Select-Object Name, SamAccountName, TrustedForDelegation

# Find all computer accounts with unconstrained delegation (excluding DCs which legitimately have it)
Get-ADComputer -Filter { TrustedForDelegation -eq $true } -Properties TrustedForDelegation |
    Where-Object { $_.DistinguishedName -notlike "*Domain Controllers*" } |
    Select-Object Name, DistinguishedName

Any account found here that is not a domain controller should be evaluated. In most cases, unconstrained delegation should be replaced with constrained delegation.

Step 3: Configure Traditional Kerberos Constrained Delegation

Scenario: A web application running as service account svc-webapp needs to delegate user credentials to SQL Server’s MSSQLSvc service.

First, register the SPN for the web application service account if not already present:

# Set SPN for the web application service account
setspn -S HTTP/webapp.corp.example.com svc-webapp
setspn -S HTTP/webapp svc-webapp

# Verify SPN registration
setspn -L svc-webapp

Configure KCD on the service account to allow delegation to the SQL Server:

# Configure KCD via PowerShell (preferred over GUI)
Set-ADUser -Identity "svc-webapp" `
    -TrustedForDelegation $false `
    -Add @{
        "msDS-AllowedToDelegateTo" = @(
            "MSSQLSvc/SQLSERVER01.corp.example.com:1433",
            "MSSQLSvc/SQLSERVER01.corp.example.com"
        )
    }

# Enable "Use any authentication protocol" (Protocol Transition) if needed
# This allows the service to use S4U2Self to obtain a Kerberos ticket even if the user authenticated via a non-Kerberos method
Set-ADAccountControl -Identity "svc-webapp" -TrustedToAuthForDelegation $true

Verify the configuration:

Get-ADUser -Identity "svc-webapp" -Properties "msDS-AllowedToDelegateTo","TrustedToAuthForDelegation" |
    Select-Object Name, TrustedToAuthForDelegation, msDS-AllowedToDelegateTo

Step 4: Configure Resource-Based Constrained Delegation (RBCD)

RBCD is configured on the target computer object rather than the source account. This is preferable because it does not require Domain Admin rights—only the resource owner needs to configure it.

Scenario: Allow the web server computer account WEBSERVER01 to delegate to SQLSERVER01:

# Get the web server account object
$webServer = Get-ADComputer -Identity "WEBSERVER01"

# Configure RBCD on the SQL server - allow WEBSERVER01 to delegate to it
$rawSD = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-DOMAIN-SID-OF-WEBSERVER01)"

# Preferred method using Set-ADComputer:
Set-ADComputer -Identity "SQLSERVER01" `
    -PrincipalsAllowedToDelegateToAccount $webServer

# Verify
Get-ADComputer -Identity "SQLSERVER01" -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object Name, PrincipalsAllowedToDelegateToAccount

Step 5: Block Sensitive Accounts from Delegation

High-privilege accounts (Domain Admins, service accounts with broad access) should be marked as sensitive and cannot be delegated. This prevents their credentials from being used in delegation attacks:

# Mark sensitive accounts as "Account is sensitive and cannot be delegated"
$sensitiveAccounts = @("Administrator","DomainAdmin1","svc-sqlengine","svc-backup")

foreach ($account in $sensitiveAccounts) {
    Set-ADUser -Identity $account -AccountNotDelegated $true
    Write-Host "Marked as not delegatable: $account"
}

# Verify
Get-ADUser -Filter { AccountNotDelegated -eq $true } |
    Select-Object Name, SamAccountName

Also add these accounts to the Protected Users group, which automatically prevents delegation:

Add-ADGroupMember -Identity "Protected Users" -Members "Administrator","DomainAdmin1"

Step 6: Audit Constrained Delegation Configuration

Periodically audit which accounts have delegation configured to detect unauthorized changes:

# All user accounts with ANY delegation configured
Get-ADUser -Filter { (TrustedForDelegation -eq $true) -or (TrustedToAuthForDelegation -eq $true) } `
    -Properties TrustedForDelegation, TrustedToAuthForDelegation, msDS-AllowedToDelegateTo |
    Select-Object Name, TrustedForDelegation, TrustedToAuthForDelegation, "msDS-AllowedToDelegateTo" |
    Format-Table -AutoSize

# Computer accounts with constrained delegation
Get-ADComputer -Filter { msDS-AllowedToDelegateTo -like "*" } `
    -Properties "msDS-AllowedToDelegateTo" |
    Select-Object Name, "msDS-AllowedToDelegateTo"

Step 7: Monitoring and Event Logging

Enable auditing of delegation-related Kerberos events on domain controllers:

# Enable auditing on domain controllers
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable

# Monitor for S4U2Proxy (constrained delegation) events
# Event ID 4769 with service ticket type 0x10 indicates S4U2Proxy
Get-WinEvent -LogName Security -FilterXPath `
    "*[System[EventID=4769]]" -MaxEvents 100 |
    Where-Object { $_.Message -match "0x10" } |
    Select-Object TimeCreated, Message

Summary

Kerberos Constrained Delegation on Windows Server 2012 R2 provides a secure framework for service-to-service authentication that avoids the dangers of unconstrained delegation. By auditing and eliminating unconstrained delegation, configuring KCD or RBCD only for specific documented service pairs, marking sensitive accounts as not delegatable, and monitoring Kerberos delegation events, you significantly reduce the risk of Kerberos-based lateral movement in your Active Directory environment. RBCD is the preferred model for new configurations because it decentralizes control to resource owners and does not require Domain Admin intervention for every change.