RADIUS vs LDAP for AD authentication for OpenVPN

[Rob Pomeroy]

@BloodyIron:

Is there any good reason to use RADIUS instead of LDAP in this particular regard?

You might find that RADIUS suits you better if you're allowing VPN connections from machines that have never joined your network - especially if you're using Network Access Protection or other granular remote access policies.  You may also want to use it if you've deployed RADIUS for other systems (non Microsoft routers, for example).  Combine all your network authentication needs in one place.

Personally I'd go for LDAP/Active Directory (which is what I'm doing right now).  Simple set-up.

[BloodyIron]

When using LDAP or RADIUS for authentication with openVPN, are users prompted for login/password when connecting? We use another openVPN implementation where it doesn't, and I'm not familiar with the expected behavior with LDAP/RADIUS.

Thanks for the info :)

@Rob:

@BloodyIron:

Is there any good reason to use RADIUS instead of LDAP in this particular regard?

You might find that RADIUS suits you better if you're allowing VPN connections from machines that have never joined your network - especially if you're using Network Access Protection or other granular remote access policies.  You may also want to use it if you've deployed RADIUS for other systems (non Microsoft routers, for example).  Combine all your network authentication needs in one place.

Personally I'd go for LDAP/Active Directory (which is what I'm doing right now).  Simple set-up.

[Rob Pomeroy]

@BloodyIron:

When using LDAP or RADIUS for authentication with openVPN, are users prompted for login/password when connecting?

I'm in a proof of concept phase at the moment, so I'm not sure how much this can be tweaked.  I can say for sure that when firing up the OpenVPN client, as I have configured it on a Windows 7 machine, there's a username/password prompt.  The username doesn't require a domain part.  There's probably a configuration option to pre-fill the username?

Ideally I'd like to aim for what the native Windows VPN client is capable of: pass through the currently logged-on user's domain credentials.  Not sure if that's even possible though - I suspect Kerberos credentials are used in that instance.

Then after that, I'll be investigating whether it's possible to establish the VPN connection before (and as part of) log on to the computer.  Single sign on effectively.  I'm sure there will be documentation about that - just haven't got to it yet.

[Garfield000]

@Rob:

@BloodyIron:

Is there any good reason to use RADIUS instead of LDAP in this particular regard?

You might find that RADIUS suits you better if you're allowing VPN connections from machines that have never joined your network - especially if you're using Network Access Protection or other granular remote access policies.  You may also want to use it if you've deployed RADIUS for other systems (non Microsoft routers, for example).  Combine all your network authentication needs in one place.

Personally I'd go for LDAP/Active Directory (which is what I'm doing right now).  Simple set-up.

Hi Rob,

You say it's a simple set-up.
Can you tell me what steps to follow? Since everything I tried doesn't work.

I'm trying to setup an vpn-connection via openvpn that authenticates by active directory.
It works already when not authenticating by active directory.
I believe this is what you are talking about.

[Rob Pomeroy]

Sure.  From the OpenVPN: Server page, I clicked the "Wizards" and followed that through.  I do recall that the LDAP configuration wasn't entirely intuitive.  So here are a few settings that work for me, with a Windows 2008 domain controller:

• Protocol version: 3

• Search scope: entire subtree

• BaseDN: DC=Our domain,DC=local

• Authentication containers: OU=Our users,DC=Our domain,DC=local

• Bind credentials: a dedicated "domain user" account

• User naming attribute: samAccountName

• Group naming attribute: cn

• Group member attribute: memberOf

Have you managed to get authentication working?  Are you on a recent release of pfSense?

[Garfield000]

authentication is working. (Diagnostics -> Authentication -> Test)

2.1-RELEASE (i386)
built on Wed Sep 11 18:16:22 EDT 2013
FreeBSD 8.3-RELEASE-p11

[Rob Pomeroy]

Okay, good.

Next, these are some of the settings I needed on my OpenVPN configuration:

• Server mode: Remote Access (User Auth)

• Backend for auth: obviously the LDAP connection configured earlier

• Protocol: UDP

• Device mode: tun

• Interface: the WAN interface

• Local port: 1194

• TLS auth: enabled; certificate shown in the next box

• Peer certificate auth, etc.: the one configured by the wizard

• IPv4 tunnel network: here I used a network that does not exist on the internal network.  Internally, we use 10.12.0.0/16, so here I entered 192.168.20.0/24.  Doesn't really matter what you use as long as it's from a private range and doesn't overlap any other network.

• Redirect gateway: disabled (no check mark)

• IPv4 local network: 10.12.0.0/16, see above

• Dynamic IP: checked

• Address pool: checked

• DNS/NTP stuff: everything here was from the LAN side

• NetBIOS: not checked

[Garfield000]

Thanks for the help
Now it works !!

[Rob Pomeroy]

Ah, brilliant!

[Garfield000]

Oh, now the next problem…

when I have a VPN-connection and I try to go to our server I can't use its name, I have to use the IP-adress.
At the Openvpn-server-configuration on PfSense I checked "Provide a DNS server list to clients" and I placed our internal DNS-server in that list.

[Rob Pomeroy]

Do you have an "allow all" rule on the OpenVPN network?  (You probably do, if you used the wizard.)  Sounds like DNS traffic isn't being allowed through the tunnel for some reason.

You could possibly enable NetBIOS over TCP/IP in the OpenVPN server settings.  That would enable the remote computer to fall back to WINS if DNS isn't working.  I think I usually choose "H-node", but experiment perhaps.  You can also switch on "Redirect Gateway", if you prefer all traffic to go via your LAN's gateway while the tunnel's established.

Mind you, if DNS isn't working, you'll probably have a lot of other problems too.

[Garfield000]

It looks it has something to do with dns-suffix's

when I set the dns-suffix in the network-connection settings, it works.
or when i go to \server.domain.local instead of \server it works.

Is there are way this is not necessary?

[Rob Pomeroy]

Ah okay.  Yeah, your remote workstation does need to know the full domain somehow.  Sounds like you've cracked it?

[Garfield000]

Looks like I did  :)
I did set the "Provide a default domain name to clients"
but there I only placed our domain, not domain.local

Now it's working. Thanks a lot !!

[Rob Pomeroy]

Cool.  Good work.

[BloodyIron]

Adding to the original topic of this thread, my testing so far is very successful with using LDAP to auth against AD. I haven't yet found a reason to use RADIUS over LDAP, and RADIUS seems like added work.

I'll try to post more information as it comes.

[Rob Pomeroy]

You'd probably want RADIUS for granular NAP/VPN quarantine, I'd think.

[BloodyIron]

Where I'm stuck now is figuring out how to get pfSense to only allow members of a domain group to successfully connect, not just rely on the cert.

@Rob:

You'd probably want RADIUS for granular NAP/VPN quarantine, I'd think.

[Rob Pomeroy]

Surely you'd control that through the remote dial-in permission in AD, which OpenVPN has to honour?

[BloodyIron]

From what I'm seeing using LDAP to auth in pfsense just does an LDAP query against the domain. I can't yet get it to query against a domain group for members, which is what I want. Whenever I adjust the scope of the query to a specific group it seems to not authorize the user under diagnostics -> authentication.

@Rob:

Surely you'd control that through the remote dial-in permission in AD, which OpenVPN has to honour?