Re: xp_cmdshell issue, local system

From: Dan Guzman (guzmanda_at_nospam-online.sbcglobal.net)
Date: 11/23/05


Date: Wed, 23 Nov 2005 09:00:48 -0600


> Msg 50001, Level 1, State 50001
> xp_cmdshell failed to execute because CreateProcessAsUserW returns error
> 1314. please make sure the service account SQL Server running under has
> appropriate privilege.

As the message indicates, this error may be because the SQL Server service
account doesn't have the rights necessary to change security context to the
proxy account. Specifically, 'act as part of operating system' and 'replace
a process level token' are needed. These rights are set automatically
during SQL Server installation and when the account is changed using
Enterprise Manager but not when you change the account directly from
Windows.

The easiest way to assign the rights is to use EM to change the SQL Server
account to local system and then back to the desired domain account.

-- 
Hope this helps.
Dan Guzman
SQL Server MVP
"yodarules" <yodarules@discussions.microsoft.com> wrote in message 
news:8BD28577-F4B6-4F84-B116-F9930A32F8AC@microsoft.com...
>I want to give access to a regular user to execute xp_cmdshell.  To do so, 
>I
> followed all KB articles and did the following
>
> EXEC master.dbo.xp_sqlagent_proxy_account N'SET',
>             N'Domain', -- agent_domain_name
>             N'name', -- agent_username domain
>             N'password' -- agent password
>
> -- Enable non-system administrators to run the job and to execute 
> xp_cmdshell.
> EXECUTE msdb..sp_set_sqlagent_properties @sysadmin_only = 0
>
> grant execute on xp_cmdshell to name -- Enter the user name again without
> quotes
>
> If I log in as this user 'name' and execute master..xp_cmdshell 'dir'. 
> Its
> fine.  My problem is, the system that I want this to work in is not part 
> of a
> domain.  Its a stand alone SQL Server box.  So I set these
> EXEC master.dbo.xp_sqlagent_proxy_account N'SET',
>             N'computer-name', -- agent_domain_name
>             N'localuser', -- agent_username domain
>             N'password' -- agent password
>
>
> When I set as local user and computer name I get no errors.  But when I
> execute xp_cmdshell I doesn't work.  The localuser is part of 
> administrators
> group as well.  The error that I get is
>
> Msg 50001, Level 1, State 50001
> xp_cmdshell failed to execute because CreateProcessAsUserW returns error
> 1314. please make sure the service account SQL Server running under has
> appropriate privilege. For more information, search Book Online for topic
> related to xp_sqlagent_proxy_accoun
>
> Has anyone seen this before and any ideas to resolve it.  Thanks. 


Relevant Pages

  • Re: Execute Persmission denied on object sp_OACreate
    ... > I logged in as that user, tried to execute the DTS ... which then launches the DTS package using the sp_OA* procs? ... account is used during proc execution. ... > proxy account to use in the Job Systems tab of SQL Server Agent ...
    (microsoft.public.sqlserver.security)
  • Execute Process Task not failing, but not executing the batch comm
    ... I can execute the following command from the windows "Run" prompt and it ... Might I have something set weird in SQL Server? ... server being by default configured to run as localsystem account, ...
    (microsoft.public.sqlserver.dts)
  • Re: dts or xp_cmdshell permissions
    ... You could have the users execute the package ... Change the SQL Server or SQL Server Agent Service ... >> Account Without Using SQL Enterprise Manager in SQL Server ...
    (microsoft.public.sqlserver.tools)
  • Re: bcp data export from SQL Server to file
    ... the OS security context will be the SQL Server ... service account when executed by a sysadmin server role member. ... But when I execute it threw the application - nothing ...
    (microsoft.public.sqlserver.programming)
  • Re: Error 15401 using sp_grantlogin (not addressed by current KB articles)
    ... Restarting Windows 2000 resolved the problem for this particular account, ... confused when it sees a duplicate SID. ... > One way to get SQL Server to agree with the renamed NT ... > Preview (to ensure the script was created), ...
    (microsoft.public.sqlserver.security)