Trying to connect using SQL Server Management Studio 2012 on a Windows 8.1 Client computer from outside the cluster's domain.

Cluster is a two node Virtual Cluster made from Windows Server 2012 R2.

We can connect to the cluster from within the cluster's domain by using the Failover Cluster Virtual Network Name Account with SSMS running on another Virtual Computer from within the cluster's domain.

We have created a new Inbound Rule with port 1433 on each of the two nodes - but still don't understand how to connect to the SQL Instance from outside the domain.

  • 1
    mssqltips.com/sqlservertip/3250/… - you may also need to try connecting to the cluster's virtual IP address (or perhaps FQDN), because - depending on networking - name resolution might not work outside the domain. Is the cluster a default instance? Are you even sure it's running on port 1433? Can you ping the server by network name outside the domain? Can you telnet to the SQL Server port (or UDP 1434)? What is the actual error message you're getting? ("Trying to connect" could mean lots of things.) Jan 22, 2015 at 19:45
  • After you figure out the connectivity piece, use SQL authentication from untrusted domains.
    – Dan Guzman
    Jan 23, 2015 at 12:46

2 Answers 2


If you are connecting from outside the domain you can either

1) Use SQL authentication to login. If you have enabled mixed mode during the install you will have an sa account and you can create a sql login for yourself

2) There are other tricks, such as enabling named pipes and then authenticating against the IPC$ share with your domain account and then you can login using np:ipaddress in SSMS. But beware it is a bit slow and most people don't want named pipes enabled on a production system.

But if you are connecting from outside the domain the easiest way is use SQL authentication.


I often run into this issue in environments where we have domains with no trusts between them. The issue with using SQL Auth is that by default it's in clear text (as noted in comments up to 2005), so your passwords can be easily sniffed out and it doesn't pass a lot of compliance requirements.

I made a shortcut which executes SSMS as a different user. When you log in, it'll show your current user in the user drop down but it'll actually authenticate with the user you put in. Here is a link for SSMS 2012 and it's default location:

C:\Windows\System32\runas.exe /netonly /user:DOMAIN\USERNAME "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"

It will then prompt you for a password and open up SSMS.

Change the path to \100\Tools\Binn for 2008. If you need to find the SSMS path, just go to the SSMS icon, right click, properties, and check the path. You can use the runas.exe to launch other apps too, such as profiler. There is a sysinternals app that let's you run remote commands but it might be too much for what you're asking for. This is simpler.

  • 1
    SQL authentication is NOT in clear text since SQL Server 2005. Versions from 2005 to 2008R2 use RC4 to encrypt the password in the TDS packets. SQL 2012 and newer use a different encryption algorithm, I don't know which one. Jan 23, 2015 at 12:10
  • Good point, my testing was on 2005 for clear text. Microsoft highly recommends dumping RC4 though hence why they must have changed it in 2012. Jan 26, 2015 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.