December 18, 2006 at 4:46 pm
Logging in via a terminal server works, but not from my workstation, even though it's the same domain account.
We have a box running SQL Server 2000 (SP3) on Windows Server 2003. This box was recently added to a domain (it was domainless before). The SQL Server and agent services now run under a domain account as well. Obviously, we've been using sql logins almost entirely to this point.
I granted my own domain account access to login, and was able to successfully log in through Enterprise Manager from a terminal server on the same domain. However, when I attempted to log in the same way from my workstation (same domain and account again), I get the following error:
Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection
Any help would be much appreciated.
December 18, 2006 at 5:00 pm
It's not getting your credentials. Sometimes this can be resolved by installing the latest MDAC version on your workstation.
Also, I would double-check your login on SQL Server. Make sure you don't have two of the same logins:
domain\myname is the same as myname.
Make sure that your login has a default database and that it has permissions to access the database. Sometimes a login is created but the creator overlooks adding the login to a database and giving it rights to do anything.
-SQLBill
December 18, 2006 at 5:22 pm
Thanks for responding, SQLBill.
I think you're right about not getting my credentials. Running a profile, I noticed that information that came through when logging in from the terminal server wasn't there when logging in from my workstation.
Component Checker reports that I have MDAC 2.8 sp1, which is the latest, so that can't be it..
The login does have a default database, and has permissions to several databases.
When you say domain\myname is the same as myname, is that true if myname is a standard login type (sql login) and not a Windows User?
December 19, 2006 at 1:04 am
Try specifying network protocols while connecting...
To connect using named pipes you have to "np:" for tcp/ip you should "tcp:"
In Client Networ Utility check enabled protocols and try changing the protocol order...
MohammedU
Microsoft SQL Server MVP
December 19, 2006 at 10:03 am
quote: When you say domain\myname is the same as myname, is that true if myname is a standard login type (sql login) and not a Windows User?
Yes. I found this out when I had a domain account (ex. domain\sqlbill) and tried to create a SQL Server login for testing purposes. It didn't like sqlbill and I had to use billsql.
-SQLBill
December 20, 2006 at 5:14 pm
SQLBill: tried removing my sql login (it did match), but that did not solve the problem. However, that's not to say it wasn't a problem, just that there was another problem on top of it.
I tried Mohammed's suggestion, giving Named Pipes priority over TCP/IP on my workstation. That worked. Just to be sure, I switched it back. It stopped working. Once more and it worked again.
I looked at the terminal server I used for my testing, the one that would let me in. It has TCP/IP set above Named Pipes. This indicates to me that there is still an underlying problem on my workstation. If anyone has clues, I'd like to fix this problem.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply