Trusted for delegation
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 credential can set up 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
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
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 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.
The Kerberos protocol is used over the connections with a linked server as seen in the graph above
The Kerberos protocol requires that the following Windows features are properly configured:
|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 UPD 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|
Make sure to perform the changes on the Active Directory server sponsoring the logon process. The Logon Server can be found out 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 synchronization 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)
Make sure to connect to the Nodinite SQL Server instance from the Nodinite Application server. If Nodinite Core Services and the Microsoft SQL Server is on the same machine, then you need to run the tool from some other Windows Server on the network.
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
In the Delegation tab, there should be no issues reported
You can enable the Trusted for delegation right in two different ways:
Settings are applied on the User object
In the Active Directory, you can enable the option to grant the SQL Server account, 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).
For this SQL Server service account, make sure to select target node names, cluster names and listener names as appropriate
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) (Fail over cluster)
- Listener name(s) (Always On)
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)
Delegation on Server Level
The steps outlined in the graph explains how the Logging Service process gets the Kerberos ticket working against the SQL Server instance fo BizTalk Server: