- 5 minutes to read

Trusted for delegation

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

Trusted for delegation is a Windows Server policy setting. Delegation of authentication is a capability that client and server applications like Nodinite use when they have multiple tiers. For this configuration and to use the Kerberos security protocol, the client and the server must run under accounts that are trusted for delegation.

Security account delegation provides the ability to connect to multiple servers, and each server change retains the authentication credentials of the original client.

Only administrators who have the Enable computer and user accounts to be trusted for delegation credentials can set up the delegation. Domain admins and Enterprise admins have this credential. The procedure to allow a user to be trusted for delegation depends on the functionality level of the domain.

A common error for problems related to not having the trusted for delegation option properly configured

A reboot is often required if you need to change any of the settings described on this page. Make sure to have a plan, and perform the changes during a maintenance window

  1. Before you read this article, please read the 'Understanding Kerberos Double Hop' first. For additional information, review the 'how to configure the server to be trusted for delegation' user guide

  2. There is a general page with recommendations and some useful comments about SQL Server to be used with Nodinite, make sure to read this as well

The Kerberos security protocol is used IF you are using multiple SQL Server database instances for Nodinite and/or if you are using a remote (distributed) installation of Microsoft BizTalk Server for Logging.

The Logging Service initiates a process that may span multiple Log Databases which may also include some BizTalk Server Databases when Logging from BizTalk Server is enabled. The account, running the Logging Service, authenticates with SQL Server, Kerberos must be properly configured. Please also review the Log Database prerequisites user guide.

graph LR subgraph "Nodinite" rols(fa:fa-hdd 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

The Kerberos protocol is required when jumping from one SQL Server instance to another, using a linked server as seen in the diagram above

The Kerberos protocol requires that the following Windows features are properly configured:

Windows Feature/Setting Comment
Trusted for delegation on Service level All SQL Server instances with a linked server that makes a jump to some other remote SQL Server instance
Account for SQL Server instance(s) Should ALL run as a Windows Active Directory account to restrict delegation on Service level. Also, the SPN is more likely to be registered properly in the Active Directory in this way
SPN All SQL Server node names, cluster names, listener names must be properly registered, verify with Microsoft Kerberos Configuration Manager tool
Firewall(s) TCP and UDP ports used for RPC, DTC, Kerberos, DNS, and SQL Server must be allowed
Authentication and Authorization The account running the Logging Service, must have the proper access rights on the target databases
The domain functional level must be 2003 (or later)
The account must NOT have the following option checked: Account is sensitive and cannot be delegated

Logon Server

Make sure to perform the changes on the Active Directory server sponsoring the login process. The Logon Server can be found if you type Set from the command prompt:

If you are performing the changes on some other Active Directory Server, then you must either wait or force a synchronisation of the replication information

Make sure to run the following command to make sure your server gets the new configuration (or allow some time for your Domain Controllers to replicate the new setting first)

gpupdate /force


TIP: Use the Microsoft Kerberos Configuration Manager tool from Microsoft to validate the SPNs, and that the proper settings to enable the trusted for delegation right exists

Make sure to connect locally to the Nodinite SQL Server instance (then you do not need to provide any connection details)

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

Default install path for the Microsoft Kerberos Configuration Manager tool

If there are issues detected, the tool provides Powershell scripts that a Domain Admin can use and execute to resolve the problem(s).


In the SPN tab, the Nodinite SQL Server making the hop, should all be listed and the status should be in the OK state
SPN tab


In the Delegation tab, there should be no issues reported

You can enable the Trusted for delegation right in two different ways:

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

1. Service level

Settings are applied on the User object

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

Account Comment
Nodinite SQL Server

Add Services
For this SQL Server service account, make sure to select target node names, cluster names and listener names as appropriate

Select the service account (either the domain or the local account) for the SQL Server instance to be trusted for delegation.

Do NOT select the computer account

Service Level Delegation
SQL Account trusted for delegation on Service Level against selected targets

Repeat for target SQL Server instances as appropriate:

  • SQL node name(s) (stand-alone and for any of the following combinations)
  • 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

Settings are applied on the Server object

The Trusted for delegation option can be set on the server level (listener name, cluster name, node names) in the Active Directory.

Repeat as appropriate:

  • SQL node name(s) (Stand-alone and for any of the following combinations)
  • Cluster name(s) (Fail-over cluster)
  • Listener name(s) (Always On)

Server Level
Delegation on Server Level

Kerberos ticket

The steps outlined in the graph explain how the Logging Service process gets the Kerberos ticket working against 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