Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN - AD Group membership authentication for firewall rule

For our XG with SSL VPN we are using AD Authentication and MFA. That works but sometimes when setting up new users I am having problems getting them to access our LAN. As if the route to the LAN is not present after connecting with SSL VPN.

Today I was also troubleshooting a user and I believe it is not a route add issue in SSL VPN as I saw the src ip traffic being blocked in the firewall log. I think that the AD Group membership authentication check with AD is having problems. 

Users in AD can be member of many different Groups. The groups and the users have been imported in the past. Now when I add a user to the VPN User group in AD I am suspecting that this change is not picked up by the XG. I starts working for the user when I add him to the VPN user group in the XG. 

We want to administer everything in AD and have the XG check that. Is this authentication flawed in XG not synchronized with AD?

Should I purge periodically the AD Groups and users and re-import them? How is this supposed to work in the XG?

Thanks,

Fred

 

 



This thread was automatically locked due to age.
Parents Reply
  • Hi Jaydeep, I do not believe that this KBA is true for my setup would not be working at all. I see a lot of users that are mapped to a Group in XG that has no Firewall access at all. Still it is working for them. I believe this post by LucaToni to be more correct. community.sophos.com/.../ad-synchronisation-user-multiple-user-group-memberships But in my case today the user group were not updated correctly from AD. If I look in XG users than his primary group is still Open Group. I added him manually to the correct Group in XG manually and it started working instantly. Still his primary group is Open Group in XG and cannot be removed. I wil troubleshoote more. Fred
Children
  • Actually it depends. 

    The Primary Group is only used for "visibility" in XG.

    In fact all other Groups attached to this user AND created in XG (linked) are used for Proxy, Web, VPN etc.

    XG is lacking the capability in showing the value of all groups. 

    But for VPN (SSLVPN), it should be working. 

    If you attach a AD Group in SSLVPN, this group should be shown in the User as VPN Group. 

     

     

    If you import Group A, B, C. and you have a User Test, this user will get all groups attached in the backend.

    The First match principle in all facilities will hit. 

    __________________________________________________________________________________________________________________

  • PS: The Policy Tester should work in V18 with all Groups. 

    __________________________________________________________________________________________________________________

  • Hi LuCar Toni,

    Is that pre-release info? That would be great. The XG is on SFOS 17.5.9 MR-9 and there is no new firmware available yet. 

    I have one SSL VPN policy named Employee. It has the following Policy members namely VPN Administrators, VPN Power Users and VPN Users. 

    In Users - user - SSL VPN Policy - Remote Acces has Employee as policy.

    At the Info tooltip it doesn't give the group involved for that user. There is now no way of knowing for me if the XG has the imported AD Group associated with that user. In Groups you cannot see the user members.   Annoyingly this user has the Open Group as its primary group and that is a XG local Group and the only Group that shows its members. How does this association to the Open Group take place as I never added him to that group? Can he be associated with another primary group?

    In Firewall rule I have an access rule grouped from most specific to less specific, so from VPN Administrators to VPN Users. 

    I regrouped the AD groups now also from top to bottom Group, Clientless Open group, Guest group, VPN administrators, VPN Power Users, VPN Users.  But if this user hits Open Group first he will not be allowed access. 

    Personally I believe a Firewall rule should be evaluated by querying the associated group membership in that Firewall rule. So if there is a Firewall rule allowing access for VPN Users it should check who is member of VPN Users and allow and not find Open Group as the first and then bounce. I don't see it working like that as there are users associated with an AD primary Group that was above the VPN Users in Group order and still were allowed access tru the Firewall rule. No problem there. Just the one's associated with Open group. 

    We have different sets of Firewall rules based on AD groups for different situations that users can be in like WIFI access, LAN inside out, VPN access in to name a few. If XG does not query AD group membership and evaluates Group order down than it can conflict in different situations.  

    It is a bit difficult trouble shooting this.

    Thanks,

    Fred

     

     

     

     

     

     

     

  • You should start to check, which groups are coming back from your AD to actually verify all groups, XG is getting by your AD.

     

    There are two way to do this.

    1. Tcpdump on port 389 and wireshark check the packets.

    2. access_server debug mode and check the XG Debug Log. 

     

     

     

    __________________________________________________________________________________________________________________

  • In Authentication - Services - Firewall authentication method - Servers I have moved the AD server above Local.

    The default group here is Open Group. That would also cvreate a direct hit and a deny.