views:

1107

answers:

1

I have a strange scenario that I am currently unable to explain. I live in hope that it's just "the Friday feeling" or that some kindly sole here will bail my brain out and save me from endless loops of "but why!?" :)

Two servers, running SQL Server 2005, with DNS Entries of:

1. ServerA  
2. ServerB

(Well, they're not really called that, but it will suffice...)

On both SQL Server Instances there are Linked Servers configured pointing to the other server.

For obvious security reasons the LinkedServer Security configuration is set to:

- Be made using the login's current security context

The other "Linked Server Options" are...

Collation Compatible: True
Data Access:          True
RPC:                  True
RPC Out:              True
Use Remote Collation: True
Collation Name:       <blank>
Connection Timeout:   30
Command Timeout:      10

A login is created with the same password on both Instances. The logins are given the appropriate execute permissions to the relevant stored procedures.

I write some code, and execute it under that login and it all works hoorah


But when I create an Agent Job to run these stored procedures it all goes wrong. The owner of the Agent Job is 'automated_job_login' but my error logging gives the following: - Login failed for user 'automated_job_login'

(Again that name has been altered to protect the guilty.)


I can't figure out for the life of me why it will work when I log in as that user, but the job errors when connecting to the linked server. (It's definately at the point of the linked server connection.)

To make things more confusing, if I change the Linked Server Security configuration to "Be made using this secuirty context:" and specify 'automated_job_login' with the correct password, it works fine.

I'm missing something, I know I must be, but I can't find what. I've read documentation until my eyes bleed and I've failed. Please help me :)


[Leaving the Linked Server Secuiry option as "Be made using this secuirty context:" is not an option as this would give all users of that server unnaceptable levels of access to the other server.]

+2  A: 

The SQL agent job may be owned by your login, but it is not executed in that login context. It's in the SQL Agent service account context

Because you have SQL Server 2005, you could use EXEC AS USER = 'mylogin' as a stored proc option.

Otherwise, you have to set the database user name using the @database_user_name parameter of sp_add_jobstep. In SSMS, you can set the context. Job ownership is slighty different to setting ths, IIRC.

gbn
Thanks for the help, have had a look around about this already. Basically, even though my login is in the sysadmin group I still can't change the "Run As" option in the agent job...
Dems
perhaps at the sp_add_jobstep level then? Sorry, but I don't have access to verify exactly in my shop. However, can you change any bits of the job?
gbn
I've found an article that pointed out that there are TWO places to set the "Run As", and only the second is usable for T-SQL jobs. Unfortunately I still get the failed login error *goes cross eyed*. http://tinyurl.com/cyaeyw
Dems
Can you use profiler to see what's *really* happening?
gbn
Not at present, though I should be able to by Wednesday... All I can do at present is isolate the exact line of code and the associated error message.
Dems
+1 for being the only person trying to help :)
Dems
Thank you. My next thought (but can't find it in BOL) is that user context change is not allowed for linked servers...
gbn
That would make the use of linked servers by agent jobs virtually redundant. I can't accept that MS would force people to compromise security to do so. But I can accept that they made it extremely convoluted AND difficult to find out how.
Dems