Creating a text file in SQL Server 2008 on a remote - non domain PC
-
Help !!! This is driving me mad - I'm trying to create a text file using sp_OAMethod on a remote PC that is not on a domain (we don't have one). I can create a file on the local machine no problem using both drive letter and UNC. When I try to write across the network it fails! I'm using windows authentication - with the same user set-up on the remote PC. When I create the file the owner of the file is Administrators and not the windows user that is running the stored procedure. Anyone got any ideas?
-
The owner of the file is account under which your SQL Server service is running.
It's pretty bad idea of creating files on remote PC's from SQL Server.
You can either create application which will reside on the PC where you want to place a file, and this application will query SQL Server and create a file.
Or
Create and application running on application server, which will do the same.
You are trying to use SQL Server for something it can do but it's not designed for...
-
it's permissions still.
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.
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! -
Andy Reilly (3/20/2012)
not on a domain (we don't have one). I'm using windows authentication - with the same user set-up on the remote PC.How can the same user be used between 2 servers not on a domain. Think about that. Windows Authentication only works between 2 servers on the same domain. If no domain, no Windows Auth. between the 2. SERVER1\username is not the same as SERVER2\username.
Jared
CE - Microsoft
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply