RADIUS vs LDAP for AD authentication for OpenVPN
-
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 -
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
-
-
Thanks for the help
Now it works !! -
Ah, brilliant!
-
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. -
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.
-
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?
-
Ah okay. Yeah, your remote workstation does need to know the full domain somehow. Sounds like you've cracked it?
-
Looks like I did :)
I did set the "Provide a default domain name to clients"
but there I only placed our domain, not domain.localNow it's working. Thanks a lot !!
-
Cool. Good work.
-
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.
-
You'd probably want RADIUS for granular NAP/VPN quarantine, I'd think.
-
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.
-
Surely you'd control that through the remote dial-in permission in AD, which OpenVPN has to honour?
-
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?
-
Yeah, I saw similar. But if you use the Remote Dial-In permission, you'll achieve the result you desire. You can even use Group Policy to apply that to the group you have in mind.
-
I don't see how an LDAP query can pull that permission info. Additionally we're running a SAMBA4 AD so I'm uncertain of the relevance of dial-in permission for this implementation. I also don't know how GPO would affect an LDAP query?
@Rob:
Yeah, I saw similar. But if you use the Remote Dial-In permission, you'll achieve the result you desire. You can even use Group Policy to apply that to the group you have in mind.
-
Gotcha. My bad. I assumed you were using AD. I guess you'll need to debug your LDAP query problem.
-
It is Active Directory. The LDAP queries against this would behave the same as if against a Microsoft Server Active Directory. I have a test user that can authenticate without being granted the dial-in permissions, and in past LDAP query setups I haven't seen such parameters of users passed in queries (but I could be wrong).
Do you have any idea why my queries to specific groups may be failing? It could be syntax, but online documentation is very unhelpful for pfsense, in this particular topic :/
@Rob:
Gotcha. My bad. I assumed you were using AD. I guess you'll need to debug your LDAP query problem.
-
Okay, let me take a step back. I might be wrong about the dial-in permission. I'd taken it as a given but never actually tested.
I have not tried to use LDAP queries against a security group, but they definitely work for me against an OU (not a container mind you). Have you tried a specific OU? Eg: OU=VPN Users,DC=YourDomain,DC=local