USG110 VPN LDAP Security Group Recursive not working

Veronesi

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

Zyxel_Stanley

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

@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

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

@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

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.

Veronesi

@Zyxel_Stanley

Thank you.

swissp

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

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.