How does the SecureAuth RADIUS Server process rules?

Version Affected:  ALL

Description:  

When having multiple RADIUS client rules, how are these rules processed?

Cause:  

Users may be denied access based on rules set in the RADIUS clients section of the configuration.

Resolution:  

The way RADIUS rules work is, if you have a specific IP or range of IPs it's going to try and match that, if that matches more than once, it's top down based on the way the rules are set in our admin page, and lastly after checking all of the rules, if it didn't match anything and you have a rule with * it goes into that one, otherwise it just rejects the connection.

If there are 5 rules in the configuration as such:

1. The end-user has an IP address of 10.1.1.86. The second rule in the list will trigger.
2. The end-user has an IP address of 10.1.1.200. The fifth rule in the list will trigger.
3. The end-user has an IP address of 172.16.18.20. The forth rule in the list will trigger.
4. The end-user has an IP address of 172.16.200.36. The third rule in the list will trigger.
5. The end user has an IP address of 10.10.10.10. The first (default) rule in the list will trigger.

The above example has a * rule so there would never be any rejections when attempting to connect. If the * rule was disabled or deleted, number 5 in the list above would have been rejected when attempting to connect via the RADIUS server.

The rules above are ordered with the many rules on the bottom (10.1.1.*, 172.16.*.*) so they do not get triggered in a top-down flow of matching multiple rules. This is a proper configuration for when specific IP addresses will be entered as a rule. Specific IP rules should be above any * rules. The default rule can be created as the last in the list but that one is always evaluated last, if it exists within the configuration.

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.