Deep Dive into Windows SPNs: Technical Guide for Kerberos Authentication in IIS and AD Environments


2 views

When troubleshooting authentication issues in Windows environments, you'll often encounter SPNs lurking beneath the surface. These Service Principal Names are crucial identifiers that allow Kerberos authentication to function properly between services and clients in an Active Directory domain.

An SPN follows a strict format: serviceclass/host:port[/servicepath]

Common service classes include:

HTTP - Web services
MSSQLSvc - SQL Server
HOST - General host services
TERMSRV - Terminal Services
WSMAN - Windows Remote Management

When configuring an IIS application pool running under a domain service account, you might need to set an SPN like this:

setspn -S HTTP/webserver.domain.com DOMAIN\ServiceAccount
setspn -S HTTP/webserver DOMAIN\ServiceAccount

The duplicate entries (with and without FQDN) ensure compatibility with different client resolution methods.

Here's what happens during authentication:

  1. Client requests service ticket from KDC
  2. KDC checks SPN registration in AD
  3. If registered to computer account (PCName$), uses machine credentials
  4. If registered to service account, uses that account's credentials
  5. Ticket contains service principal information for validation

Essential commands for SPN management:

# List all SPNs for an account
setspn -L DOMAIN\ServiceAccount

# Check SPN conflicts
setspn -X

# Test Kerberos ticket generation
klist get HTTP/webserver.domain.com

1. Duplicate SPNs: Only one account can hold a specific SPN

# Solution: Find and clean duplicates
setspn -F -Q HTTP/*

2. Incorrect Service Account: Application pool identity must match SPN registration

3. Missing SPN Types: Some services require multiple SPN formats

When services need to impersonate users across systems:

# PowerShell to configure constrained delegation
Set-ADUser ServiceAccount -Add @{
    'msDS-AllowedToDelegateTo' = @(
        'HTTP/backend.domain.com',
        'MSSQLSvc/dbserver.domain.com:1433'
    )
}

Regular SPN housekeeping helps prevent authentication issues:

# Audit script example
$serviceAccounts = Get-ADServiceAccount -Filter *
foreach ($account in $serviceAccounts) {
    Write-Host "SPNs for $($account.SamAccountName):"
    setspn -L $account.SamAccountName
}

Service Principal Names (SPNs) function as unique identifiers within Active Directory's Kerberos authentication framework. When a client requests access to a network service, the Key Distribution Center (KDC) uses SPNs to locate the appropriate service account and generate service tickets. The fundamental SPN syntax follows this pattern:

ServiceClass/Host:Port/ServiceName

Let's examine the critical elements that interact with SPNs:

  • Service Classes: Standardized identifiers (HTTP, MSSQLSvc, HOST, etc.)
  • Service Accounts: Computer accounts (COMPUTERNAME$) or dedicated service accounts
  • Binding Mechanisms: How SPNs associate with accounts in Active Directory
  • Delegation Requirements: Constrained vs unconstrained delegation scenarios

Here's how to register SPNs for common scenarios using PowerShell:

# HTTP service running on web01.contoso.com using a service account
setspn -S HTTP/web01.contoso.com CONTOSO\svc-webfarm

# SQL Server instance on SQLSRV01 listening on port 1433
setspn -S MSSQLSvc/SQLSRV01.contoso.com:1433 CONTOSO\svc-sql

# Multiple host headers for a web application
setspn -S HTTP/webapp.contoso.com CONTOSO\svc-webfarm
setspn -S HTTP/webapp-int.contoso.com CONTOSO\svc-webfarm

Common problems and diagnostic commands:

# Check registered SPNs for an account
setspn -L CONTOSO\svc-webfarm

# Verify Kerberos ticket issuance (requires client-side execution)
klist get HTTP/web01.contoso.com

# Check SPN uniqueness (avoid duplicate SPNs)
setspn -X

For complex environments:

  • Cross-domain SPNs: When services span multiple AD domains
  • Cluster-aware services: SPNs for failover clusters (SQL AlwaysOn, etc.)
  • Virtual host scenarios: SPNs for containerized or virtualized services

Recommendations for production environments:

  • Always use dedicated service accounts (avoid computer accounts)
  • Document SPN assignments in your CMDB
  • Implement monitoring for SPN changes
  • Regularly audit SPN configurations