Problems with xp_cmdshell
-
I'm hoping people can help me on this one, I'm having problem using the xp_cmdshell to rename or delete a file.
the xp_cmdshell option in enabled, the folder use is a shared folder and everyone has rights to do anything (in a deperate attempt to narrow down the problem) the user is sysadmin on the db and on the server where the folder which hold the file which needs delete/rename is hosted, yet with all this when I run the command
EXEC xp_cmdshell 'rename \\server\SQLBackups\test.txt test_rename.txt '
OR
EXEC xp_cmdshell 'del \\server\SQLBackups\test.txt'
I get and access denied problem.
Can anyone help me on this .:-)
-
The SQL Server Service account must have permission to perform the action, both on the share and the file. If it runs as local system, it does not have access to anything on other servers (unless anonymous has access, which I sincerely hope not).
I would prefer to run SQL Server as a domain account, but networked_service works as well. In the latter case, you must grant access to the computer account of your SQL Server.
That said, xp_cmdshell is one of the worst security issues with SQL Server, and it is a reason why it is disabled as default. Anyone with access to it, can do anything on the server that the SQL Server Service account has permission to.
Hope this helps.
-
In General, SQL Account with out SA dont have permission to access files on shared folder. You must give SA rights to that account if you are using SQL account. Or if you use windows account, provide the share permission on that shared folder and configure the activities in a SQL job as well as provide the respective proxy account to do this xp_cmdshell activity.
-
Thats really weird as it's using a domain account and it has sa admin right on windows server and sql server.
All I really want to do is delete an old backup as part of a procedure once its been used, but people warn against using xp_delete_file as its undocumented and against enabling XP_cmdshell
is there any other options?
-
the domain account under which your sql server is running may be dont have local administrator privilage.
-----------------------------------------------------------------------------
संकेत कोकणे -
Cheers guys, I've still not sorted it, but I've decided to look at a different route now
Thanks for the help though 🙂
-
this is a common security misconception/"gotcha". The problem is that when you access any resource OUTSIDE of SQL server, like network shares, local hard drives and folders,xp_cmdshell,bcp with a "trusted" connection, sp_OA type functions etc.
it doesn't matter what YOUR credentials are. Whether you are Domain Admin,Local Admin , logged in as sa, administrative login on a laptop, etc, because SQL will not carry those credentials to the "outside of SQL" security context.
SQL WILL pass your credentials to a linked server, but anything else is using an account you did not intuitively expect it to use.
SQL Server uses either the account set up as the proxy account, or if that is left blank(the default) it uses account it starts with to try and access the resource:
or if the above was blank, the account in services:
That account is often an account which has never logged into the domain, and was never assigned permissions to get to the local disk or network share.
As a result, you usually need to create a domain account in Active Directory, specifically grant it share access if it doesn't inherit it from Domain\Users or Domain\AuthenticatedUsers and change the account SQL Server starts with to that account.
Once that is done, and you stop and start the SQL service to make it use that account instead of old running values, your linked server/xp_cmdshell would work.
you can prove this is the issue by simply putting in your credentials, with your domain account and password, and confirm the external object you were trying to access/use works when SQL is run your credentials, so you'd know you need a domain account to access the resource.
[/quote]Lowell
--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply