How To: Understand How the SecureAuth RADIUS Server Processes Client Rules

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

     

    Overview

    The SecureAuth RADIUS Server can have multiple RADIUS Client rules configured, each matching a specific IP address, an IP range, or a wildcard. This article explains the order those rules are evaluated in, so a rule ends up matching the request it was intended for.

     

    How Rules Are Evaluated

    Rules are matched in two passes. First, every specific IP address or IP range rule is checked, top to bottom in the order the rules are listed on the RADIUS Clients configuration page — the first specific rule whose IP address or range matches the incoming request's source IP is used. If none of the specific rules match, and a wildcard (*) rule exists anywhere in the list, that wildcard rule is used as a catch-all, regardless of where it appears in the list. If no rule matches at all, including no wildcard rule, the connection is rejected.

    For example, consider the following 5 rules, configured in this order:

    SecureAuth RADIUS Clients page listing 5 enabled clients in order: a wildcard *, then 10.1.1.86, 172.16.200.36, 172.16.*.*, and 10.1.1.*, each with an Authentication Workflow of Password only or Password plus Second Factor.

    Given those rules, in this exact order:

    1. A request from 10.1.1.86 matches rule 2 (10.1.1.86) exactly, so rule 2 is used.
    2. A request from 10.1.1.200 doesn't match any more specific rule, but does match rule 5 (10.1.1.*), so rule 5 is used.
    3. A request from 172.16.18.20 doesn't match any more specific rule, but does match rule 4 (172.16.*.*), so rule 4 is used.
    4. A request from 172.16.200.36 matches rule 3 (172.16.200.36) exactly, so rule 3 is used.
    5. A request from 10.10.10.10 doesn't match any specific rule at all, so it falls through to the wildcard, rule 1 (*).


     

    Special Considerations

    Order specific IP or IP-range rules so the most specific rule for any given address comes before less specific ones — for example, an exact IP address before a range that also contains it. A wildcard (*) rule is always evaluated last regardless of where it's placed in the list, so without one, any request that doesn't match a specific rule is rejected.


     

    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

    Comments

    0 comments

    Please sign in to leave a comment.