Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

exec master.dbo.xp_cmdshell Expand / Collapse
Author
Message
Posted Thursday, December 13, 2012 1:49 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Thursday, September 11, 2014 7:35 AM
Points: 413, Visits: 1,337
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 ?
Post #1396386
Posted Thursday, December 13, 2012 7:46 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:46 PM
Points: 35,218, Visits: 31,676
LOOKUP_BI-756009 (12/13/2012)
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1396453
Posted Thursday, December 13, 2012 7:47 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:46 PM
Points: 35,218, Visits: 31,676
Shifting gears, jobs can be executed as "SA". Why do you have a user capable of running xp_CmdShell.

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1396454
Posted Friday, December 14, 2012 7:55 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Thursday, September 11, 2014 7:35 AM
Points: 413, Visits: 1,337
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.
Post #1396673
Posted Saturday, December 15, 2012 10:07 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 8:46 PM
Points: 35,218, Visits: 31,676
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
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1396901
Posted Monday, December 17, 2012 6:34 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Thursday, September 11, 2014 7:35 AM
Points: 413, Visits: 1,337
Restarting the server fixed the problem. Did not change anything, still not sure how that happend. Thank You
Post #1397231
Posted Thursday, December 27, 2012 4:52 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Friday, September 19, 2014 7:27 PM
Points: 7,107, Visits: 12,657
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
Post #1400755
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse