I have three machines participating in this exercise and I think I have everything configured properly -- but I'm still getting an error.
The error is the dreaded 'nt authority\anonymous' login error that we know comes from a double-hop issue from either a bad configuration of delegation or it not being configured, at all.
First machine is my client with SSMS 17.x; it is on this machine that I'll be right-clicking the package to configure the environment and execute.
Second machine is the dev server on which I have SQL 2017 and the Integration Services installed; it is this machine that stores the SSIS package I will be executing; I'm using a group managed service account for the SQL service set up with Kerberos Delegation
(constrained, but still functioning between this and the legacy instance).
Third machine is a legacy SQL 2008 R2 instance that contains an old database in which the SSIS package will be executing a sproc to return a dataset; I'm using regular domain user account configured as a service account; Kerberos Delegation has been set
on this account also (again, constrained).
The SSIS package has project-level connection managers that are configured to use Windows Authentication on each target instance (dev and legacy). Package runs fine from VS (as expected); also runs fine when I run it from the dev machine.
I'm credentialed up on all machines - I get the same error whether I use a domain admin or user account. The SPN's are set up so that the dev and legacy instances can communicate. In fact, the linked server connection is configured to use
Kerberos Delegation and works as expected; so I know Kerberos is configured properly (at least between the SQL service accounts).
But when I execute the SSIS package from my client machine, it will fail with the 'anonymous' error.
I understand that SQL 2008R2 SSIS doesn't support Kerberos Delegation -- well, maybe I understand it. I've always taken that statement to mean I can't run a SSIS package *from* SSIS 2008 and expect delegation to work. In this case, I'm executing
on SQL 2017 and trying to run a sproc on a 2008R2 database (basically an RPC call). I'm not using SSIS on 2008R2 at all.
Do I need to somehow configure a SPN for ISServerExec.exe, or will it use the SPN for the SQL service acct? Or -- is it that I'm using constrained delegation and need to add an entry for ISServerExec.exe (in whatever manner that service is identified
for SPNs)? Those're really my only thought-out questions -- the rest of it is; what am I missing?