Openvpn – AD Integrated OpenVPN Server User Cannot Connect to MS SQL Server

active-directoryopenvpnsql-server-2008-r2

I have a Windows 2008 R2 Domain/Forest functional level environment with an OpenVPN Access Server (v1.8.4.400) that is Active Directory integrated and working smoothly. I've been working with our DBA to streamline the permissions process and we have decided that we want to implement access to the various MS SQL Databases through AD User account and/or AD Group.

We created a test user: dbtest@domain.local and assigned the account through SQL Management Studio to the proper role using DOMAIN\dbtest.

We then connected to the OpenVPN box, authenticated successfully but when we try to connect to the SQL db we receive the following error:

UPDATED (Direct from Error Logs)

12/13/2013 08:00:02,Logon,Unknown,Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 10.0.160.201]
12/13/2013 08:00:02,Logon,Unknown,Error: 18452<c/> Severity: 14<c/> State: 1.
12/13/2013 08:00:02,Logon,Unknown,SSPI handshake failed with error code 0x8009030c<c/> state 14 while establishing a connection with integrated security; the connection has been cclosed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed   [CLIENT: 10.0.160.201]
12/13/2013 08:00:02,Logon,Unknown,Error: 17806<c/> Severity: 20<c/> State: 14.

Is there anyway to make this work knowing that the remote machines connecting through the VPN are not joined to the domain? The accounts they are connecting with are domain accounts.

Thanks in advance!

Best Answer

We have used OpenVPN-AS server successfully with SQL Server using AD authentication for several years. I suspect it may have more to do with the client system on the other end of the OpenVPN connection -- is the machine joined to the same domain the VPN server is on? If not, is it joined to a different domain, and is there a trust relationship between the two? If it's not joined to any domain you will still need to add the domain info when connecting to SSMS or whatever client or program you're attempting to connect through, even if you've created the same username on the client, as it will be trying to pass COMPUTERNAME\dbtest and not DOMAIN\dbtest by default.

Update re: comments

The OpenVPN-AS server shouldn't be modifying how the domain info is passed -- I suggest a quick Wireshark capture at either end, then examining the stream with the SQL authentication attempt. If the application uses SSL this may be more difficult but you may still be able to see the user details being passed. Also, if you have the source to the application, check that it's set to use Integrated Security=SSPI instead of userid and password in the connection string. Depending on the SQL Server version, there's also a Trusted_Connection=True command you can use in the connection string. This site is a great resource for building them.

Lastly, if the app is connecting via ODBC instead of the native .NET connector, you can create a trace log via the Data Sources (ODBC) icon in the Control Panel > Administrative Tools area.

Update 2

You may need to have your SQL Server set to mixed authentication mode. But I'd still run the Wireshark capture ASAP to look more closely at what's getting passed.

Related Topic