WCF service with impersonate cannot connect to SQL Server, but SSMS on the same machine will

Question

I have an issue that I simply cannot wrap my head around how to solve. In the bottom there's a WCF service (.NET 4.0) which is configured to impersonate a valid user like this:

<system.web>
    <compilation debug="true" targetFramework="4.0" />
    <identity impersonate="true" password="abc123" userName="domain\theuser" />
</system.web>

And a SQL Server connection string that looks like this:

<connectionStrings>
    <add name="MyTest.Service.Properties.Settings.ConnStr"
         connectionString="Data Source=192.168.0.54;Initial Catalog=TheDatabase;Integrated Security=SSPI;" />
</connectionStrings>

I have the WCF service running under IIS7 and in an application pool that is also running with the same users credentials.

IF I try to access the database, WITH these credentials (the user is set up as a valid user on the SQL Server), in SSMS on the SAME machine, everything works fine, but as soon as I try the same thing with the WCF service it throws me this:

System.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

What on earth can be the issue? I have other applications running on the server accessing other external SQL Server databases without any troubles.

Answer 1

It's likely your connection string as it's not an error being given for credentials.

If the SQL server is local, you can try "datasource=(local)" instead.

You can also try adding in the instance to the datasource as well.

If it's a SQL server that is remote, make sure the SQL server is configured to allow remote connections

Answer 2

Taken from msdn

If your database is on a remote server, you must also configure the relevant accounts in Active Directory for delegation. For example, you must ensure that your application's service account is marked as Trusted for delegation and that end user accounts are not marked as sensitive, which means that they cannot be delegated.