How to Configure Kerberos Authentication on Windows Server 2019

March 20, 2026
Tutorials
Comment off

Introduction to Kerberos Authentication

Kerberos is the default authentication protocol for Windows domain environments. Introduced with Windows 2000 and continually improved in Windows Server 2019, Kerberos provides mutual authentication—both the client and the server verify each other’s identity—and uses tickets rather than transmitting passwords over the network. Understanding Kerberos is essential for troubleshooting authentication failures, securing service accounts, and implementing advanced features like constrained delegation and resource-based constrained delegation. This tutorial covers Kerberos architecture, ticket granting, service principal names (SPNs), delegation types, and hardening recommendations for Windows Server 2019.

Kerberos Protocol Overview

Kerberos authentication involves three parties: the client, the Key Distribution Center (KDC, which runs on domain controllers), and the resource server. The process has two stages: first the client obtains a Ticket Granting Ticket (TGT) from the KDC’s Authentication Service (AS) by presenting its credentials. The KDC issues a TGT encrypted with the krbtgt account’s key. Second, when the client needs to access a resource, it presents the TGT to the KDC’s Ticket Granting Service (TGS) and receives a service ticket for the specific resource. The client presents this service ticket to the resource server to authenticate.

Service Principal Names

A Service Principal Name (SPN) uniquely identifies a service instance and is the mechanism by which Kerberos maps service tickets to specific services. SPNs follow the format ServiceClass/FQDN:Port or ServiceClass/NetBIOS. For example, a web server running on server01.yourdomain.com listening on port 8080 would have the SPN http/server01.yourdomain.com:8080. SPNs are registered in Active Directory against the account running the service.

# List all SPNs registered in the domain
Get-ADObject -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName |
    Select-Object Name, ServicePrincipalName

# List SPNs for a specific service account
Get-ADUser -Identity "svc-webapp" -Properties ServicePrincipalName |
    Select-Object Name, ServicePrincipalName

Registering Service Principal Names

Register SPNs using setspn.exe or PowerShell. SPNs must be unique across the entire forest—duplicate SPNs cause Kerberos authentication failures. Use setspn -Q to search for existing SPNs before registering.

# Search for existing SPN to check for duplicates
setspn -Q HTTP/webapp.yourdomain.com

# Register an SPN on a service account
setspn -S HTTP/webapp.yourdomain.com yourdomainsvc-webapp
setspn -S HTTP/webapp yourdomainsvc-webapp

# List all SPNs on an account
setspn -L yourdomainsvc-webapp

# PowerShell equivalent
Set-ADUser -Identity "svc-webapp" `
    -ServicePrincipalNames @{Add="HTTP/webapp.yourdomain.com","HTTP/webapp"}

Kerberos Delegation

Kerberos delegation allows a service to authenticate to another service on behalf of a user. For example, a web application server can use the user’s Kerberos identity to authenticate to a database server behind it. There are three delegation types: Unconstrained Delegation (dangerous—allows the service to impersonate the user to any service), Constrained Delegation (safer—limits which services the account can delegate to), and Resource-Based Constrained Delegation (RBCD, most flexible—controlled by the back-end resource).

Configuring Constrained Delegation

Configure Constrained Delegation on the front-end service account. Specify exactly which back-end services the account is allowed to delegate to. This uses the msDS-AllowedToDelegateTo attribute.

# Configure constrained delegation: web app can delegate to SQL server
Set-ADUser -Identity "svc-webapp" `
    -TrustedForDelegation $false `
    -TrustedToAuthForDelegation $true

Set-ADUser -Identity "svc-webapp" `
    -Add @{'msDS-AllowedToDelegateTo'=@("MSSQLSvc/sqlserver01.yourdomain.com:1433",
                                         "MSSQLSvc/sqlserver01.yourdomain.com")}

# Verify delegation settings
Get-ADUser -Identity "svc-webapp" `
    -Properties TrustedForDelegation, TrustedToAuthForDelegation, msDS-AllowedToDelegateTo

Configuring Resource-Based Constrained Delegation

RBCD is configured on the back-end resource (the service being delegated to) rather than on the front-end service. This allows the owner of the back-end resource to control which services can delegate to it without requiring Domain Admin privileges.

# Configure RBCD: allow svc-webapp to delegate to SQL server
$webAppAccount = Get-ADUser -Identity "svc-webapp"
Set-ADComputer -Identity "SQLSERVER01" `
    -PrincipalsAllowedToDelegateToAccount $webAppAccount

# Verify
Get-ADComputer -Identity "SQLSERVER01" `
    -Properties msDS-AllowedToActOnBehalfOfOtherIdentity

Hardening the krbtgt Account

The krbtgt account’s password is used to sign all Kerberos tickets. If compromised (as in a Golden Ticket attack), an attacker can forge valid Kerberos tickets for any user including Domain Admins. Reset the krbtgt password twice (with a delay between resets to allow replication) to invalidate all existing tickets and prevent Golden Ticket forgeries. This is a key remediation step after any Domain Admin compromise.

# Reset krbtgt password (do this TWICE with 10+ hours between resets)
# First reset
$newPassword = ConvertTo-SecureString -String (New-Guid).Guid -AsPlainText -Force
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword -Reset

# Wait for AD replication, then reset AGAIN
# Second reset (necessary to invalidate all old tickets)
$newPassword2 = ConvertTo-SecureString -String (New-Guid).Guid -AsPlainText -Force
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword2 -Reset

Configuring Kerberos AES Encryption

Windows Server 2019 supports AES-128 and AES-256 Kerberos encryption types, which are significantly stronger than the older RC4 (NTLM hash based) encryption. Configure service accounts and computer accounts to use AES encryption. Use the msDS-SupportedEncryptionTypes attribute to specify supported types.

# Enable AES 128 and 256 for a service account (value 24 = AES128 + AES256)
Set-ADUser -Identity "svc-webapp" `
    -KerberosEncryptionType AES128,AES256

# Disable RC4/DES encryption domain-wide via Group Policy
# Computer Config > Policies > Windows Settings > Security Settings > 
# Local Policies > Security Options > 
# "Network security: Configure encryption types allowed for Kerberos"
# Enable only AES128_HMAC_SHA1 and AES256_HMAC_SHA1

Diagnosing Kerberos Issues

Kerberos failures appear as Event ID 4771 (pre-authentication failure) and 4769 (service ticket request failure) in the Security event log. Use klist to view and purge Kerberos tickets on a client computer.

# View current Kerberos tickets
klist

# View tickets for a specific logon session
klist tickets

# Purge all Kerberos tickets (forces re-authentication)
klist purge

# Check for duplicate SPNs (common cause of Kerberos failures)
setspn -X

Conclusion

Kerberos is the backbone of Windows domain authentication and understanding it deeply enables effective troubleshooting and hardening. Windows Server 2019 supports modern AES encryption for Kerberos, resource-based constrained delegation for flexible service-to-service authentication, and Protected Users security group to enforce strong Kerberos protections on privileged accounts. Regularly audit SPNs for duplicates and unauthorized registrations, enforce AES-only encryption to prevent RC4 downgrade attacks, and protect the krbtgt account as the most sensitive credential in your domain.