SQL Server Job running as different user

Question

A year or so ago I started working on a project to set up a job to run a stored procedure. I've now come back to this to finish it off. When I run the job I get an error that he job is running under the 'build' user (this is a valid account on our system).

However I've no idea why it is doing this. I'm logged in as my own userID (keith.miller) and I cant see anything on the job. Here are the salient parts of my job creation SQL:

EXEC msdb.dbo.sp_add_job @job_name=N'Restore Database', 
        @enabled=1, 
        @notify_level_eventlog=0, 
        @notify_level_email=0, 
        @notify_level_netsend=0, 
        @notify_level_page=0, 
        @delete_level=0, 
        @description=N'No description available.', 
        @category_name=N'[Uncategorized (Local)]', 
        @owner_login_name=N'XXX\Keith.Miller', @job_id = @jobId OUTPUT

EXEC msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Restore', 
        @step_id=1, 
        @cmdexec_success_code=0, 
        @on_success_action=1, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'TSQL', 
        @command=N'EXEC dbo.spRestoreDatabase', 
        @database_name=N'master', 
        @flags=0

Would this happen if I created the job when logged in as 'build'? Is there a way I can check this or is there somewhere else I can look to see why the build user is being used?

Answer 1

If you aren't using a proxy (as the job step script shows that you are not) then there are two possibilities that I can think of. I typically only see proxies used for job steps that touch the world outside of SQL (file system operations and the like), so probably not this.

First, check the account that is running the SQL Agent service in the operating system (SQL Configuration Manager / Services.msc). By default, the Agent runs as this user.

Second and rarer possibility is that the procedure itself has an Execute As command in it that is changing who the procedure executes as. This is harder to setup and even rarer to see it setup properly so that it's secure, so I'm pretty sure that this is not the case.