Troubleshooting: Post Auth Tab or Adaptive Authentication Page Slow to Load or Save in Air-Gapped Deployments

Version Affected: All — this specifically applies to air-gapped deployments, but can also affect non-air-gapped deployments if internet access is limited
 
 

Overview

In an air-gapped deployment — or any deployment with limited internet access — the Admin Console's Post Authentication tab can take close to two minutes to save, and the Adaptive Authentication page can take upwards of 45 seconds to open. Both delays come from the appliance, or its .NET runtime, attempting to reach an external URL that isn't reachable, and waiting for that call to time out before continuing.

This has two independent causes:

• See Cause 1 - The .NET runtime itself (dotnet.exe) is reaching out to Microsoft for various reasons, unrelated to SecureAuth.
• See Cause 2 - The Identity Provider (IdP) is reaching out to SecureAuth cloud service URLs — such as us-services.secureauth.com — that aren't reachable in an air-gapped environment.

These causes are not related, so a fix for one cause will not resolve the other.

 

In this article

• Cause 1: dotnet.exe Is Reaching Out to Microsoft
• Cause 2: The IdP Is Reaching Unreachable SecureAuth Cloud URLs

Cause 1: dotnet.exe Is Reaching Out to Microsoft

Amongst other causes, this delay has been seen to be caused by dotnet.exe attempting to reach out to Microsoft. This can be seen in a Wireshark or NetMon trace taken during a save of the Post Authentication tab: the trace shows dotnet.exe making repeated outbound connections over roughly a minute and a half, while the browser shows the WebAdminComplete.aspx request itself taking close to two minutes to complete.

To resolve this, add an outgoing Windows Firewall rule that blocks dotnet.exe from reaching any address outside your internal IP ranges:

1. Open Windows Firewall, click Outbound Rules, then click New Rule...
2. Leave Program selected and click Next.
3. Browse to the dotnet.exe executable — typically %ProgramFiles%\dotnet\dotnet.exe — and click Next.
4. Leave Action set to Block the connection and click Next.
5. Select the relevant firewall profile and click Next.
6. Give the rule an identifiable name and description, then click Finish.
7. Double-click the new rule to open its properties, and go to the Scope tab.
8. Under Remote IP addresses, select These IP addresses:, then click Add... twice to add two IP address ranges that together cover every address outside your internal range. For example, if your internal range is 10.0.0.0/8, add 0.0.0.0 to 9.255.255.255, and separately 11.0.0.0 to 255.255.255.255.
9. Click OK to save the rule.

dotnet.exe can now only reach IP addresses inside your internal range.
 

Special Considerations

• Creating firewall rules can cause communication problems in unexpected ways. Make sure you understand the rule's scope before applying it, and don't make the change if you're unsure how it will affect other traffic.

Cause 2: The IdP Is Reaching Unreachable SecureAuth Cloud URLs

Both the Post Authentication tab and the Adaptive Authentication page can independently show this same slow-loading behavior for a different reason: the IdP itself attempts to reach SecureAuth cloud service URLs — such as us-services.secureauth.com — that aren't accessible in an air-gapped deployment. Since the connection isn't refused outright, the call has to wait until it times out before the page continues loading or saving.

A NetMon trace taken during either delay shows a Domain Name System (DNS) query for one of these URLs:

The delay itself shows up as a single long-running request — for example, about 45 seconds on the Post Authentication tab's WebAdminComplete.aspx save:

or a similar delay on the internal API call made when opening the Adaptive Authentication page:

To resolve this, add the following entries to the local HOST file, pointing each URL to an invalid IP address so the lookup fails immediately instead of timing out:

0.0.0.0 us-cloud.secureauth.com
0.0.0.0 us-services.secureauth.com
0.0.0.0 sparkles-content.prod.secureauth.com

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.