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.

  • This post is somewhat related.
    – RBT
    Commented Jun 30, 2017 at 7:06

2 Answers 2


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
  • 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
    Commented Jan 23, 2020 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
    Commented Jun 8, 2021 at 8:36
  • Thanks, the runas option worked for me on my nondomain workstation
    – Taavi
    Commented Sep 1, 2021 at 10:55
  • I was having the same issue so I opened Visual Studio with run as different domain user & kept connection string with Integrated Scurity = True so it took correct credentials & execute the program successfully. But that program was writing a file & as a result it created a user with Username.DomainName where it wrote the output file, but then I didn't have access to that folder.
    – Harshil
    Commented Jul 6, 2022 at 12:39

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.

  • 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
    Commented Oct 28, 2016 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. Commented Oct 28, 2016 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. Commented Nov 16, 2016 at 18:03
  • 3
    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] Commented Jun 18, 2020 at 14:25
  • 2
    On my machine, SSMS returns "Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. (Microsoft SQL Server, Error: 18452)". This error doesn't appear when using \netonly
    – Stevoisiak
    Commented Aug 17, 2021 at 16:39

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