June 7, 2011 at 11:23 am
I'm getting the following error when trying to connect to a server using SSMS.
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Now, my case is very specific in that it is only affecting one domain account on one specific workstation while trying to connect to one specific server. Bear with me as I try to illustrate the scenario.
For simplicity, let's say we have:
Server1, Server2
and
Workstation1, Workstation2
and
Account1, Account2,
all on the same domain.
The issue is that I only get this error when using Account1, logged into Workstation1, while trying to connect to Server1. All other scenarios work perfectly.
For example, Account1 CAN connect to all other servers while using Workstation1, just not Server1. Also, Account1 CAN connect to Server1 when using any other workstation. Furthermore, Account2 (and any other account) CAN connect to Server1 while using Workstation1.
I can't for the life of me figure out what is wrong and this issue just popped up. Account1 was having no problems for over a year. I've uninstalled and reinstalled SQL Server on Workstation1 and it did not resolve the issue.
Any help would be great!
June 7, 2011 at 11:47 am
Is the database instance on Server1 a named instance?
Some things to look into:
Is SQL Browser running on Server1?
Is port 1434 open between Wrokstation1 and Server1? Use PortQryv2 to find out.
Does Workstation1 have a version of the Native Client that matches the major and minor patch level of Server1?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
June 8, 2011 at 5:46 am
Since it's so specific, you might want to look at the Configuration Manager and see if there's an alias created on the server that might be affecting how connections are run from that workstation. Also check the connection settings there. Otherwise, I'm not sure what that might be.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 9, 2011 at 1:05 am
Have you checked the value of the "STATE" part of the error message from the SQL error log on Server 1? That might point you to the specifics of why the connection is failing or whether it is connecting and dropping for some other reason?
Failing that, I would look at deleting the User 1 profile from Workstation 1 and logging in again from scratch - there may be something within the profile that is messed up. That might explain why it is only that user on that specific workstation.
June 9, 2011 at 7:16 am
Thanks for the replies everyone. Still no luck. Here is what I've tried from the suggestions:
@opc.three - Server 1 is a named instance. SQL Browser is running. Tried PortQryv2 but it wouldn't run for some reason. Workstation1's client matches Server1 perfectly, like I said, other users are able to connect to Server1 from Workstation1 with no problem.
@Grant Fritchey - There's no alias on the server.
@martin-2 Cairney - I can't find anything helpful in the error logs. We actually tried deleting User1 from Workstation1 yesterday and had him start off fresh but the same error popped up.
Thanks again for the suggestions. Still trying...
June 9, 2011 at 7:28 am
kurtyue (6/9/2011)
@opc.three - Server 1 is a named instance. SQL Browser is running. Tried PortQryv2 but it wouldn't run for some reason. Workstation1's client matches Server1 perfectly, like I said, other users are able to connect to Server1 from Workstation1 with no problem.
What does "wouldn't run" mean?
Can the workstation connect to the server via IP and port number?
Like this:
255.255.255.255,9999
instead of:
Server1\NameOfInstance
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
June 9, 2011 at 7:31 am
"Good news everyone!" (said in the voice of the Professor from Futurama)
It looks like the removal of User1's documents and settings folder on Workstation1 actually did work. We just didn't reboot after doing it yesterday. After a reboot this morning, the issue is fixed!
Thanks so much for the help on this!
June 9, 2011 at 7:34 am
:w00t: I'll add it to the list of things to try as a last resort when I see these issues come up...and they do come up regularly. Thanks for posting back.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
June 9, 2011 at 7:34 am
When I double clicked to run the program nothing happened. Not sure if I got an incompatible version or what. Either way, the primary issue is resolved now. Thanks for the help!
June 9, 2011 at 7:37 am
Oh, it's a command line tool 😀
It's a good one to keep in your toolkit for troubleshooting these kinds of issues. Sometimes the network folks unintentionally get involved and break a working environment by blocking what they think are unused ports between two network segments.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
June 9, 2011 at 7:41 am
oh. 🙂 I guess reading the readme doc would have helped. (RTFM)
Anywho, to be more specific on what we did, I didn't have rights to outright delete the user's folder so we just renamed it. Does the same thing and probably a safer approach anyway.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply