CODEWITHSUNDEEP
c#winformsvpnwindows-authentication
Wade73
Wade73

Reputation: 4509

Windows Authentication over VPN for Windows Form Application

I created a WinForms app for a client, that uses integrated security to connect to SQL Server. The client complained that they were getting the error - "Cannot generate SSPI context." It turns out that they were trying to connect to the WinForms app through a VPN on a computer that was not part of the domain. If I change the connection string to use a SQL user, the program works, but I lose the information I could get from the Windows Identity. My question is, will I be able to make this setup work correctly or do I need to find some other way to make the program work over VPN. Thanks.

Wade

Upvotes: 0

Views: 1073

Answers (1)

Vlad
Vlad

Reputation: 2165

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.

Upvotes: 5

Related Questions