SecureAuth IdP Version affected: All versions 9.0.2 and earlier
Description: When configuring a realm's the Adaptive Authentication tab for Geo-velocity on an internal server, internal network users are authenticated regardless of what Set Velocity Limits are in place.
Cause: The IdP can not find the Geo-location, to internal network IP addresses. This issue is often witnessed when both external and internal servers are active in an environment. An end-user may login through an internal server, then login again from a different geo-location, through an external server, and never trigger a geo-velocity failure action. Because the IdP can not determine the geo-location of the internal IP address--saved to the user's Access Histories profile field--it can not determine the MPH that has passed between login attempts, thus cannot determine a failure.
Resolution: List the externally facing network IP addresses onto the Adaptive Authentication realm's System Info tab for each server. This will allow the IdP to match internal traffic against an identifiable IP address for the configured realm.
From each server--internal or external--go to the following:
Admin Console -> Admin Realm -> SecureAuth# -> System Info (tab) -> IP Configuration (section) -> Public IP Address
- Enter your network's externally facing IP address into the Public IP Address field.
If you are unsure what that might be, you can search engine "What's my IP" directly from the server.
- Click Save.
Geo-velocity can be tested on a realm by appending an inputted IP address to the following URL.
This will allow you to fake a geo-location, despite your current geo-location, for testing purposes. Launching the realm without the IP parameter, will pick-up the IP of your current location.
To enable this feature, add the following add key values to the realm's web.config file between the appSettings tags. Remove these add key values after testing to avoid security vulnerabilities.
<add key="EndUserIPDebug" value="True" />
<add key="AEDebug" value="true" />
. . .
If geo-velocity still does not hard stop, after implementing this change, check the servers' computer time. Make sure that each server is displaying the correct time for it's timezone.
Another possibility for a failure could be that the IdP server(s) isn't able to reach our GeoLocation endpoint through /msg protocol. Consult the document below for further information.
Country Restriction and Geo-velocity Do Not Restrict Access Properly