USG110 VPN LDAP Security Group Recursive not working

Veronesi
Veronesi Posts: 24  Freshman Member
First Answer First Comment Friend Collector
edited April 2021 in Security
We have several USG110. (Firmware 4.33 (AAPH.0)
 
Users can connect from outside via L2TP VPN.
As authentication method we use an Active Directory (LDAP) query.

Allowed users are all users in the Domain Security Group gRemoteAccess.
This is working fine, as long as the users are directly in this Security Group.
If this gRemoteAccess contains other Security Groups within the users are (recursive) then this is not working.

This looks clearly like a bug. (Btw: same issue with our USG1100)

See attached screenshots.






This is how the working Security Group looks like:



This is how the not working Security Group looks like:


Veronesi

All Replies

  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,379  Zyxel Employee
    100 Answers 1000 Comments Friend Collector Seventh Anniversary

    Hi @Veronesi  

    As your description, gField and gSupport are members of gRemoteAccess.

    And users are belonging to gField and gSupport groups.

     

    You can use “test” function to make sure what is the value in “memberof”.

    If there is no gRemoteAccess identifier, then authentication will fail.

    (The attribute is replied from AD/LDAP server)



  • Veronesi
    Veronesi Posts: 24  Freshman Member
    First Answer First Comment Friend Collector
    @Zyxel_Stanley

    Thank you for your reply.
    I did this test and the Result is: "UserXYZ does not belong to this group."

    So this test is quite useful. However, it will not solve my problem.
    Because this user really belongs to this group. - But not in 1st hierarchy!
    In this Group are only other security groups. And there are then the members.

    You mentioned it right:
    gField and gSupport are members of gRemoteAccess.
    And users are belonging to gField and gSupport groups.

    So, the user belongs to the gRemoteAccess (indirectly). But the USG should recursively search for all groups and test. 
    This is currently not the case and therefore this issue happens.

    Veronesi
  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,379  Zyxel Employee
    100 Answers 1000 Comments Friend Collector Seventh Anniversary

    Hi @Veronesi  

    The attribute is replied from AD/LDAP server, If attribute without it, then user authentication will fail.

    There is other way to improve this situation. You can add subgroups first,aAnd then group them as a group object on USG.



  • Veronesi
    Veronesi Posts: 24  Freshman Member
    First Answer First Comment Friend Collector
    @Zyxel_Stanley

    Thank you for your answer.
    Yes, this would probably work.
    However, we don't like to manage the user groups in AD and in USG. (In AD there are many other attributes assigned to control different access permissions, not only VPN).

    Also there are more than only these two groups (gField and gSupport). About 30 different groups in at least 6 different countries (with their own USG). 

    So this is unfortunately not very practicable for us. Currently we've added all the different people manually in AD to the gRemoteAccessVPN group. This works and has the advantage for us, that we all can manage in AD - one central point.

    Pity, but thank you anyway for your suggestion.

    Best regards, Veronesi
  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,379  Zyxel Employee
    100 Answers 1000 Comments Friend Collector Seventh Anniversary
    edited April 2019

    Hi @Veronesi

    For USG, it is just forwarding request to AD server.

    The attributes and accessing permission are controlled by AD server.

    If gRemoteAccess group is not in “memberof” attribute, then AD server will not allow to login.

     

    It’s good heard you use other workaround on your environment. :+1:

  • Veronesi
    Veronesi Posts: 24  Freshman Member
    First Answer First Comment Friend Collector
    @Zyxel_Stanley

    Thank you.
  • swissp
    swissp Posts: 2  Freshman Member
    First Comment Fourth Anniversary
    Anyway, if your security group is with _ like Group_Name then it doesn't work, so remove _ in your group name! A bug from zyxel since many years.
  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,266  Zyxel Employee
    100 Answers 500 Comments Friend Collector Fourth Anniversary
    swissp said:
    Anyway, if your security group is with _ like Group_Name then it doesn't work, so remove _ in your group name! A bug from zyxel since many years.
    Hi @swissp

    Do you mean the group name is named on the AD server database? Thanks.


    Untitled Image

    See how you've made an impact in Zyxel Community this year! https://bit.ly/Your2024Moments_Community

Categories

Security Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）