December 13, 2012 at 1:49 pm
:ermm: Its been working all this while but for some reason it has stopped working for only 1 of our environment.
Even executing exec master.dbo.xp_cmdshell 'dir c:\*.txt' brings following error mssg
Msg 15121, Level 16, State 10, Procedure xp_cmdshell, Line 1
An error occurred during the execution of xp_cmdshell. A call to 'CreateProcessAsUser' failed with error code: '1314'.
Here is what I have confirmed so far
1) select * from sys.configurations = xp_cmdshell value is 1 (in column value, value_in_use, maximum)
2) The ##xp_cmdshell_proxy_account## uses a Domain Service Account . This Service Account is part of the Local Administrator group and has the following user rights permissions
•Act as part of the operating system.
•replace process level token.
•Log on as a batch job.
3) I have restarted the instance and still no luck
4) I am a sysadmin but was executing the above as a non admin user, the same user that runs this command through a job every night.
5) Executing the above as a sysadmin works perfectly fine
I think this is for sure a permission problem but not sure what else to check for ?
December 13, 2012 at 7:46 pm
LOOKUP_BI-756009 (12/13/2012)
:ermm: Its been working all this while but for some reason it has stopped working for only 1 of our environment.Even executing exec master.dbo.xp_cmdshell 'dir c:\*.txt' brings following error mssg
Msg 15121, Level 16, State 10, Procedure xp_cmdshell, Line 1
An error occurred during the execution of xp_cmdshell. A call to 'CreateProcessAsUser' failed with error code: '1314'.
Here is what I have confirmed so far
1) select * from sys.configurations = xp_cmdshell value is 1 (in column value, value_in_use, maximum)
2) The ##xp_cmdshell_proxy_account## uses a Domain Service Account . This Service Account is part of the Local Administrator group and has the following user rights permissions
•Act as part of the operating system.
•replace process level token.
•Log on as a batch job.
3) I have restarted the instance and still no luck
4) I am a sysadmin but was executing the above as a non admin user, the same user that runs this command through a job every night.
5) Executing the above as a sysadmin works perfectly fine
I think this is for sure a permission problem but not sure what else to check for ?
Have you checked the user to make sure that it still has privs to execute xp_CmdShell?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2012 at 7:47 pm
Shifting gears, jobs can be executed as "SA". Why do you have a user capable of running xp_CmdShell.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2012 at 7:55 am
Its a huge complicated SSIS package that makes calls to many different database's and calls to other applications. It is scheduled as a job and SQL Agent Service executes this job every night. Within the job all connections are made using a non admin account, so when a call is made to execute xp_cmdshell the non admin account uses the proxy account which belongs to the SQL Service Account credentials. This is how its been setup.
December 15, 2012 at 10:07 am
According to what I've found on Google, your error is a privs problem for a non-SA account. If it's been running fine for years and suddenly quit like you say, then there's a very high probability that, somewhere and somehow, someone changed the privs for the related account or for the SQL Agent account.
Sorry I can't offer much more than that. You may have to more closely isolate where the problem is happening and simply deduce where the privs changes occured (for whatever reason) from what occurs in the code or the SSIS package nodes.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2012 at 6:34 am
Restarting the server fixed the problem. Did not change anything, still not sure how that happend. Thank You
December 27, 2012 at 4:52 pm
LOOKUP_BI-756009 (12/17/2012)
Restarting the server fixed the problem. Did not change anything, still not sure how that happend. Thank You
I had this issue many many times on SQL 2005 SP4 running on Server 2003 and it beyond frustrating because I was never able to determine the root cause. In my case dropping the proxy and recreating it using sp_xp_cmdshell_proxy_account always did the trick.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply