1

I have a number of SQL Server Agent jobs running CmdExec statements.
They are simple jobs that call simple batch files.

They are run with a Run As: Proxy account, that has permissions to run as a CmdExec proxy, with a relevant linked Credential defined.
However when I try to run the job I get the following error:

Executed as user: PROXY_ACCOUNT.  
The process could not be created for step 2 of job (reason: Access is denied).  
The step failed.

When I grant the SQL Server Agent account permissions on the drive that the Proxy Account is trying to access, everything works.
This despite the fact that the Proxy Account already had permissions on the relevant drive.

As per the definition of proxy accounts the security context of the job step I'm running should be defined by the Proxy Account.
The documentation and articles about Proxy Accounts that I was able to find so far all indicate that when running the job step that has a Proxy Account defined, the SQL Server Agent should impersonate the credential, and run it with the Proxy Accounts security context.

So why is it that the Agent account also needs permissions on the relevant drive?
Am I misunderstanding something about the workings of a SQL Server Agent Proxy Account?

Reaces
  • 5,597
  • 4
  • 38
  • 46
  • The proxy account should be fine. My guess is that the access you granted the proxy account isn't sufficient to the task. Try widening access temporarily for the proxy account and see if that fixes it. The other thing to double check is make sure the job isn't server hopping (linked server). You may find the permissions issue isn't local. – Steve Mangiameli Mar 18 '16 at 14:49
  • @SteveMangiameli I agree that this is a likely cause. However I have elevated the account to sysadmin on the SQL Server, and copied the permissions from the SQL Agent user for the local permissions. Do you know of a way to see what permissions are lacking, based on my error above? – Reaces Mar 18 '16 at 15:30
  • You can check the event logs on the server, specifically the application logs and audit logs to see what's going on. You could also run a profiler trace and see if you can get a little more info. – Steve Mangiameli Mar 18 '16 at 15:36

0 Answers0