Service Principal Names (SPN): Solving the "Cannot Generate SSPI Context" Mystery

You've deployed Nodinite across several servers: the Web Client on IIS, the Logging and Monitoring Services on an application server, and the databases on SQL Server. You select Test Connection and get:

"Cannot generate SSPI context"

Or users open the Web Client and get a login prompt instead of signing in automatically. Or a linked server query fails with:

"Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'"

All three symptoms usually share one root cause: a missing, duplicate, or misplaced Service Principal Name (SPN), which stops Kerberos authentication from working across server boundaries.

SPNs show up in two different places in a Nodinite installation, and the two problems are related but not the same:

• SQL Server SPNs (MSSQLSvc/...) - Nodinite services and SQL Server instances authenticating to each other, including linked server hops between the Configuration Database and Log Databases.
• IIS HTTP SPNs (HTTP/...) - users' browsers and API clients authenticating to IIS-hosted Nodinite services: the Web Client, Web API, Log API, Logging Service, Monitoring Service, MCP Endpoint, and Pickup Service.

This page is the hub. It explains the shared concepts and commands once, then sends you to the guide for your problem:

• SQL Server SPNs (MSSQLSvc) - default and named instances, failover clusters, Always On, linked servers, and delegation
• HTTP SPNs for IIS - Web Client hostnames, web farms, useAppPoolCredentials, and HTTP SPN ownership conflicts

Important

NTLM-disabled environments: many organizations disable NTLM for security compliance, which forces Kerberos-only authentication. Without NTLM there's no fallback: if a required SPN is missing, the Nodinite Web Client, Monitoring Service, and Logging Service fail to authenticate. In these environments SPNs are mandatory, for both SQL Server and IIS.

What Goes Wrong Without Proper SPNs

• Deployment delays - installations that work on a single developer machine fail in multi-server production environments.
• Silent fallback to NTLM - systems fall back to the weaker NTLM protocol without warning, which creates compliance gaps and, for IIS, slow page loads.
• Intermittent failures - Kerberos works on one cluster node or web farm node but not another.
• Linked server breakdowns - the Configuration Database connects, but queries to remote Log Databases fail as anonymous logon.
• Post-failover surprises - a cluster or Availability Group fails over, and applications can't authenticate to the new active node.
• Unexpected login prompts - the Web Client asks for credentials instead of signing users in transparently.

Understanding SPNs and Kerberos

An SPN is a unique identifier in Active Directory that maps a service instance, such as MSSQLSvc/sql-prod-01.contoso.com:1433 or HTTP/nodinite.contoso.com, to the account the service runs as. When a client wants to connect, it asks the Domain Controller for a Kerberos ticket for that SPN. The Domain Controller encrypts the ticket with the key of the account that owns the SPN, so only that service can read it.

That gives Kerberos two hard requirements:

• Exactly one owner - each SPN must exist on exactly one account in the forest. A missing SPN makes Kerberos fail or fall back to NTLM; a duplicate SPN makes it fail.
• The right owner - the SPN must be on the account the service actually runs as. If the ticket is encrypted for another account, the service can't decrypt it.

Diagram: the two SPN paths in a Nodinite installation. Blue nodes are the IIS path (HTTP SPN, see the IIS guide); orange nodes are the SQL Server path (MSSQLSvc SPN and delegation, see the SQL Server guide); purple is Active Directory, which both paths depend on.

Key Components Explained

SQL Server SPNs vs IIS HTTP SPNs

Both use the same Active Directory mechanism and the same setspn tool, but they break in different ways and get fixed in different places.

Which Guide Do You Need?

When Is SPN Registration Required?

You need SPNs when Windows authentication crosses a machine boundary, or when a service runs as a domain account:

• Required - NTLM is disabled (Kerberos-only policy)
• Required - Nodinite and SQL Server are on different machines
• Required - SQL Server runs as a domain account or gMSA
• Required - an IIS application pool runs as a domain account, for example the v7 Web Client, Web API, or Log API published on a DNS alias
• Required - Linked Servers connect to remote SQL Server instances, or another double-hop scenario needs Trusted for delegation
• Required - SQL Server failover clusters or Always On Availability Groups
• Required - load-balanced IIS web farms serving the Web Client

You don't need to register SPNs yourself when:

• Not required - BizTalk, SQL Server, and Nodinite all run on one machine with built-in accounts
• Not required - you use SQL Server authentication instead of Windows authentication
• Not required - the IIS application pool uses ApplicationPoolIdentity or Network Service and users browse to the machine name; the computer account's built-in HOST/ SPN covers it

Note

Even when all databases are on the same SQL Server instance, Nodinite requires Linked Servers to be configured. SPNs only come into play when Windows authentication crosses machine boundaries.

End-to-End Example: Multi-Tier Deployment with NTLM Disabled

The Web Client runs on an IIS server, the Monitoring and Logging Services on an application server, and SQL Server on a database server. NTLM is disabled. This deployment needs SPNs from both guides:

Important

In NTLM-disabled environments, every service that runs as a domain account needs its SPNs. Missing even one causes a hard authentication failure for that hop.

Service Account Requirements

These rules apply to every account that owns an SPN, whether it runs SQL Server, an IIS application pool, or a Windows service.

Important

Registering SPNs for another account requires Domain Admin rights, or delegated rights to write servicePrincipalName. Work with your Active Directory administrators.

Important

Upgrades and migrations: if you upgrade or migrate an older Nodinite installation and a required SPN is missing, register it as part of the same change. Changes to service identities, server names, cluster names, listener names, or Web Client hostnames all change which SPNs you need.

Shared setspn Commands

Both guides use the same commands. They're listed once here; the guides show only the SPN values for their scenario.

:: Register an SPN (SQL Server example)
setspn -S MSSQLSvc/sql-prod-01.contoso.com CONTOSO\svc-sql-prod

:: Verify
setspn -L CONTOSO\svc-sql-prod

Expected result:

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

Tip

Always use setspn -S rather than the older setspn -A. -S checks the forest for duplicates before adding the SPN.

Error 0x21c7/8647: SPN Value Is Not Unique Forest-Wide

If setspn -S returns:

Failed to assign SPN ... error 0x21c7/8647
The operation failed because SPN value provided for addition/modification is not unique forest-wide.

Active Directory already has an owner for that SPN. To resolve it:

1. Find the owner with setspn -Q <serviceclass>/<host> for both the short name and the FQDN, and run setspn -X to list all duplicates.
2. If the owner is already the intended account, do nothing; the SPN is in place.
3. If the owner is a stale or wrong account, for example after a server or account migration, remove the SPN from that account with setspn -D, then add it to the correct account with setspn -S.

Warning

For HTTP/ SPNs on a machine-name URL, the conflict can come from the computer account's HOST/ SPN even when setspn -Q shows no HTTP/ row. Never remove HOST/ SPNs from a computer account; see HTTP SPN Ownership Conflicts in the IIS guide.

Other Services: BizTalk Host Instances

When BizTalk Host Instances run as custom domain accounts and are accessed with Kerberos, register their SPNs with the same setspn -S pattern, substituting the host instance account and host name:

setspn -S BTSSvc/biztalk-host01.contoso.com CONTOSO\svc-biztalk-host

Note

When you upgrade or migrate a BizTalk environment, validate SPN ownership in the same change window. A missing BizTalk SPN is often discovered only after a host instance moves or a server is renamed.

External References

• Register a Service Principal Name for Kerberos Connections
• Understanding Kerberos Double Hop
• Microsoft Kerberos Configuration Manager for SQL Server
• Setspn command reference

Next Steps

• SQL Server SPNs (MSSQLSvc)
• HTTP SPNs for IIS
• Trusted for delegation

Related Topics

• Kerberos Transparent Login After v7 Upgrade
• NTLM vs Kerberos Authentication
• Linked Servers
• Always On Availability Groups
• gMSA accounts
• Configuration Database
• Log Databases