views:

1019

answers:

3

I get this error when I try to connect to a remote SQL server using this connection string.

Error:

ODBC error: 28000118452[Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user ''. The user is not associated with a trusted SQL Server connection.

Connection string:

"DRIVER={SQL Server};SERVER=testserver,1433;Trusted_Connection={Yes};"

Note this same connection string works fine if I specify the local computer.

My question: Why does the remote SQL server think my username is blank ''?

I did a valid login using the WNetAddConnection Win32 API to the remote machine first.

Edit: I get the same error when connecting from Management studio. But I thought my program would have a higher chance of working since I established a connection to the remote machine first.

Edit2: Note I really need a solution that uses Windows authentication. I already have it working with SQL authentication.

A: 

You might need SQL authentication by providing user and password in the connection string.

EDIT. I was curious to find out and I just found a good documentation of How to: Access SQL Server Using Windows Integrated Security

codemeit
see my edit2 above
Brian R. Bondy
I added a link in my post which might be helpful to your questions.
codemeit
A: 

I think that error might be because the UserId section isn't filled in (which is correct for Windows Auth).

Try a connection string like:

Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;

Another alternative which is supposed to be identical:

Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;

Maltrap
+1  A: 

Thoughts:

1.) are both machines in the same domain? I am thinking probably so because of your references to making a connection with WNet*...

If not, Integrated Security will give you problems.

Edit: I see that both machines are not in the same domain. To use Integrated Security, the domain that the SQL Server is in must trust the domain your local machine is in.

Another Edit: Corroboration for the above statement.

From link: This error message can appear if the user logging in is a domain account from a different, untrusted domain from the SQL Server’s domain. The next step for this is either to move the client machine into the same domain as the SQL Server and set it up to use a domain account, or to set up mutual trust between the domains. Setting up mutual trust is a complicated procedure and should be done with a great deal of care and due security considerations.

2.) Check to be sure the SPNs are set properly on the server.

Look HERE for more guidance, but basically you do:

setspn -L servername

one of the SPNs needs to look like:

MSSQLSvc/servername:1433

3.) One more Edit: If neither machine is in a domain, all you need to do is have a local userid/password that matches on both machines.

For example, a user named brian on both machines, and both users passwords are 'letmein'.

Moose
1) They are not on a domain and have diff u/p. wnet api work fine even when you are working with 2 machines not in a domain.
Brian R. Bondy
SQL Server does not use the WNet* apis though.
Moose
Hi Moose; Could you give me a hint on where to start looking about setting up this trust between computers?
Brian R. Bondy
I thought maybe the connection would be associated with the current session and that the sql driver would be able to connect. But no.
Brian R. Bondy
It's not a trivial thing. For one, you have to have domain admin rights in both domains. For another, setting up this trust means that users in the trusted domain can now access computers in the trusting domain. Let me rustle up a link..
Moose
Here's one for a Windows 2003 domain. Again, not for the faint of heart: http://technet.microsoft.com/en-us/library/cc740018.aspx
Moose
okay, I just read your comment again. I missed the part where neither machine is in a domain. All you need then is to have a matching username/pwd on each local machine, this is what I do at home.
Moose
I need a way where the 2 computers are not on the same domain and don't have the same u/p.
Brian R. Bondy
I think the only way that will be possible is with sql auth.
Moose