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
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy