Hi we run 2017 std. I didn't know whether to post this in the ssis forum or here. The bottom line is that my test service acct has permissions to read on my sql server after we added it to the appropriate nt group. We proved this by having a dba with sa execute as 'domain\newacct' select...
The acct's creds originate in a 3rd party scheduling product. The scheduler executes a powershell script on a different server. That script executes a proc on sql server a which runs some ssis on sql server a that (amongst other things) contacts sql server b. we see from the log on b that the login was as nt authority\anonymous logon. the login failed because token-based server access validation failed with an infrastructure error.
Can someone explain what is happening and if there is a low footprint way to get around this? there are actually 12 servers that the ssis on server a tries to connect to.
Its as if i'm getting at most 1 sql hop retaining my service acct's creds before they "get lost". I wouldn't really want to store the acct's creds in ssis but I suppose if that's a last resort and ssis has a fool proof way of doing that, maybe it would work.
I can say this. The ssis errors show that ssis knew the service acct was who ssis was running as.
from a connection standpoint, the powershell script specifies nothing more than sql server a's name and the database where the proc is to be run from.