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
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 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 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 |
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
Delegation
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).
SPN
In the SPN tab, the Nodinite SQL Server making the hop, should all be listed and the status should be in the OK state
Delegation
In the Delegation tab, there should be no issues reported
You can enable the Trusted for delegation right in two different ways:
- Service level (Constrained delegation - recommended)
- 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 |
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
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)
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)
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: