Users are getting 2FA screen despite the ‘Default Workflow’ on the realm is set to Username only/Username & Password or Username | Password.

    Applies to:
Deployment model:
  • Hybrid
  • On Premises
  • SecureAuth IdP Version Affected: All

    Description: The realm is supposed to prompt the users for their AD credentials but they would still see the 2FA screen after entering the User name or Username & Password.

    Cause: Realm is configured with Adaptive Auth settings to check GeoVelocity, when the user accesses the realm using one of the Private IPs, (user’s location would be captured if the realm is accessed using a Public IP), so it will not detect the user’s location hence the analyzeEngine would consider the user’s location as ‘Unavailable’, resulting into TwoFactor.

    Below is the default GeoVelocity settings in web.config file.


    <analyzeEngine enabled="true" beginState="State1">
          <state name="State1" type="SecureAuth.AnalyzeEngine.State.VerifyGeoLocationState" enabled="true">
              <constraint name="C1" key="geovelocity" action="le" value="385">
                  <transition on="true" to="Continue" />
                  <transition on="false" to="HardStop" />
                  <transition on="unavailable" to="TwoFactor" />
                  <transition on="ipv6" to="TwoFactor" />


    Debug Logs show the result for location as ‘Unavailable’ when the realm is accessed using a Private IP:

    Message="AnalyzeEngine.Analyze: === Analyze Engine starts ===

     ###'State1:VerifyGeoLocationState', 'geovelocity', 'le', '385'

     Current IP ''

     Previous IP 'N/A'

     Result: unavailable

     'State1:VerifyGeoLocationState', goes to 'twofactor'

     === Analyze Engine ends at 'TwoFactorState' ==="


    Resolution: In the web.config file, we can alter GeoVelocity settings for the case when user’s location is ‘unavailable’. Change the condition FROM “<transition on="unavailable" to="TwoFactor" />” TO “<transition on="unavailable" to="Disable" />”, this way the realm will NOT prompt the Two Factor for the users accessing the realm from a Private IP.

    Special Consideration: If the customer has a Load Balancer or Proxy Server in place and the request is hitting to IdP via LB/Proxy, we’ll need to enable ‘X-Forwarded for’ to capture the end user’s IPs.



    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



    Please sign in to leave a comment.