I have 2 SQL servers: A & B. On A, I have a stored proc that processes some data from B and then dumps the results into a table on A. I need to schedule a job to run this proc.
According to http://msdn.microsoft.com/en-us/library/ms189064(SQL.105).aspx, it's the Job Owner that gets used when running the job. (Can't set a "Run as" on the job step for TSQL step/job.)
How the network people have set these machines / security up for is to use a third server, C, with centralised logins stored on that. So my login is: SERVERC\SEAN. This login has access to both DB servers, A & B. The proc runs fine if I execute when logged in and connected to Server A.
So I set the job owner as SERVERC\SEAN, but when the job runs, the error message is:
"Executed as user: NT AUTHORITY\NETWORK SERVICE. Login failed for user SERVERC\SERVERA$"
Why is it running as Network Service, and some weird login combination, instead of as the job owner, as instructed? How do I get this to work?
Thanks
Check out this post, it should do what you want it to.
Editing to show most helpful link
http://social.msdn.microsoft.com/Forums/en/sqltools/thread/54dff132-b9c9-4753-b0c5-2134bf7f4327
Related
I have my sql auth user, which has Insert access to table A in database A.
I have my team’s sql user, which has read access to table B in database B.
I need to create a SP, that will select from table B in database B and insert it in table A in database A. (and should run daily …)
What’s the most professional approach? I don’t want to use EXECUTE AS…
I also don’t understand… if the SP by default gets executed with the caller’s permission, the caller would be sql agent, so in the SP I could be dropping all the databases?! (what am I missing?)
if it gets executed with the creator permissions, is it executed with the creators permission at the moment of creation or at the current moment of execution?!
I'll tell you how I do similar things currently. We will have a Active Directory service account set up with the needed access, be it DBO, sys admin or data Writer. Create a job to run the script in question and the Job will use the SQL Agent's user ID or whatever account you designate.
Our SQL agent account has the needed permissions to run any jobs that are needed on the server and works the easiest for us. You only have to set it up once and then use that account for all jobs.
I have a SQL Job where I want to send an email alert if job fails. I know that for this functionalty I have to Configure Database Mail and than Adjust the properties within the SQL Server Agent. This article gives pretty good detail http://www.sherweb.com/blog/how-to-set-up-database-mail-for-sql-server-job-failures/.
What I want is, instead of setting up an email address to particular user like person1#test.com, I want to send an email to current user. This way who ever logged in to database and runs the job receives the email on job failure.
As I see, there are two benefits of this approach,
i. One particular user won't get flooded with emails. ii. Who ever is running the job can know that job has failed.
For example,
If I set person1#test.com and person2 logs in than on job failure person1 will receive an email. I don't want that. Is there any way that I can do this in SQL Server Agent Job settings. If no than how can I achieve this?
Like SELECT SYSTEM_USER or SELECT SUSER_NAME() gives me current user and use that as outgoing email address.
I think you are confused, if one user will start the job manually then you use a STORE PROCEDURE and there you can get the connected user information.
But pgAgent will run the process automatic and run using the USER you setup on the job.
I have a job which tries to access data from a remote server. I have created linked server which is connected successfully. When I try to access tables by directly running the query it works fine. But when I run same query via job it throws an error "login failed for user".
Job is assigned owner 'sa' and running with ssis proxy with sysadmin and public roles. In security tab of linked server properties I have no mappings and "be made using the login's current security context" selected.
I am not sure how should I correct it. If I should add mappings then what should be mapped? Please help me as I already spend whole day exploring possible options but couldn't find anything useful.
It does not matter who is the owner of package. Only the user under whom the packet is launched is important.
If this user is Windows (Windows domen) user, read this link.
If your user is sql-user, check it password and permissions on linked server.
If all from previous step are correct, try to add this user to mapping with checked Impersonate checkbox.
I have a stored procedure that I can execute in SSMS with a non domain SQL Server user.
This stored procedure selects data from tables in one database (DB1) truncates and selects into a table in DB2.
The user has datareader,datawriter and dbowner for both databases.
Problem:
When I execute the stored procedure via SS Agent with execute as the user I get the following error
The server principal [user] is not able to access the database [DB1]
under the current security context.
Actions taken So far:
I have tried to resolve this so far by:
Turning on db chaining for both databases
Deleted the user from DB1 and added again
Checked using EXEC sp_change_users_login #Action=’Report’ to see if user orphaned. As this is a database that is a restore of a live one. However I added the user after the restore. The user was not listed as orphaned
A possible workaround if you don't want to have the owner be sa is to have the user be a member of msdb and grant the the SQLAgentOperatorRole in msdb. See if that works.
But to be honest, either use sa or a dedicated service account with enough permissions. It's better if the job runs under that context.
In the past this command would work:
EXEC [linkedServerName].msdb.dbo.sp_start_job #job_name = 'test2'
Now I have to use the impersonate login and add the SQL service account (referenced in local login to impersonate) of calling server onto called server and giving it SA privilege: think I am doing something wrong, it shouldn't be so complicated should it?
Without the SA privilege on the impersonating account added to the remote server I receive error:
The EXECUTE permission was denied on the object 'sp_start_job', database 'msdb', schema 'dbo'.
Thank you
it shouldn't be so complicated should it?
This isn't any more complicated than the task you're doing. It's pretty basic security. If you want an account to be able to do things on a server, the account needs to have the proper access to that server. I'm not sure why you think it should be otherwise. Setting up proxy accounts isn't the most straightforward, but scheduling jobs from a remote server instead of the local agent isn't the most straightforward task, either.
Per the doc a user needs to be a member of the sysadmin, SQLAgentUserRole, SQLAgentReaderRole, or SQLAgentOperatorRole to be able to call sp_start_job.
The alternative is to configure the linked server to use a fixed security context or map a security context instead of impersonating one. This can be configured on the Security page of the Linked Server properties. Note that the account used for a fixed context still needs to be a member of one of the above roles to execute sp_start_job.