sql-serverwindowsauthenticationscheduled-tasksdelegation

How to Delegate Credentials through double hop to SQL Server?


What I am trying to do:

We have a Task Scheduler that kicks off an EXE, which in the course of its runtime, will connect to SQL Server.

So that would be:

  1. taskServer.myDomain triggers the Task Scheduler action
  2. taskServer.myDomain exe runs locally
  3. taskServer.myDomain initiates a connection to sqlServer.myDomain

The scheduled task is associated with a service account (svc_user) that is set to run with highest privilege, run whether the user is logged in or not, and store credentials for access to non-local resources.

The actual behavior

What we are seeing is the Task Scheduler is indeed running as svc_user. It triggers the EXE as expected, and the EXE is also running as svc_user. When the EXE initiates a connection to SQL Server, it errors on authentication.

Looking at the Event Viewer we can see the failure trying to initialize the connection to SQL

Exception Info: System.Data.SqlClient.SqlException
   at System.Data.SqlClient.SqlInternalConnectionTds..ctor(System.Data.ProviderBase.DbConnectionPoolIdentity, System.Data.SqlClient.SqlConnectionString, System.Data.SqlClient.SqlCredential, System.Object, System.String, System.Security.SecureString, Boolean, System.Data.SqlClient.SqlConnectionString, System.Data.SqlClient.SessionData, System.Data.ProviderBase.DbConnectionPool, System.String, Boolean, System.Data.SqlClient.SqlAuthenticationProviderManager)

And then looking at the SQL Server logs we can see the root of the issue

Logon,Unknown,Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Could not find a login matching the name provided. 

The connection initialized by the EXE to SQL Server is trying to authenticate as ANONYMOUS LOGON.

What I have tried

Background

This issue popped up when our IT team started deploying a GPO lockdown in our environments. So in order to get to this point, we first had to add some GPO exceptions to allow the svc_user to:

Progress?

This is where we started being able to capture the ANONYMOUS LOGON error in SQL Server. From there we tried a handful of other GPO exceptions including

The actual issue?

So it would appear that this is a double hop delegation issue. Which eventually led me here and then via the answer, here and here.

So I tried adding GPO policies to allow delegating fresh credentials using the WSMAN/* protocol + wildcard.

Two issues with this:

So, I added the protocol MSSQLSvc/* to the enabled delegation and tried all permutations of Fresh, Saved and Default delegation. (This was all done in Local Computer Policy -> Computer Configuration -> Administrative Templates -> system -> Credentials Delegation)

Where it gets weird

We have another server, otherServer.myDomain, which we setup with the same TaskSchedule. It is setup with the same GPO memberships, but seems to be able to successfully connect to SQL Server. AFAIK, the servers are identical as far as setup and configuration.

The Present

I have done a bit more digging into anywhere I could think that might offer clues as to how I can feed the credentials through or where they might be falling through. Including watching the traffic between the taskServer and the sqlServer as well as otherServer and sqlServer.

I was able to see NTLM challenges coming from the sqlServer to the taskServer/otherServer.

Question

What is the disconnect between hop 1 (task scheduler to EXE) and hop 2 (EXE to SQL on sqlServer)? And why does this behavior not match between taskServer and otherServer?


Solution

  • So I finally have an update/solution for this post.

    The crux of the issue was a missing SPN. The short answer: