94

I am trying to connect to a remote SQL Server on a VPN in a different domain. When I enter the Server name on the SQL Server and choose Additional Connection Parameters to add some extra stuff needed by my school:

Integrated Security=SSPI; User ID=DOMAIN\username; Password=Password

I get the following error:

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Improve this question
3
  • The only problem with the Windows Credential Manager solution is if you have a whole lot of database you support you have to have an entry for each one and update them each time you have to update your domain passwords. For some people that could be every 30 - 60 days. – smehaffie Jun 13 '17 at 14:51
  • This post is somewhat related. – RBT Jun 30 '17 at 7:06
  • @smehaffie you can easily use scripting and the "cmdkey /add" command to maintain your passwords - it also updates. – Mister Magoo Aug 28 '17 at 9:02
90

You are attempting to pass Windows credentials in plain text from the connection string of an application. This simply isn't how Windows authentication works, and largely defeats the purpose.

You also can't just create the same username with the same password in your own domain, and expect that to magically work. Domain name is still part of the validation - your machine either has to be part of the domain, or the domain your machine is in must be trusted by the school's domain.

The only workaround I know of is for SSMS (and it works for other apps too, like Plan Explorer and SentryOne), and that's the runas /netonly trick described in this answer. This fools Windows into launching SSMS as the login you specify, rather than your own (this isn't something you can set in the Connection properties dialog of SSMS, it's how you need to launch SSMS from the command line or a shortcut):

runas /netonly /user:domain\username "C:\path_to\ssms.exe"

This will prompt you for your password in the remote domain. It will look like it is using your local Windows credentials, but it is not.

This should work with any application, including Visual Studio.

So your options are:

  • have the university allow you to join your machine to the domain
  • have the university add your domain as a trusted domain
  • have a jump box inside the VPN that allows you to RDP and use tools connecting directly to the SQL Server machine
  • use SQL authentication
  • use the runas /netonly trick with SSMS or Visual Studio
Improve this answer
4
  • Is there a way to mimic this behaviour without the command prompt? – Gilles Lesire Aug 29 '17 at 11:08
  • 1
    @Gilles you can make a batch file and double-click the batch file, or you could use that string and create a shortcut maybe – Aaron Bertrand Aug 29 '17 at 16:18
  • See serverfault.com/q/784616/58957 if you are tired of typing the password every time you run runas /netonly or need to use it from a batch script. – Nickolay Jan 23 '20 at 22:13
  • This however does NOT work if the source system is Win10 (maybe 8.1 or 7 would apply too), the target system is Windows Server 2003R2 (have to run such legacy) with SQL Server 2005 as target application, and possibly the fact that source system is in a domain also played a role. The problem is that WS2003 reports successful login, while SQL server reports untrusted connection. Some legacy issue I admit, but should others come by this answer, expect problems with legacy OSes and software that relies on some internal credential transfer. – Vesper Jun 8 at 8:36
134
+200

There is another way, which I now use in preference to the runas /netonly method.

You can add the credentials to your profile in Windows using the Credential Manager found in the Windows control panel.

  1. Open Credential Manager

  2. Click "Add A Windows Credential"

  3. Populate the "internet or network address" field with the name and port number of the SQL instance you wish to store credentials for.

    Example: UniServer:1433 (1433 is the default port, you may need a different port, especially if you are connecting to a named instance)

  4. Populate the "User Name" (don't forget to include the domain e.g. MYDOMAIN\MYUSER)

  5. Populate the "Password"

  6. Click OK

If you have the server name, port and login details correct, you should now be able to use Windows Authentication from most client tools, SSMS, Excel, whatever. They will all use the stored credentials.

Tip: Sometimes you need to use the FQN for the server when adding the credentials. e.g. UniServer.UniDomain.org:1433, it all depends on your network specifics.

Here is a quick demo of the method : http://youtu.be/WiVBPsqB9b4

It is a screen grab of me attempting (and failing) to connect to a SQL Server running in a VM from my desktop, then adding the required credentials and trying again - successfully.

Tip: use the "cmdkey /add" command to script creating and updating stored credentials.

Improve this answer
11
  • Interesting! It seems to depend on what your client machine thinks the remote machine is called rather than what it might actually be called. I've put an invented entry ("verysillytest.mwardm") in my host file for the IP address (as those of us accessing from outside of domains are wont to do) and set up the credential in the name "verysillytest.mwardm:1433". I can then connect happily (from a little app called Query Express) using either the hostname or the IP address. – mwardm Oct 28 '16 at 9:04
  • @mwardm yes, that's why I recommend using ping or nslookup as it will tell you the name exactly as you need to use it, including upper / lower case specifics. – Mister Magoo Oct 28 '16 at 9:28
  • 2
    Awesome, it works! I just wonder - is it supposed to work like that or is it a bug or a design fail on the side of SQL Server? Microsoft or people from Microsoft advertise everywhere that you have to have a domain connected machine, otherwise there is no way to connect to SQL Server which is set up to accept only the domain credentials. – David Ferenczy Rogožan Nov 16 '16 at 18:03
  • 1
    BTW I would say that this answer should be marked as accepted, since it seems to be a real solution and the other answer is more like a workaround. – David Ferenczy Rogožan Nov 16 '16 at 18:36
  • 2
    Just a minor thing to be aware of. You don't put the instance name in the Credential Manager. Initially I tried to add it like server\SQL2019,[port]. This didn't work. It just needs [servername]:[port] – user1751825 Jun 18 '20 at 14:25

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