Active Directory Authentication
Hi.
We use IPSEC MUVPN with AD authentication for a long time successfully. Today we removed a user from a MUVPN group and wonder that he is still able to conntect to the network via MUVPN client.
I would say that I'm quite sure that this was different in the past (maybe long time ago).
Did I miss anything (obvious) here?
Thanks a lot for your suggestions.
0
Sign In to comment.
Comments
Hi @offbyone
The user will still be able to authenticate, but their traffic won't match up with any of the policies in the MobileVPN w/IPSEC tab of your policies, so their traffic should appear as "unhandled muvpn traffic" and be dropped.
This may have been different in much older versions of fireware, or with other VPN technologies (like PPTP, when it was supported, as only one group was supported.)
So long as the user's traffic is being dropped on the firewall, this is the expected behavior.
Thank you,
-James Carson
WatchGuard Customer Support
Hi James,
THX for your fast response.
IMHO this is rather bad design.
We have situations where we have ADs with a lot of users and only a few are allowed to connect via VPN. Users which are allowed to connect via VPN are automatically assigned a password policy which enforces strong passwords.
With this design it is possible to check the password of all users objects inside AD from outside.
Hi @offbyone
In order for the user to connect, they'll need to have the VPN profile to do so. Unless they have been provided it, they'll be unable to complete authentication.
If you'd like to prevent logins all together, you can modify the AD settings (In Setup -> Authentication -> Authentication Servers) to only query a specific OU. If the user is not in the OU, the user will not authenticate.
(Configure Active Directory Authentication)
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/authentication/active_directory_about_c.html
(Find Your Active Directory Search Base)
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/authentication/find_ad_search_base_c.html
Thank you,
-James Carson
WatchGuard Customer Support
Hi James,
the OU solution is not an option as it would break the whole AD design of the customer (having about 2000 users). I really have no idea why WG does it this way. There is no reason to let people connect which are not allowed to in the first place.
However THX for the suggestion.
Another question.
Does it work similar for Firebox user authentication now as it does for AD? I suspect not. What I mean is can all users in the Firebox DB connect via IPSEC VPN client regardless if they are part of a MUVPN group and only traffic is blocked for those who do not belong to such groups?
The change how it works for AD has exposed security issues for one of our customers, as the MUVPN virtual IP address pool overlap with one of the normal Firewall rules and as such grants access to those resources for everyone connected and not only those belonging to that MUVPN group.
Sorry to say but I would consider this a design flaw. The least that should be done is to outline this behavior and esp. the difference to the FB internal database behavior in the manual.
Kind Regards.
I believe that it works the same way for Firebox-DB.
Hi @offbyone,
IPSEC MUVPN users will only be able to access rules on the IPSEC tab, and not the normal firewall rules.
While I understand your concern, like I mentioned previously, the user will be unable to even make it to that point without a correct VPN profile, which includes a pre-shared key, as well as the Phase1/2 settings.
I would not advise that you use overlapping IP ranges, as putting your IPSEC users on the same subnet will not get them in the same broadcast domain. If you did make rules by that subnet or alias, I would suggest specifying the IP range that's not part of the IPSEC users range to avoid any overlap.
Thank you,
-James Carson
WatchGuard Customer Support
I did not understand what you mean?
If I put a rule in the normal firewall rules tab like "Any | 10.10.0.0/16 -> Any Trusted" and "10.10.100.0/24" is the virtual address pool for the MUVPN group "MUAdmins" then anyone able to authenticate against AD is able to access all resources on the subnet "10.10.0.0/16" independently if they belong to "MUAdmins" or not.
Cheers.
Users not in the group should not be able to access a resource. Firewall rules are parsed against the group list that is generated when the user initially logs in.
If you're having an issue with users getting by that, I'd suggest opening a case with support so that they can take a deeper look at that with you, and resolve it.
You can contact support via the web or by phone here:
https://www.watchguard.com/wgrd-support/contact-support
Thank you,
-James Carson
WatchGuard Customer Support
Ok we will open an incident.
However everyone should be careful. If you have IP addresses in your normal rules that are part of the virtual address pool for a MUVPN group those rules grant access nevertheless the user is in that AD group or not.
Currently we are operating about 70 Fireboxes for our customers an we checked that on different customer installations.
Thanks for taking the time.
H. Bruces.
I verified this and you are right.
You can connect via MUVPN with the credentials of a Firebox-DB user even if he does not belong to a MUVPN group.
Cheers.