Skip to main content
Submit a Request

Bug: Realm Shows 'Error Retrieving Contact Information' or 'Invalid User' After an Application Pool Recycle

Ben Watts
Updated
    Applies to:
  • SecureAuth Identity Platform
    Deployment model:
  • Hybrid
  • On Premises

Version Affected: 23.07, 24.04, 26.0, 26.1
Bug Number: EE-3943, EE-3983
Bug Status: Open
Fixed in Version(s): Broker GetDataStores timeout (EE-3943): 24.4.3.14, 24.4.5.7, 24.4.6.5, and 26.0.2.9 or later. SecureStorage GetCredentials timeout (EE-3983): not yet fixed.

 

Overview

A realm that was working starts returning Error Retrieving Contact Information or Invalid User to every user after its Internet Information Services (IIS) application pool recycles, for example after the scheduled recycle, a server restart, or Windows patching. The realm keeps failing until it is restarted again. Usually only one realm, or one server, is affected while the others keep working. The data store's service account can also be locked out in Active Directory, with the lockout traced back to the Identity Provider (IdP) server.

 

Cause

When a realm starts, it calls SecureAuth services to load its data store configuration before it can look users up. If one of these calls takes longer than 10 seconds, it times out. Because of a defect in the retry logic, the realm does not try the call again: it keeps the failed result, and every login on that realm fails until the realm restarts.

Two different calls are affected, each tracked as its own bug. The realm's error log shows which one timed out.

Broker GetDataStores timeout (EE-3943) — the call that loads the realm's data store definitions. The error log shows:

Broker GetDataStores, Error encountered for filter id eq '<data-store-id>': A task was canceled., exception: System.Threading.Tasks.TaskCanceledException: A task was canceled. ... ResponseTime='10011'

It is often followed by The type initializer for 'SecureAuth.Integration.IWA.IWAManager' threw an exception. or ContextUser.GetUser: GetProfileProperties() exception:A task was canceled.

SecureStorage GetCredentials timeout (EE-3983) — the call that New Experience data stores make to fetch the service account's credentials. The error log shows:

SecureStorage GetCredentials, Error encountered for id <id> and store <store-id>: A task was canceled., exception: System.Threading.Tasks.TaskCanceledException: A task was canceled. ... ResponseTime='10009'

This timeout can also lock out the data store's service account in Active Directory, and SQL Server data stores can log SqlException: Login failed for user '<service-account>'.

The slow response that triggers either timeout is more likely when many realms restart at the same moment (for example, when several application pools recycle together), when the server is short of processor or memory capacity, or when a realm has more data stores than it needs.

 

Resolution / Workaround

The Broker GetDataStores timeout is fixed in 24.4.3.14, 24.4.5.7, 24.4.6.5, and 26.0.2.9 or later: upgrade to one of these versions. The SecureStorage GetCredentials timeout is not yet fixed. For either timeout on other versions, SecureAuth Support can provide patched files for specific builds.

To restore a realm that is failing now:

  1. In the affected realm's error log on the affected server, confirm that one of the two log entries shown above is present.
  2. In the Admin Console, open the affected realm, go to the Overview tab, and click Save. This restarts only that realm.
  3. If saving does not clear the error, recycle the realm's application pool in IIS Manager on the affected server.
  4. Test a login on that realm. If it fails again with the same log entry, the call timed out again while the realm restarted, so repeat step 2.
  5. If the data store's service account was locked out, unlock it in Active Directory.

To make the timeout less likely:

  • Put no more than about 10 realms in each application pool, and stagger the pools' recycle times so that they don't all restart at once.
  • Make sure the server has enough processor and memory capacity, and that only one antivirus product scans the SecureAuth folders.
  • Remove any data stores a realm doesn't need, which reduces the time the realm spends looking users up.




 

Special Considerations

  • Patched files from SecureAuth Support must be copied into the Bin folder of every realm on every server, including the template realm SecureAuth1 so that new realms get them. FileSync does not copy these files. A realm without the patched files can still hit the timeout, and a later upgrade or hotfix can replace them, so re-check after each one.
  • Saving a realm or recycling its application pool restarts the realm, which interrupts any logins in progress on it.

 

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.

Comments

0 comments

Please sign in to leave a comment.