September 19, 2005 at 10:56 am
Hi All,
I need to access databases in another domain via SQL Server client tool. When trying to register the SQL Server using an SQL Server login, it failed with promtping below messages
SQL Server does not exist or access denied.
ConnectionOpen (Connect())
Could some there advise me what I should do on this?
Thanks a lot!
Yichang
September 19, 2005 at 11:29 am
What's the authentication mode?
Did you try the sa account?
Did you check the WINDOW'S application even log?
September 19, 2005 at 11:29 am
First, do you have an account on the distant SQL Server?
Second, is that SQL Server instance using Mixed Mode or Windows Only Authentication?
Third, how are you trying to log in?
If the distant system is using Windows Only or your account is Windows Only, then there needs to be a common domain controller to authenticate your login.
Can your computer 'reach' the distant computer? Can you PING it or TELNET to it?
-SQLBill
September 19, 2005 at 12:17 pm
Thanks for your replies. Here is more info regarding the problem:
1. I created a login in the remote SQL Server.
2. The remote server is in Mixed Mode.
3. I tried to register the remote SQL Server from SQL Server client.
4. Unable to ping the remote server (in a different domain).
5. Registering with sa returned the same eroor message.
Yichang
September 20, 2005 at 6:20 am
<quote>Unable to ping the remote server (in a different domain).<end quote>
Well, there you go. You can't reach that domain and need to solve that issue.
Did you ping by the server name and then try the IP address? There might be an issue with 'name resolution'. If you can ping by IP address, use that to register the server.
Is there a firewall blocking you? SQL Server's default port is 1433 and some firewalls are set up to block that port. You either need the port openned or your IP added to the access.
-SQLBill
September 20, 2005 at 8:18 am
Also you may need to talk to the network gods , have them setup a trusted domain group (this have to be setup on both domains, and trusted to each other), and make you part of that group.
Then either grant permission to that group in the other server with the appropiated permission on the database(s), or use a SQL userid/pw that has been setup on the other box.
September 20, 2005 at 10:37 am
I'd first talk to the network ?gods? about 'firewalls' and 'ports' before anything like trusted domains. If you're using SQL authentication then 'trusts' are just a wste of time and resources.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
September 20, 2005 at 3:37 pm
Hi,
Ask them network admins to open port 1433 and 1434 (the later one is helpful for instances)
But the very first thing that I will do is to use Fully Qualified Domain Name as myserver.mydomain.mycompany.com or domainname\servername when pinging or registering the sever. Once you are able to ping the machine then just add an entry to the Client Network Utility with some easy alias. Also you may add a suffix with the domain name in the advanced properties for TCP/IP protocol properties. Or ignore all of above and use IP address when connecting to the server.
If you can not ping by IP then it is a Firewall issue. If you can ping by IP but can not connect to SQL Server by IP it is still Firewall issue, tell them to open 1433 or whatever port SQL Server you are trying to connect to is using. If it is a named instance or MSDE then the port probably will not be 1433, check in Server Network Utility
Yelena
Regards,Yelena Varsha
September 20, 2005 at 4:12 pm
Just to clarify the ports ... TCP 1433 & UDP 1434 are needed at a minimum for SQL authentication. If you are going to use Windows Authentication with (ughh ...) some implementation of 'trust' then there are about a dozen more ports that need to be opened up (a combinatino of TCP and UDP) and a registry 'hack' to limit the range of RPC ports used by the OS on each server (otherwise random ones are chosen above 124 if memory serves correctly). I know because I once had a dozen servers behind a firewall where the default rule set was 'deny all'.
Also, if the firewall is the real issue, do not bother searching MS for ports to open up. Been there, done that. 99% of the documentation when referring to ports indicat3s which ports to 'firewall off' (close) to secure your site.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
September 20, 2005 at 4:33 pm
Rudy,
TCP 1433 is a default port for a default instance, a DBA can easily change that in Server Network Utility. Additional Instances including MSDE will install on different ports.
Yichang, You network admin can search a firewall log for you when you give him SQL Server IP, your client IP and the time the connection attempt was made. He will tell you what ports are "dropped". Rudy can probably tell you more about that
Yelena
Regards,Yelena Varsha
September 20, 2005 at 5:44 pm
You should have an alias for the remote server set up on your Client Network Utility. I would use the IP address is the ServerName text box.
September 21, 2005 at 6:52 am
<quote>If you can ping by IP but can not connect to SQL Server by IP it is still Firewall issue<end quote>
Not so. If you can use IP but not the computer name, then it is a DNS issue. The DNS server is not set up for NAME RESOLUTION.
-SQLBill
September 21, 2005 at 9:41 am
Hi SQLBill,
not the "Not So" but "Yes so" I say:
<quote>If you can ping by IP but can not connect to SQL Server by IP it is still Firewall issue<end quote>
I say "can not connect to SQL Server by IP" I did not say "by computer name" What I mean that Ping ports usually open whatever they are, but 1433 is usually closed. I have this particular case every week with applications and SQL Servers I support. When someone tells me he can ping but can not connect to SQL server by IP then this is the very first indication of the firewall and I call our Network support who opens 1433 and then everything works.
Yelena
Regards,Yelena Varsha
September 21, 2005 at 10:22 am
Yelena and SQLBill, you're both right (although it seems contradictory). The contradiction is in how your individual networks are configured to handle ICMP traffic (ping).
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
September 21, 2005 at 12:03 pm
Yelena is actually correct. I misread the post (even though I quoted it). What I meant was, if you can PING by IP, then it's probably Name Resolution problems and try to connect via IP vice the name. But that's not what Yelena said.....so I was mistaken and apologize. My 'not so' was wrong.
-SQLBill
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply