Remote access not allowed for Windows NT user activated by SETUSER
in [Server Configuration]
|
From: Ian Boyd on 18 Feb 2005 14:09 i can login as an SQL Server user (FinanceArchiveTraining), and run my desired stored procedure. This sp accesses a linked sever. i want a scheduled job that does this for me. But of course i get: Remote access not allowed for Windows NT user activated by SETUSER What magical combination of the job's "Owner" and the one and only step's "Run as User" do i have to set in order to make it go? Of course the SQL Agent has no rights to the remote server, it's the agent. i want the agent to run the job as though it were FinanceArchiveTraining. And while we're at it, what is "Owner" anyway? And why does "Owner" have to be "sa" before "Run as User" option will enable? What is "Run as User" anyway? It apparently doesn't run the TSQL as that user.
From: Ian Boyd on 18 Feb 2005 14:40 i log into the server in QA using sa. > setuser 'FinanceArchiveTraining' > execute Archive_AllSessions Server: Msg 7410, Level 16, State 1, Procedure Archive_PullOldestSessionFromLive, Line 9 Remote access not allowed for Windows NT user activated by SETUSER. i guess, the answer to my question is that "SETUSER can be used by members of the sysadmin or db_owner roles to adopt the identity of another user" is not true. The BOL should read: "SETUSER can not be used by members of the sysadmin or db_owner roles to adopt the identity of another user"
From: Ian Boyd on 18 Feb 2005 15:13 Login to QA using sa: SETUSER 'FinanceArchiveTraining' SELECT * FROM CMSLive.CashierManagementSystemTraining.dbo.Cages Server: Msg 7410, Level 16, State 1, Line 2 Remote access not allowed for Windows NT user activated by SETUSER. What "Windows NT" user? i logged into QA using sa. What are you talking about SETUSER. i am FinanceArchiveTraining. Who between the two servers is not honoring the fact that i am now "FinanceArchiveTraining?" More importantly, why are they not honoring it?
From: Ian Boyd on 18 Feb 2005 15:20 > More importantly, why are they not honoring it? Is SQL Server deciding to not honor SETUSER when connecting to a remote server? What credentials does it fall back to? i logged in as SA originally, but SA is allowed to perform that query. It must not be falling back to the original login. It must be falling back to credentials of SQL Server itself, since i connect using SQL authentication, the QA client has no windows credentials. But all others connections to the remote server map to a single login in the linked server - so no matter what credentials it is using, they all fail. That means that it can't even be a security issue. The local server and the remote server must be conspiring together to shut me out, when the local server tells the remote server that, "he has run SETUSER to change who he is." They then decide that i am just not allowed access.
|
Pages: 1 Prev: Error Message: SQLState 'S1000' Cannot generate SPPI Context Next: VSS with SQL server |