Connecting to the Sql server using NT authentication
-
I have been trying to connect to the server using NT authentication but I keep getting the error "SQL Server does not exist or access denied." Even the connections that worked before don't seem to work now and I ahve tried giving all kinds of access and permissions to the login. Please let me know what's wrong... I need to get this working!
-
Can you connect to a different SQL Server using Windows authentication? Are others experiencing the same issue as you are? Can you connect to the SQL Server using a SQL Server login?
K. Brian Kelley
@kbriankelley -
Hi,
has the nt-user a valid login-id and user id for his standard database?
Is the sql server configured for integrated security?
Does the client use the same network library (tcp/ip, named pipes, multiprotocol) as the server?
karl
Best regards
karl -
Have you checked the Server Network Utility? (C:\Program Files\Microsoft SQL Server\80\Tools\Binn\svrnetcn.exe) Make sure that TCP/IP is enabled, at the very least. You may want Named Pipes as well. I have seen instances where a service pack or something else disabled the protocol. If it is enabled you might want to disable is, stop SQL Server, re-enable the protocol, then restart SQL Server.
Anything showing in your error logs to indicate that SQL Server is no longer listening or that the port has changed?
HTH
Don
-
like Karl said, make sure that the Windows NT User (or group that the user is in) is setup with a Login and then make sure that the login has access to the database that you are trying to connect to.
How/what are you using to connect to the db? Are you getting the msg when connecting to the server or a db?
I've also had to change the order of TCP/IP and NamedPipes to be able to login before.
-
I have experienced this problem before as well, and the fix was not very easy. I generally found that re-installing MDAC fixed the problem; however, MDAC is not easy to uninstall. I had to go into the Registry editor to HKEY_CLASSES_ROOT and remove all keys that began with "ADO.Connect", "ADODB.", and "ADOR." (you will probably find several versions of each class). Then I had re-installed the latest version of MDAC (version 2.8), and the connections have worked.
-
I had one today like this one. For some unknown reason, if the user creates an alias to the server using the Client Network Utility on their machine, they are able to connect using Windows Authentication. Otherwise, they are unable to connect. We're running only TCP/IP on the servers. The user actually had this situation with 2 servers this morning.
It's possible that the registry has some old entries for the servers. Though, I've only seen that issue with MSDE. I had to uninstall / reinstall and then I discovered some network library entries for some Named Pipes and TCP/IP protocols that I didn't want running on my laptop had persisted in the registry which I then deleted and was then able to use Shared Memory.
-
Another thing to check is DNS resolution, in both the ODBC call and and the client level.
From a cmd line ping %ServerName% - does it successfully resolve?
If not "ipconfig /flushdns" and try again - if it does not then ping by IP address - if it does resolve then something is wrong with the DNS. That needs to be fixed.
The temp workaround is on the ODBC call edit the "Client Configuration" button and put the IP in for the servername.
Just my $0.02.
----------------
Jim P.A little bit of this and a little byte of that can cause bloatware.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply