- 5 minutes to read

Trusted for delegation

Enable secure, multi-tier authentication for your distributed Nodinite environment by configuring 'Trusted for delegation' in Windows Server and SQL Server. This guide explains why delegation is essential, how to set it up, and how to avoid common pitfalls in Kerberos authentication.

✅ Ensure secure Kerberos authentication for distributed SQL Server and BizTalk scenarios
✅ Step-by-step guidance for configuring delegation, SPNs, and service accounts
✅ Troubleshoot and resolve double-hop and linked server issues

Enable Kerberos for Microsoft SQL Server instances that make a jump using a Linked Server.

Trusted for delegation is a Windows Server policy setting. Nodinite and other multi-tier applications use delegation of authentication to securely pass user credentials across multiple servers. To use Kerberos, both client and server must run under accounts trusted for delegation.

Delegation allows users to connect to multiple servers, retaining the original authentication credentials throughout the chain. Only administrators with the "Enable computer and user accounts to be trusted for delegation" right (typically Domain or Enterprise Admins) can configure this setting. The procedure depends on your domain's functional level.

Anonymous
A common error when 'trusted for delegation' is not properly configured.

Tip

Settings on this page often require a reboot. Plan changes for a maintenance window.

  1. Before proceeding, read 'Understanding Kerberos Double Hop' and 'How to configure the server to be trusted for delegation' for foundational knowledge.
  2. Review our recommendations about using SQL Server with Nodinite.

Kerberos is required if you use multiple SQL Server instances for Nodinite and/or a remote BizTalk Server for Logging. When logging from BizTalk is enabled, the Logging Service may span multiple Log Databases, including BizTalk databases. The Logging Service account must authenticate with SQL Server using Kerberos. See the Log Database prerequisites guide.

graph LR subgraph "Nodinite" rols(fa:fa-hard-drive Logging Service) end subgraph "Nodinite SQL Server " rols --> roCPL(fa:fa-database Config Database) end subgraph "BizTalk SQL Server " roCPL --> |Linked Server| roBT(fa:fa-database BizTalkMgmtDb) roCPL --> |Linked Server| roBT2(fa:fa-database BizTalkDTADb) end subgraph "Nodinite SQL Server Archive" roCPL -.-> |Linked Server| roLog(fa:fa-database Nodinite Log Archive Database) end

As shown above, Kerberos is required when jumping between SQL Server instances using a linked server.

Kerberos requires the following Windows features to be properly configured:

Windows Feature/Setting Comment
Trusted for delegation on the Service level All SQL Server instances with a linked server that jumps to another remote SQL Server
Account for SQL Server instance(s) Should run as a Windows Active Directory account to restrict delegation on the Service level. This also helps ensure SPN registration
SPN All SQL Server node, cluster, and listener names must be configured. Verify with the Microsoft Kerberos Configuration Manager tool
Firewall(s) TCP/UDP ports for RPC, DTC, Kerberos, DNS, and SQL Server must be allowed
Authentication and Authorization The Logging Service account must have proper access rights on target databases

Note

The domain functional level must be 2003 or later.

Important

The account must NOT have 'Account is sensitive and cannot be delegated' checked.

Logon Server

Make changes on the Active Directory server that handles the login process. Find the Logon Server by typing Set at the command prompt:
Logon Server

Note

If you change settings on another AD server, wait or force replication.

Run the following command to update your server's configuration (or allow time for replication):

gpupdate /force

Tip

Use the Microsoft Kerberos Configuration Manager tool to validate SPNs and ensure proper delegation settings.

Connect locally to the Nodinite SQL Server instance (no connection details needed):

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

Default install path for the Microsoft Kerberos Configuration Manager tool.

If issues are detected, the tool provides PowerShell scripts for a Domain Admin to resolve problems.

SPN

Nodinite SQL Servers making the hop should all be listed in the SPN tab, with status OK.
SPN tab

Delegation

In the Delegation tab, no issues should be reported.
Delegation

You can enable Trusted for delegation in two ways:

  1. Service level (Constrained delegation – recommended)
  2. Server level (General delegation)

1. Service level

Note

Settings apply to the User object.

In Active Directory, enable the option to grant the SQL Server account used for the Nodinite SQL Server instance the right to be 'Trusted for delegation' to selected target services. The SQL Server must run with an Active Directory service account (not a local/computer account).

Account Comment
Nodinite SQL Server

Add Services
For this SQL Server service account, select all relevant target node, cluster, and listener names.

Select the service account (an AD domain account) for the SQL Server instance to be trusted for delegation.

Important

Do NOT select the computer account.

Service Level Delegation
Example: SQL Account with 'trusted for delegation' set on the Service Level for selected targets.

Repeat for each target SQL Server instance as needed:

  • SQL node name(s) (stand-alone and for any combination)
  • Cluster name(s) (Failover cluster)
  • Listener name(s) (Always On)
graph LR subgraph "Nodinite SQL Server " roCPL(fa:fa-user-cog Nodinite SQL instance Account) end subgraph "BizTalk SQL Server " roCPL --> |Linked Server| roBT(fa:fa-database BizTalkMgmtDb instance Service Account) end subgraph "BizTalk SQL Server" roCPL --> |Linked Server| roBT2(fa:fa-database BizTalkDTADb instance Service Account) end subgraph "Nodinite SQL Server Archive" roCPL -.-> |Linked Server| roLog(fa:fa-database Nodinite Log Archive instance Service Account) end

2. Server level

Note

Settings apply to the Server object.

Set the "Trusted for delegation" option in Active Directory at the server level (listener, cluster, or node name).

Repeat as needed:

  • SQL node name(s) (stand-alone and for any combination)
  • Cluster name(s) (Failover cluster)
  • Listener name(s) (Always On)

Server Level
Delegation on Server Level

Kerberos ticket

The following diagram explains how the Logging Service process obtains a Kerberos ticket for the SQL Server instance for BizTalk Server:

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) ->> BizTalk SQL (BizTalkMgmtDb): Client TGT and SQL service ticket BizTalk SQL (BizTalkMgmtDb) ->> SQL (Configuration Database): Response SQL (Configuration Database) ->> Logging Service: Response

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