Cannot connect to SQL Server using TCP/IP

Last Post 07 Jul 2004 01:35 PM by ebalch24. 7 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
ebalch24
New Member
New Member

--
06 Jul 2004 12:30 PM
When I came into work this morning I found none of my database users could connect to our application consisting of a MS Access front-end that backends to some SQL Server tables (not an Access project). They were getting the following error:

Connection failed:
SQLState: '28000'
SQL Server Error: 18456
[Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

I was able to get around the problem by changing the dsn on each client workstation to use Named pipes instead of TCP/IP. Our SQL Server is configured to use both TCP/IP and Named pipes connections. However, when I do a netstat -a on my SQL Server I don't see that it is listening at all on 1433....

The only thing that I can think of that has changed in the last few days is that late on Friday my coworker patched the server that is housing the .mdb file for the database. She applied serveral security patches, but the only one that seems to be related is MS04-003. However, I haven't found any known issues with this patch or have seen any posts about other people with this problem since applying the patch...

Any suggestions would be greatly appreciated!

Elizabeth
ebalch24
New Member
New Member

--
06 Jul 2004 01:06 PM
Yes, I can ping the box and all connectivity setting are set correctly on the client and server...
VenteDBA
New Member
New Member

--
06 Jul 2004 01:07 PM
Hello

I guess I start by trying to ping the box -- if ping is allowed under your security. If that works, I would check the connectivity on the server to determine what port it's listening on and make sure the tcpip settings for each client is set appropriately
ebalch24
New Member
New Member

--
06 Jul 2004 02:44 PM
Nope, nothing alarming in the log.

It shows my SQL Server is listening on 1433 and is configured for TCP, Shared Memory, and Named Pipes. Also, there is this entry:

SQL server listening on 127.0.0.1: 1433.
ebalch24
New Member
New Member

--
06 Jul 2004 04:18 PM
Okay... Makes sense.

I'm still getting the same error as noted above. I have also found that my DTS jobs scheduled to run nightly are also failing with the same error. However, they did run successfully one time AFTER my coworker did her patching... so maybe that is not related after all.
ebalch24
New Member
New Member

--
07 Jul 2004 05:09 AM
No, nothing to indicate any problem.
ebalch24
New Member
New Member

--
07 Jul 2004 01:35 PM
Yes.
ebalch24
New Member
New Member

--
08 Jul 2004 12:09 PM
The fix to this issue turned out to be that the Kerberos Key Distribution Center service on one of my three DCs was disabled!! I am still trying to figure out how this happened, but as soon as I started it back up, things started working again.

Additionally, I still don't understand why my clients were only looking to this single DC for Kerberos tickets. I would think that if they couldn't get a ticket, they would look to one of the other two DC whose KDC service was running...

Anyhow, that was the solution, but if anyone has any thoughts on my remaining questions I would be very grateful for them..
You are not authorized to post a reply.

Acceptable Use Policy