Troubleshooting: Geo-Velocity Not Enforced for Internal Network Users

Version Affected: 9.0.2 and earlier

Overview

When Geo-Velocity is configured on an Adaptive Authentication realm for an internal server, internal network users are authenticated regardless of the configured Set Velocity Limits.

Cause

Identity Platform (IdP) cannot determine the geo-location of internal network IP addresses. This is most often seen in environments where both internal and external servers are active: a user can log in through an internal server, then log in again shortly afterward from a different geo-location through an external server, without ever triggering a Geo-Velocity failure. Because the IdP cannot determine the geo-location of the internal IP address saved to the user's Access Histories profile field, it cannot calculate the miles per hour (MPH) that would have had to be traveled between the two logins, and so cannot detect a failure.

To resolve this:

1. From each server — internal or external — open the Admin Console.
2. Open the Admin Realm's SecureAuth# realm.
3. Open the System Info tab, then the IP Configuration section.
4. Enter the server's externally facing IP address into the Public IP Address field, as shown below. If you are unsure what this is, search "What's my IP" directly from the server.

5. Click Save.

This allows the IdP to match internal traffic against an identifiable IP address for the configured realm.

Geo-Velocity can also be tested by spoofing a client IP address for the realm. See How To: Debug and Verify Adaptive Authentication's Threat Service for the steps to enable and use this.

Special Considerations

If Geo-Velocity still does not hard stop after making this change, check each server's system clock — make sure it is displaying the correct time for its timezone.

Another possibility is that the IdP server(s) cannot reach the GeoLocation endpoint through the /msg protocol.

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.