- 0 minutes to read

Service Principal Names (SPN)

Master Service Principal Name (SPN) registration for secure Kerberos authentication in distributed Nodinite environments. This comprehensive guide covers SPNs for standalone SQL Server instances, failover clusters, Always On Availability Groups (AOAG), and troubleshooting common authentication issues.

What you'll learn on this page:

✅ When SPN registration is required for Nodinite environments
✅ Register SPNs for default instances, named instances, clusters, and AOAG listeners
✅ Validate SPN configuration with Microsoft's Kerberos Configuration Manager
✅ Troubleshoot common Kerberos authentication and delegation issues
✅ Understand SPN requirements for linked servers and distributed transactions

Overview

Service Principal Names (SPNs) are unique identifiers for services running on servers in Active Directory. When Nodinite uses Kerberos authentication in distributed environments—particularly with Linked Servers, multiple SQL Server instances, or BizTalk Server integration—proper SPN registration is essential for secure authentication.

What is an SPN?

An SPN maps a service instance to a domain account, enabling Kerberos authentication. SQL Server automatically attempts to register SPNs when started, but this requires the service account to have appropriate Active Directory permissions.

When is SPN registration required?

When is SPN registration NOT required?

  • ❌ Single-box server with BizTalk, SQL Server, and Nodinite all on the same machine
  • ❌ Using SQL Server authentication instead of Windows authentication

Note

Linked servers are always required: Even when all databases are on the same SQL Server instance, Nodinite requires Linked Servers to be configured. SPNs are only needed when using Windows authentication in distributed environments.

Tip

Use the Microsoft Kerberos Configuration Manager: Download the Microsoft Kerberos Configuration Manager for SQL Server to automatically detect and resolve SPN issues. This tool generates PowerShell scripts for Domain Admins to fix missing or duplicate SPNs.

Important

Domain Admin rights required: Registering SPNs requires Domain Admin privileges. Work with your Active Directory administrators to register SPNs using the setspn command.

SPN Registration Commands

Default Instance

Register an SPN for a default SQL Server instance running under a domain account:

setspn -S MSSQLSvc/myhost.redmond.microsoft.com accountname

Example:

setspn -S MSSQLSvc/sql-prod-01.contoso.com CONTOSO\svc-sql-prod

Named Instance

Register an SPN for a named SQL Server instance running under a domain account:

setspn -S MSSQLSvc/myhost.redmond.microsoft.com:instancename accountname

Example:

setspn -S MSSQLSvc/sql-prod-01.contoso.com:BIZTALK CONTOSO\svc-sql-biztalk

Note

Repeat for each named instance: If you have multiple named instances on the same server with different service accounts, register SPNs for each combination.

List Registered SPNs

Verify which SPNs are registered for a service account:

setspn -l accountname

Example:

setspn -l CONTOSO\svc-sql-prod

Expected output:

Registered ServicePrincipalNames for CN=svc-sql-prod,OU=Service Accounts,DC=contoso,DC=com:
        MSSQLSvc/sql-prod-01.contoso.com:1433
        MSSQLSvc/sql-prod-01.contoso.com

Delete an SPN

Remove an incorrectly registered or duplicate SPN:

setspn -D MSSQLSvc/myhost.redmond.microsoft.com accountname

Warning

Avoid duplicate SPNs: Duplicate SPNs cause Kerberos authentication failures. Use the Kerberos Configuration Manager tool to detect and resolve duplicates.

SPN Requirements by Scenario

Single Nodinite Instance

Scenario: Nodinite Configuration Database and Log Databases on one SQL Server instance.

SPNs required: 1

  1. SQL Server name for default instance with Nodinite databases

Nodinite + BizTalk Failover Cluster

Scenario: Nodinite on a standalone SQL Server, BizTalk on a two-node failover cluster with default and named instances.

SPNs required: 7

  1. SQL Server name for default instance with Nodinite Configuration Database
  2. SQL Server first node name for default instance with BizTalk databases
  3. SQL Server second node name for default instance with BizTalk databases
  4. SQL Server cluster name for default instance with BizTalk databases
  5. SQL Server first node name for named instance with BizTalk messagebox database
  6. SQL Server second node name for named instance with BizTalk messagebox database
  7. SQL Server cluster name for named instance with BizTalk messagebox database

Tip

Failover clusters require node + cluster SPNs: Each physical node AND the cluster virtual name must have SPNs registered for seamless failover.

Always On Availability Groups (AOAG)

Scenario: SQL Server with Always On Availability Groups using a listener on a custom port.

SPNs required: Cluster name, listener name, and each node name

Even if your SQL instance uses a specific port (e.g., 50123), the AOAG listener typically uses port 1433 (default). You must register SPNs for both the custom instance port and the listener port.

Example for two-node AOAG:

setspn -S MSSQLSvc/AOAGListener:1433 CONTOSO\svc-sql-aoag
setspn -S MSSQLSvc/AOAGListener CONTOSO\svc-sql-aoag
setspn -S MSSQLSvc/NodeA:50123 CONTOSO\svc-sql-aoag
setspn -S MSSQLSvc/NodeB:50123 CONTOSO\svc-sql-aoag
setspn -S MSSQLSvc/NodeA:InstanceName CONTOSO\svc-sql-aoag
setspn -S MSSQLSvc/NodeB:InstanceName CONTOSO\svc-sql-aoag

Verify with setspn -l:

setspn -l CONTOSO\svc-sql-aoag

Expected output:

MSSQLSvc/AOAGListener:1433
MSSQLSvc/AOAGListener
MSSQLSvc/NodeA:50123
MSSQLSvc/NodeB:50123
MSSQLSvc/NodeA:InstanceName
MSSQLSvc/NodeB:InstanceName

Important

SQL accounts are not replicated between nodes: Each node in the AOAG must have SQL login accounts configured locally. See Always On Availability Groups for details.

Validation and Troubleshooting

Microsoft Kerberos Configuration Manager

The Microsoft Kerberos Configuration Manager for SQL Server is the recommended tool for validating and fixing SPN issues.

Download: https://www.microsoft.com/en-us/download/details.aspx?id=39046

Features:

  • ✅ Automatically detects missing or duplicate SPNs
  • ✅ Validates delegation settings
  • ✅ Generates PowerShell scripts for Domain Admins to fix issues
  • ✅ No SQL Server connection details required—connects locally

Installation:

C:\Program Files\Microsoft\Kerberos Configuration Manager for SQL Server\

SPN Tab

All Nodinite SQL Servers making linked server hops should be listed in the SPN tab with status OK.

SPN tab

Delegation Tab

The Delegation tab should report no issues.

Delegation

Common SPN Issues

Issue Cause Solution
"Cannot generate SSPI context" error Missing or duplicate SPNs Use Kerberos Configuration Manager to detect and fix SPNs
SQL Server falls back to NTLM SPN not registered Register SPNs for all node, cluster, and listener names
"Anonymous login" errors Delegation not configured See Trusted for delegation guide
Kerberos works on node A, fails on node B SPNs registered for cluster but not individual nodes Register SPNs for each physical node

Note

Check SQL Server audit log: If SQL Server runs with an account that cannot register SPNs automatically, errors appear in the SQL Server audit log. Review Microsoft's SPN registration guide for details.

SPN and Service Account Requirements

Service Account Best Practices

Requirement Description
Domain account SQL Server instance must run as an Active Directory domain account (not Local System or Network Service)
SPN registration rights Service account should have rights to register SPNs in Active Directory, OR Domain Admins must register SPNs manually
Not sensitive Account must NOT have 'Account is sensitive and cannot be delegated' checked in Active Directory
Trusted for delegation Configure Trusted for delegation for linked server scenarios

Account Configuration Checklist

When configuring SQL Server service accounts:

  1. ✅ Create dedicated domain service account (e.g., CONTOSO\svc-sql-prod)
  2. ✅ Grant 'Log on as a service' right on SQL Server machine
  3. ✅ Configure SQL Server instance to run as domain account
  4. ✅ Register SPNs for instance (node, cluster, listener names)
  5. ✅ Configure Trusted for delegation if using linked servers
  6. ✅ Validate with Kerberos Configuration Manager tool

SPNs and Linked Servers

Nodinite uses Linked Servers to access Log Databases from the Configuration Database. When databases are on different SQL Server instances, proper SPN registration enables Kerberos authentication across the linked server connection.

Kerberos Ticket Flow:

sequenceDiagram opt Kerberos TGT Logging Service ->> Domain Controller: Service account credentials Domain Controller ->> Logging Service: Kerberos TGT end opt Service ticket Logging Service ->> Domain Controller: Send TGT to request a service ticket Domain Controller ->> Logging Service: service ticket end Logging Service ->> SQL (Configuration Database): Client TGT and service ticket opt SQL service ticket SQL (Configuration Database) ->> Domain Controller: Clients TGT to request a service ticket Domain Controller ->> SQL (Configuration Database): service ticket end SQL (Configuration Database) ->> Remote SQL (Log Database): Client TGT and SQL service ticket Remote SQL (Log Database) ->> SQL (Configuration Database): Response SQL (Configuration Database) ->> Logging Service: Response

Sequence: Logging Service authenticates and traverses SQL Server instances using Kerberos tickets.

Requirements:

External References