locked
SQL Agent Job Step using a proxy account fails with A required privilege is not held by the client RRS feed

  • Question

  • Hi all,

    We are  running SQL 2014 SP1 Ent edition and I'm trying to set up a SQL Agent job step  that uses a proxy in order to copy a file to a file share on a remote server.  We created a domain account with limited privileges and I have set up the proxy and credentials as instructed by the MS articles including mapped access to msdb and granting the account the SQLAgentUserRole role.

    The file share has the correct permissions on the remote  directory for the account the credential is using as well. The job continually fails with the error " The process could not be created for step 1 of job xxxx reason: A required privilege is not held by the client". 
        
    I then found an article which stated the proxy account required the following privileges:
     Permission to log on as a service (SeServiceLogonRight)
     Permission to replace a process-level token (SeAssignPrimaryTokenPrivilege)
     Permission to bypass traverse checking (SeChangeNotifyPrivilege) 
      Permission to adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
     Permission to log on using the batch logon type (SeBatchLogonRight)
        
    These were granted however the error still persists. I even went ass far as granting "CONTROL SERVER " to the login ( just as a test)  with no avail, the job step still fails with the same error.
        
    I have researched this for 2 days and I can't see anything wrong in the set up of the credential, proxy or login.

    I'm at a loss at this point so if anyone has any suggestions  or has run into this before any help would be greatly appreciated.
       
       

    Wednesday, October 5, 2016 8:13 PM

Answers

  • I would change service account for Agent to something else, using the right tool: SQL Server Confguration Manager, and then change it back. Try after each change. When I have seen thiese problems, it has been because the proper priviliges haven't been grated to the service account for Agent. Using the right tool, SQL Server configuration Maneger has sorted things.

    Tibor Karaszi, SQL Server MVP (Web Blog)

    Monday, October 10, 2016 8:37 PM

All replies

  • Hi DMSQL2014,

    BOL explains a bit of this ... When a SQL Server user executes a command prompt command using xp_cmdshell, the command must execute in the security context of a Windows account. If the SQL Server user is a member of the sysadmin fixed server role, SQL Server executes the command prompt command using the Windows account under which the SQL Server service is running. If the SQL Server user executing xp_cmdshell is not a member of the sysadmin fixed server role, SQL Server executes the command using the Windows account specified as the SQL Server Agent proxy account. If no SQL Server Agent proxy account has been set, the user gets an error. 

    From the error it confirms a required privilege is not held by the client. Tyr using xp_sqlagent_proxy_account in assigning the correct rights to the user.

    https://social.msdn.microsoft.com/Forums/sqlserver/en-US/dc9fa982-bf27-4a68-a86c-12b4d11a598a/error-the-process-could-not-be-created-for-step-1-of-job-reason-a-required-privilege-is-not?forum=sqltools


    Please click Mark As Answer if my post helped.

    Thursday, October 6, 2016 3:21 AM
  •  Hi Dinesh,

    The proxy account is set up as well as the credential and the proxy account is active to the operating System (CmdEXEc) subsystem. The domain account is also listed as a SQL Login in the principals tab as well as  the SqlAgentUserRole. The job step that is using thus is also showing up correctly in the references tab on the proxy properties.

    Any other ideas?

    Thursday, October 6, 2016 2:14 PM
  • The question at hand has nothing to do with xp_cmdshell. Also, xp_sqlagent_proxy_account hasn't been used for many many versions of SQL Server.

    Tibor Karaszi, SQL Server MVP (Web Blog)

    Monday, October 10, 2016 8:35 PM
  • I would change service account for Agent to something else, using the right tool: SQL Server Confguration Manager, and then change it back. Try after each change. When I have seen thiese problems, it has been because the proper priviliges haven't been grated to the service account for Agent. Using the right tool, SQL Server configuration Maneger has sorted things.

    Tibor Karaszi, SQL Server MVP (Web Blog)

    Monday, October 10, 2016 8:37 PM