I have two servers A and B. B is a database server, A is (here) a client to the database server. A tool running on server A connects to SQL Server on server B and ultimately triggers a bulk import from a share on server A (\\servera\fileshare).
The tool on server A runs as localsystem. domain\servera$ has the required access to the SQL Server on server B.
The problem is SQL Server on server B cannot access \\servera\fileshare despite the SQL service account having all permissions to do so (on server A). I found out that this is because SQL Server tries to delegate the connection to the account that the utility uses to connect to SQL Server and that fails because the SQL Server service account does not have the right to delegate (and that setting cannot be changed by me).
I also found that if I connect using a SQL account (i.e. not an Active Directory account) using SQL authentication (and not Windows authentication), SQL Server connects to the fileshare using the SQL Server service account and everything works. The tool luckily supports using a SQL account. Unfortunately the password is given in plain text as a command line parameter and then appears in the process list among all other parameters. This is not good.
Is there a way to make SQL Server use its own service account when connecting to the fileshare without using a SQL account to connect to SQL Server?
This is SQL Server 2008 on Windows Server 2003.