Question

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.]

Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top