RADIUS vs LDAP for AD authentication for OpenVPN
-
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
-
No I haven't against a specific OU. My understanding though is that in that case I would have to create duplicate accounts, which is not what I'm looking for. We have multiple sites so we organize accounts based on location (like, city). So if I were to use an OU I would have to either move accounts into a VPN OU, or duplicate accounts.
Or, I'm misunderstanding. Am I? I thought groups were CNs.
@Rob:
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
-
You can use multiple DNs separated by semi-colons, so you could have one OU for each site.
-
Be that as it may, I want more granular control. I don't want everyone at a site to inherently have VPN access. I follow the mantra of only needed access. As such I want access delegated by group membership (and having their own cert too of course).
How can I get LDAP auth to query against a specific group?
@Rob:
You can use multiple DNs separated by semi-colons, so you could have one OU for each site.
-
Okay so I think I've found how to configure the LDAP authentication to check against domain groups (or a single group). I had to dig around and found this bug report ( https://redmine.pfsense.org/issues/1009 ) If you read #7 in the list the person refers to this thread ( https://forum.pfsense.org/index.php?topic=48961.0 ).
So to test I've been using Diagnostics -> Authentication. I have a test account, and tested if auth failed when in and out of the group. Auth succeeded when in the group, and failed when not in the group. Working how I want!
So how I have it is as follows.
Level: Entire Subtree (but this can probably work at one level too)
Base DN: DC=domain,DC=local
Containers: DC=domain,DC=local
Extended Query (checked): memberOf=CN=VPNgroup,OU=Groups,DC=domain,DC=localThe rest is still using the initial recommended Active Directory parameters when I first set up the "Server" configuration.
Now to complete setup and test this for actual OpenVPN access now, wheee!
-
So with my test account I have this set up exactly how I want. If the user account is disabled, auth fails. If the user is not part of the group, auth fails. To clarify, when I try to connect with the openvpnmanager it keeps prompting for login when either not member of the group or account disabled.
Now I need to test deleting/revoking the cert to make sure that works how I want. Also testing that the manager does work with a non-privileged user.
-
The cert revocation list works quite well! Interestingly enough it seems to just appear as a connection reset from the user's perspective, there's no "access denied" equivalent. I wonder if this is intentional.
I'm good to go it seems!