6

I have a development server with an SQL 2008 EXPRESS instance running on it. The domain is called DEVAD, and the instance is enabled for Shared Memory, Named Pipes and TCP/IP.

My workstation PC is on a different domain called AD.

I have domain trusts set up between AD and DEVAD, and I can connect to the DEVAD instance using my AD credentials, via SSMS or .NET programs.

Unfortunately, the moment I connect to another network via a VPN using credentials for a different domain, I get the following error "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)".

My VPN connection has the option for "Use default gateway on remote network" unchecked for IPv4 and IPv6.

Any ideas as to how to prevent the VPN connection from breaking the trust?

Update: I have an additional VPN that I occasionally connect to, and I don't have issues connecting to SQL at the same time when this one is active.

I did some nslookup tests on the SQL host with various VPNs connected and not connected. My problem VPN ends up with a DNS timeout, which may mean that the DNS on the VPN is misconfigured and slurps up the request, rather than giving a Non-existent domain response (as my other VPN does), and letting the system get on with querying a DNS that does know about it.

Improve this question

3 Answers 3

Reset to default
4

I was also having this same issue and found the solution here:

http://social.technet.microsoft.com/forums/en-US/itprovistanetworking/thread/275599f0-6239-46a5-8245-50a5c13a2713/

You'll need to locate your VPN connections .pbk file.

You can find it here:

C:\Users\{WindowsLogin}\AppData\Roaming\Microsoft\Network\Connections\Pbk

Or if you have it set to allow all users to use the connection, you can find it here:

C:\ProgramData\Microsoft\Network\Connections\Pbk

Edit it with a text editor and find the line that says:

UseRasCredentials=1

Disable it by setting it to 0

UseRasCredentials=0
Improve this answer
1

Did you ever figure this out? I think I know what your problem is.

  1. It's possible that the problematic VPN is a full tunnel, and if so, it could be the case that even unchecking the option for "use default gateway on remote network" won't help. With full tunnel VPN, when you're VPN'd in, ALL of your traffic will be on the VPN network, whether you like it or not. You can test this by going to a site such as ipchicken.com before you connect to the VPN, and then refresh the page again after you're connected. If the IP changes, then you're on a full tunnel.

  2. How are you trying to connect to SQL Server? Are you using an application, or SQL Server Management Studio? If you can run the program from a command line, you may have luck using the runas windows command with the /netonly switch. It enables you to be logged into one domain but run a program as a different domain user. Like this:

    runas /user:MYDOMAIN\MYUSER /netonly "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe"

Replace the domain, username, and path of SQL Server Manamgent Studio with the appropriate values.

When it asks you for the password, type in the password for the domain user you enetered. It will not authenticate the user at this point. Then when you open SSMS, connect to the DB in question like you normally would, and if it can't connect with your normal creds it should try to use the ones you entered with the runas command.

Improve this answer
11
  • Haven't figured it out. The IPs are the same. Connections to the SQL server are all trusted. Via Management Studio, it's my credentials. But there's also the application(s) on IIS7. Each application pool has it's own user that also uses a trusted connection.
    – Reuben
    Mar 1, 2013 at 0:29
  • I assume the app pool users can still connect when you're VPN'd in, it is only you with SQL Server that can't access the DB while VPN'd in? Does running SSMS with /netonly work?
    – TTT
    Mar 5, 2013 at 19:01
  • It would appear that the app pool users can still connect when the VPN is active. It does not appear that Ssms for SQL Server 2012 has a /netonly option. ssms -? shows a dialog with -S, -d, -E, -U, -P, -nosplash, etc options. Specifying a username and password in the connection string is a work around, rather than a solution, and I'm after a solution for this one.
    – Reuben
    Mar 5, 2013 at 23:50
  • 1
    Sorry I wasn't clear about how to use the /netonly switch. It must be used in conjunction with the runas command. I updated my answer with better instructions.
    – TTT
    Mar 7, 2013 at 0:50
  • 1
    Ok, in that case, the vpn domain is taking precedent for some reason. I don't know if there's a way when you're logged into both to specify the precedent domain. Since you said you setup trusts, can you give your user in the vpn domain permission to sql server the same way your normal user has? That way you wouldn't have to use the runas /netonly command when vpn'd in.
    – TTT
    Mar 8, 2013 at 14:31
0

Let's say your workstation is on domain A and the domain of the server in the VPN is B

As the accepted answer alludes to, the issue is that Windows is trying to send "domain A" credentials to the "domain B" server, and "B" basically responds , "I don't know who 'A' is!" and denies the authentication request.

You can override this to send your "B" credentials, by using the Windows Credential Manager. In Credential Manager, under Windows Credentials, click "Add a Windows Credential". The address should be the SQL server (with port 1433 or whatever your SQL port is), and the credentials should be your "B domain" credentials (which you may be more familiar with as domain\user but user@domain is also valid)

Add a Windows Credential

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .