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.
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.
- Before proceeding, read 'Understanding Kerberos Double Hop' and 'How to configure the server to be trusted for delegation' for foundational knowledge.
- 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.
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:
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.
Delegation
In the Delegation tab, no issues should be reported.
You can enable Trusted for delegation in two ways:
- Service level (Constrained delegation – recommended)
- 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 |
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.
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)
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)
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:
Sequence: Logging Service authenticates and traverses SQL Server instances using Kerberos tickets.