How the SecureAuth RADIUS server processes rules
The way the SecureAuth RADIUS rules works is when you have a user coming from a specific IP or range of IPs it will try to match the rule for that IP defined in the RADIUS clients.
If the IP matches more than one defined IP address, it will prioritize specific IP ranges over a general one.
Lastly, after it checks all the IP rules and there is no match, and you have a rule with a wildcard asterisk (*), it will apply that rule. Otherwise, it rejects the RADIUS connection.
For example, there are five RADIUS client IP rules defined as shown in the following image and table.
 |
Rule # | Client IP Address | Authentication Workflow |
|---|---|---|
First | 10.9.102.69-72 | Password | One-Time Passcode (TOTP/HOTP) |
Second | 172.16.*.* | Username | Fingerprint |
Third | 10.9.102.68 | Username | Face Recognition |
Fourth | 172.16.200.36 | Password | Second Factor |
Last (default) | * | Password only |
Then, it applies the following rules:
If the end user has an IP address of 10.9.102.68, it triggers the third rule.
If the end user has an IP address of 10.9.102.72, it triggers the first rule.
If the end user has an IP address of 172.16.18.20, it triggers the second rule.
If the end user has an IP address of 172.16.200.36, it triggers the fourth rule.
If the end user has an IP address of 10.10.10.10, it triggers the last (default) rule.
If the end user has an IP address of 10.9.102.73, it triggers the last (default) rule.
In this example, with the wildcard asterisk (*) rule, there would never be any rejections when attempting to connect via the RADIUS server.
If you disable or delete the wildcard asterisk (*) rule, then the rules number 5 and 6 in the list get rejected when attempting to connect via the RADIUS server.