Openvpn – Log into Active Directory Domain over OpenVPN

active-directoryopenvpn

Is it possible for an OpenVPN client to log into a Windows AD domain on the server end of the tunnel?

In my set up, my OpenVPN server is running on a linux box joined to the domain and I'm using the centrifyDC package to authenticate OpenVPN client against the AD domain. Clients can access all the domain resources – they are prompted to provide their domain credentials when they attempt to access a resource.

That's all fine, but when a client accesses SQL Server via SSMS, when they select 'Windows Authentication' they can't independently supply their domain credentials; they need to be logged into the domain for this to work.

Ideally, I would be able to do this transparently when they log in to OpenVPN.

Best Answer

I haven't actually tried it, but assuming you run the OpenVPN client as a Windows service and set it to start automatically you should be able to logon to the domain from a client computer. I highly doubt computer Group Policy processing will work properly (since it's really, really picky about being able to communicate with a Domain Controller during boot) and depending only how long it takes for your OpenVPN client to establish the tunnel it may be possible for clients to attempt to logon "too soon". It should be possible, though, to do what you're looking for. (It would be fun to try this sometime.)

Related Solutions

Openvpn plugin openvpn-auth-ldap does not bind to Active Directory

I'v found it! I forgot f***g option client-cert-not-required in server config.

If somebody is interested, during my research what's happening I wrote external script to check user though LDAP. No openvpn-auth-ldap is needed, but you need to install ldap-utils.

In server config:

script-security 2
auth-user-pass-verify ldap-check-user.sh via-env

ldap-check-user.sh:

#!/bin/bash

bind_dn="cn=<user>,cn=Users,dc=domain,dc=com"
bind_pass="<password>"
host=rserver
port=389

dn=`ldapsearch -x -D "$bind_dn" -w $bind_pass -h $host -p $port -LLL -s sub \
-b "cn=Users,dc=radix-tools" "(&(objectCategory=person)(objectClass=user)(sAMAccountName=$username))" "dn" | cut -d':' -f 2`

if [ $? != 0 ]; then
        echo "Error: user $username not found."
        exit 1
fi

ldapsearch -x -D "$dn" -w $password -h $host -p $port -LLL -s sub \
-b "cn=Users,dc=domain,dc=com" "(&(objectCategory=person)(objectClass=user)(sAMAccountName=$username))" > /dev/null 2>&1

if [ $? != 0 ]; then
        echo "Error: password for $username is incorrect."
        exit 1
fi

exit 0

Active Directory – Should It Be Exposed to the Public Internet?

I'm posting this as answer mainly because everyone has their own "educated opinion" based on experience, 3rd party info, hearsay, and tribal knowledge within IT, but this is more a list of citations and readings "directly" from Microsoft. I used quotes because I'm sure they don't properly filter all opinions made by their employees, but this should prove helpful nonetheless if you are after authoritative references direct from Microsoft.

BTW, I also think it is VERY EASY to say DOMAIN CONTROLLER == ACTIVE DIRECTORY, which isn't quite the case. AD FS proxies and other means (forms based auth for OWA, EAS, etc.) offer a way to "expose" AD itself to the web to allow clients to at least attempt to authenticate via AD without exposing the DCs themselves. Go on someone's OWA site and attempt to login and AD will get the request for authentication on a backend DC, so AD is technically "exposed"...but is secured via SSL and proxied through an Exchange server.

Citation #1

Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines

Before you go "Azure isn't AD"...you CAN deploy ADDS on an Azure VM.

But to quote the relevant bits:

Never expose STSs directly to the Internet.

As a security best practice, place STS instances behind a firewall and connect them to your corporate network to prevent exposure to the Internet. This is important because the STS role issues security tokens. As a result, they should be treated with the same level of protection as a domain controller. If an STS is compromised, malicious users have the ability to issue access tokens potentially containing claims of their choosing to relying party applications and other STSs in trusting organizations.

ergo...don't expose domain controllers directly to the internet.

Citation #2

Active Directory - The UnicodePwd Mystery of AD LDS

Exposing a domain controller to the Internet is normally a bad practice, whether that exposure comes directly from the production environment or through a perimeter network. The natural alternative is to place a Windows Server 2008 server with Active Directory Lightweight Directory Services (AD LDS) role running in the perimeter network.

Citation #3 - not from MS...but useful still in looking ahead

Active Directory-as-a-Service? Azure, Intune hinting at a cloud-hosted AD future

In the end, there is no great "short" answer which meets the goals of ridding the office of the AD server in exchange for an Azure alternative. While Microsoft is being complacent in allowing customers to host Active Directory Domain Services on Server 2012 and 2008 R2 boxes in Azure, their usefulness is only as good as the VPN connectivity you can muster for your staff. DirectAccess, while a very promising technology, has its hands tied due to its own unfortunate limitations.

Citation #4

Deploy AD DS or AD FS and Office 365 with single sign-on and Windows Azure Virtual Machines

Domain controllers and AD FS servers should never be exposed directly to the Internet and should only be reachable through VPN