How to speed up RADIUS authentication when users are members of many groups

    Applies to:
  • SecureAuth Identity Platform
  • Legacy SecureAuth IdP
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected:  All


    If users are members of many groups, 100+, there may be delays when attempting to authenticate against RADIUS. 



    Not all RADIUS clients can filter a large amount of data, mainly groups, quickly enough, which may cause delays in authentication or not being presented with the MFA screen or options.



    The best resolution for to speed up this type of issue is to use a Primary VPN group within AD, it can have nested groups as well and use a proper search filter on your "Data" tab for searching Active Directory and Group Filtering enabled for the primary group.

    Here is a nicely formatted query for the "Search Filter":

    (&(samAccountName=%v)(objectclass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=VPN Groups,OU=Groups,DC=my,DC=corp))

    The above query will look in the group "VPN Groups" and all nested groups for all objects that are members. If they are a member of said group, they will be allowed to authenticate via the RADIUS server.


    As for the console configuration, here is what needs to be set on your Data tab:

    1. Ensure the "searchFilter" is properly set for the environment
    2. Set the "User Groups" to the main VPN group
    3. Make sure "Include Nested Groups" is checked so it is enabled
    4. Make sure the "Group Field" is set to "memberOf"
    5. Make sure the Profile Field for "Groups" is set to "memberOf"





    Special Considerations (optional as needed): 

    For additional search configurations and filters, see the following article:

    How can I filter groups based off of a search filter?


    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful



    Please sign in to leave a comment.