Connect to SQL via Windows Authentication Over Vpn

connect to sql via windows authentication over vpn

Try creating a shortcut with:

runas /noprofile /netonly /user:domain\username ssms.exe

You may have to hard-code the path to ssms.exe. On modern versions, that's:

"C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

In a few locations it will look in SSMS like you are using your local credentials, but you should be able to verify on the remote server that your credentials are being passed, e.g.

SELECT SUSER_SNAME();

This of course depends on your requests being correctly routed to the destination SQL Server.

Windows Authentication over VPN for Windows Form Application

As you said computer is not part of the AD domain.
If your computer is not part of a domain, local user accounts are the only accounts you can use to log on. (logon to local system). And you can not be authorized to use resources of the domain with these local credentials. When your computer is part of a domain, you can either log on with a domain account or using a local user account. So the issue is unlikely VPN: usually VPN can be configured in such a way that client becomes part of remote subnetwork.
"user sitting at a computer in the subsidiary office can access the servers at the headquarters as if he were there, thanks to an OpenVPN tunnel connection between the two networks."
Assuming that network is configured as mentioned - when your computer will be added to AD domain you will be able to authenticate with integrated SQL Server authentication method. Otherwise only SQL Server authentication is available. If client machine is part of another domain then "trusted relationship" between two domains may be configured by administrator.
This issue is discussed here: Connect to domain SQL Server 2005 from non-domain machine

If client belongs to one AD domain and SQL Server instance runs using account from another domain then (I believe) the most secure solution is to establish trust relationship between domains - it's possible to grand access to users from another domain as discussed here "Cross Domain SQL Server Logins Using Windows Authentication"

Adding client machine to domain or establishing trust relationship is straightforward solution. But sometimes resolving the ticket requires too many approvals in large (multinational) companies. If user of client machine logged in to his machine with account from some other domain (or using local account) then you still can solve solution using impersonation - client process should authenticate/connect to SQL Server using account from domain of SQL Server. Find detailes: How do you do Impersonation in .NET?

For example, assume that SQL Server service logged in with account from Domain S and grands permissions only to users from Domain S. But client cannot login to local OS with account from Domain S by some reasons and login to OS with account from Domain C (maybe client mostly uses resources from domain C). Then WinForms process has security context of user's account from Domain C. This process should impersonate itself and switch security context to user from domain S and then connect to SQL Server using integrated authentication.

Not connecting to SQL Server over VPN

On a default instance, SQL Server listens on TCP/1433 by default. This can be changed. On a named instance, unless configured differently, SQL Server listens on a dynamic TCP port. What that means is should SQL Server discover that the port is in use, it will pick another TCP port. How clients usually find the right port in the case of a named instance is by talking to the SQL Server Listener Service/SQL Browser. That listens on UDP/1434 and cannot be changed. If you have a named instance, you can configure a static port and if you have a need to use Kerberos authentication/delegation, you should.

What you'll need to determine is what port your SQL Server is listening on. Then you'll need to get with your networking/security folks to determine if they allow communication to that port via VPN. If they are, as indicated, check your firewall settings. Some systems have multiple firewalls (my laptop is an example). If so, you'll need to check all the firewalls on your system.

If all of those are correct, verify the server doesn't have an IPSEC policy that restricts access to the SQL Server port via IP address. That also could result in you being blocked.

Remotely connect to SQL Server (ODBC) using Windows Authentication

Its some-thing not clear about when you are able to connect and not connect. Via office lan you able to connect VPN and sqlserver with window auth. But later means?.

Answer is When we use VPN, at the same time we have option to use window or sqlserver. But we direct connect without VPN, we are not in their lan and that's why we are not connect with window auth, we must connect with sqlserver mode only with permission user(s).

Build SQL Connection string with integrated security for use over VPN?

The VPN is a red herring. The issue is that the user is not logged in under the same domain as the SQL Server. The same issue would arise with any non-domain-joined PC, whether on a VPN or not.

1. You could join the PC to the domain. This is the best solution.

2. You could use the Legacy method - create matching usernames and passwords. However you then need to make sure they stay in sync.

3. You could use the NET USE command or NetUseAdd API to log in to the domain after connecting to the VPN.

See this question for more:

• This is the best one for you to use: SQL Server Integrated Security

• But see also this one: SQL Server Management Studio 2008 Runas user on different domain over VPN

---

Related Topics