Skip to main content
Submit a Request

Troubleshooting: Error Retrieving Contact Information

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

Version Affected: All
 
 

Overview

When attempting to log in, users see the error "Error Retrieving Contact Information". There are multiple potential causes, most distinguished by the exact message shown in the affected realm's D:\SecureAuth\SecureAuth<realm>\ErrorLog\Warning.log or Debug log. Each cause listed below gives the message or condition that identifies it.

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

 

In this article


 

Cause 1: Realm's web.config Missing a Settings Property Entry

The Warning log names a specific property — for example, kba2, kbq1, or OIDCConsent, not just one specific one. A defect means that certain actions, such as switching a realm's datastore from "No Data Store" to "Active Directory", can leave the realm's web.config missing entries it needs. Whichever property is missing is the one named in the Warning log message above.

This can also surface as an unhandled exception instead of a Warning log entry — for example, a Web Service realm can show a Server Error on its Post Authentication page reading WebServiceProfileProvider.GetPropertyValues: Got error when connecting to Profile Web Service: Object reference not set to an instance of an object.:

An ASP.NET server error page for the WebServiceProfileProvider.GetPropertyValues exception, showing the object reference error and its stack trace.

 

Resolution 1:

To resolve this, either update every realm's web.config in one pass, or manually add just the missing entry back into the affected realm.

Option 1: Run Update Web Config (recommended for most cases)

  1. Open the Web Admin Console.
  2. Click Tools > Update Web Config.
  3. Click Update.

This goes through every realm and adds back any entries that are missing.

Option 2: Add the missing entry manually

If updating every realm's web.config is too invasive for your environment, you can instead decrypt just the affected realm's web.config and add the specific missing entry back in. For example, if the Warning log named kba1:

<add name="kba1" />

Add the equivalent line for whichever property name the Warning log actually reported.

 

Cause 2: Webservice Realm Cannot Decrypt Its Stored Password

On a realm using Webservice as its datastore, the realm cannot decrypt its stored Webservice password. This prevents the realm from calling the Profile Web Service to retrieve the user's contact information, which raises this exception in the Debug log:

Message="ContextUser.GetUser: GetProfileProperties() exception:WebServiceProfileProvider.GetPropertyValues: Got error when connecting to Profile Web Service: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.

 

Resolution 2:

To resolve this:

  1. Check the License Info certificate for the realm and confirm it has the necessary permissions for SecureAuth0Pool.
  2. Even if the certificate already has the necessary permissions, re-enter the Webservice password on the realm.
  3. Try authenticating into the realm again.

 

Cause 3: Realm Configured for OpenLDAP Uses the Wrong ProfileProvider Directory Server Setting

On a realm configured to use OpenLDAP as its datastore, an issue with the ProfileProvider's connection string prevents SecureAuth from retrieving the user's properties.

 

Resolution 3:

To resolve this, configure the ProfileProvider's Directory Server setting as AD-LDS instead of OpenLDAP, even though the realm is actually using OpenLDAP:

  1. Change the ProfileProvider's "Same as above" setting to False.
  2. Set the Directory Server to AD-LDS.
  3. Fill in the rest of the ProfileProvider connection details exactly the same as the realm's OpenLDAP Membership connection settings.
  4. Save the settings and test.

 

Cause 4: SQL Server Does Not Support a Modern TLS Version

On a realm using a SQL datastore, the Warning log shows:

SqlProfileProvider.GetPropertyValues: for user: username Exception: A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The client and server cannot communicate, because they do not possess a common algorithm.)

This occurs when the SQL Server is old enough that it does not support a modern version of Transport Layer Security (TLS), so it and the appliance cannot agree on a shared encryption algorithm.

 

Resolution 4:

Upgrade the SQL Server to a version that supports TLS 1.2. Microsoft's article on enabling TLS 1.2 support for SQL Server covers the required steps: https://support.microsoft.com/en-gb/help/3135244/tls-1-2-support-for-microsoft-sql-server.

As a short-term workaround, you can re-enable an older TLS version (such as TLS 1.0) on the appliance so it can negotiate with the SQL Server, but this is not recommended since it weakens the appliance's overall TLS security.

 

Cause 5: Duplicate User Entries in the Cloud Tenant's Datastore

On a SecureAuth Identity Platform Cloud tenant, some users have duplicate entries in the tenant's datastore. When this happens, the affected user receives "Error Retrieving Contact Information" errors.

 

Resolution 5:

This requires SecureAuth Support to remove the duplicate entry on the back end. Open a Support case and provide:

  • Your tenant ID.
  • The username of the affected user.

Support will locate and delete the duplicate entry for that user.

 

Cause 6: Data Tab Profile Provider Is Misconfigured, or Profile Fields Are Missing

Users see "Error Retrieving Contact Information" when the realm's Data tab has an incorrect Profile Provider connection string, the user's account is missing profile attributes, the service account cannot read the user's profile fields, or the profile fields themselves are missing from the Data tab.

 

Resolution 6:

Work through each of the following checks in order:

  1. On the realm's Data tab, reconfigure the Profile Provider connection string, then click Test Connection to confirm it succeeds.
  2. Use LDP.exe, bound as the service account, to manually pull the user's profile attributes and confirm no fields are missing and that the service account can read them.
  3. If profile fields are missing from the Data tab, go to Admin Console > Tools > Update Web Config and click Update Web Config to bring the missing fields back.

 

Cause 7: AD LDS Used as an Additional Profile Provider Over SSL

When Active Directory Lightweight Directory Services (AD LDS) is configured as the realm's membership provider and connects over SSL, users see "Invalid User." When AD LDS is instead configured as an additional Profile Provider and connects over SSL, users see "Error Retrieving Contact Information" instead. In both cases, connecting to AD LDS over a non-SSL secure connection works without issue. The SSL connection requires the service account to meet additional requirements that a non-SSL connection does not.

 

Resolution 7:

Set up the AD LDS server with an appropriate certificate. Refer to Microsoft's documentation for the general certificate setup; the following SecureAuth-specific steps configure the service account AD LDS needs once that certificate is in place:

  1. Create a service account in the default naming context (for example, under CN=Roles) and give it a password.
  2. Edit the account's msDS-UserAccountDisabled attribute and set it to False.
    The Boolean Attribute Editor for msDS-UserAccountDisabled with the value set to False.
  3. Edit the account's userPrincipalName attribute so it matches the account's CN.
    ADSI Edit's Attribute Editor for a user object, with the userPrincipalName value being edited to match the account's CN.
  4. Grant the account sufficient permissions for the tasks it performs. In a test environment, adding it to the Administrators group is sufficient; in a production environment, scope its access with directory service access control lists (DS ACLs) instead.
  5. Confirm the IdP trusts the Certificate Authority that issued the certificate AD LDS is using.

 

Cause 8: New Experience Using One Service Account for Both AD and AD LDS Lookups

On a New Experience realm (up to version 24.04.2) that uses AD Lightweight Directory Services (AD LDS) alongside Active Directory (AD), all users see "Invalid User ID or Password" or "Error Retrieving Contact Information." New Experience's Data tab performs two separate lookups: one against an AD-based service account to verify the username and password, and a second against an AD-LDS-based service account to retrieve the user's profile information. Even when using a Secure connection type, New Experience expects two distinct service accounts — one for each lookup — rather than a single shared account.

This is a different issue from Cause 7 above: Cause 7 covers AD LDS used as an additional Profile Provider over SSL, where the existing service account has a certificate or attribute problem. Cause 8 applies even without SSL, and happens because only one service account was configured for both lookups in the first place.

 

Resolution 8:

This is due to be fixed in a future release. Until then, create two identical service accounts with permissions over AD LDS:

  1. Create one account in AD.
  2. Create a separate, matching account in AD LDS.
  3. Make sure the User Principal Name (UPN) and password are identical on both accounts.

 

Cause 9: New Experience Realm Initialization Race Condition on Multiple Datastores (23.07)

On version 23.07, a New Experience realm configured with multiple datastores can intermittently show "Invalid User," "Incorrect Group," or "Error Retrieving Contact Information." Most users can still log in; the error is typically limited to all users on one specific datastore at a time, while users on the realm's other datastores are unaffected.

When a realm initializes, it retrieves its datastore information. A race condition in 23.07 means that with several datastores configured, not all of them are guaranteed to be returned in time, which produces this intermittent, per-datastore failure.

 

Resolution 9:

This is a known defect in 23.07. Upgrade to the latest 23.07 hotfix (or a later release) to pick up the fix. Note that this cause covers only this specific race condition — the same error messages can also result from any of the other causes in this article, so confirm the realm is on 23.07 with multiple datastores and shows the one-datastore-at-a-time pattern before treating this as the cause.

 

Cause 10: Leftover ProfileProvider Reference After Migrating a Classic Dual Datastore Realm (22.02 HF2+)

On version 22.02 HF2 or later, migrating a Classic Dual Datastore realm to New Experience can leave behind an erroneous provider="SqlProfileProvider" reference in the migrated realm's web.config. New Experience does not expect this attribute on these entries, and throws an error when it encounters it. The Debug log shows an entry similar to:

OnStateChanged.SetProfileAccessHistories - Exception: The profile provider was not found 'SqlProfileProvider' (D:\SecureAuth\SecureAuth<Realm>\web.config line <N>)

 

Resolution 10:

Before continuing, back up the realm's current web.config.

  1. Open the Admin Console and go to Tools > Decrypt Web Config, select the affected realm, and click Decrypt.
  2. Attempt to log in to the realm again, and note the line number reported in the new error message.
  3. Open the decrypted web.config and go to the reported line. You will see one or more entries similar to:
    <add name="AuxID1" provider="SqlProfileProvider" />
  4. Remove only the provider="SqlProfileProvider" portion of each such entry, leaving entries like:
    <add name="AuxID1" />
  5. Save the web.config, then attempt to log in to the realm again to confirm it now succeeds.

 

Cause 11: SQL-Stored Profile Entries With No Existing SQL Record for the User

On a realm that uses SQL to store some of a user's profile entries, the user must already have a record in that SQL table. If they don't, the Debug log shows an entry similar to:

MFA.WebControls.ContextUser.SetProfileAccessHistories - Exception: The settings property 'AccessHistory' was not found.

The specific property name in the error varies depending on which properties are configured to be stored in SQL.

 

Resolution 11:

If you want a SQL entry created automatically for the user:

  1. Open the Admin Console and go to the affected realm's System Info tab.
  2. Scroll to the bottom and click Click to edit Web Config file.
  3. Search for <add connectionStringName="SqlServer.
    The Web Config Editor showing the SqlProfileProvider connection string entry, with its ClearProfile attribute highlighted.
  4. Set the ClearProfile attribute to False.

 

Cause 12: PNToken or OATHToken Property Has an Invalid Value

On a realm doing a user lookup (commonly seen on a Helpdesk realm's Search/Fetch User action), the Debug log shows:

ContextUser.GetUser: GetProfileProperties() exception: End of Stream encountered before parsing was completed.

This happens when the user's PNToken or OATHToken property holds a value SecureAuth cannot deserialize. Both properties should either be blank or hold their default placeholder value (AAEAAAD/////AQAAAAAAAAAQAQAAAAAAAAAL for each). On an affected user, one or both properties instead hold some other value — for example, a Base64 string unrelated to that default — which raises this exception when SecureAuth tries to read it.

 

Resolution 12:

Clear the value of whichever property (PNToken, OATHToken, or both) holds the incorrectly formatted value, so it reverts to blank. Once the value is cleared, SecureAuth no longer raises this exception for that user.

 

Cause 13: A Datastore Lookup Timed Out When the Realm Started

Every user on the realm gets this error after the realm's Internet Information Services (IIS) application pool recycles, for example after the scheduled recycle, a server restart, or Windows patching, and keeps getting it until the realm restarts again. Unlike in Cause 9, the whole realm fails, not one datastore at a time. The realm's error log shows one of these entries:

  • Broker GetDataStores, Error encountered for filter id eq '<datastore-id>': A task was canceled.
  • SecureStorage GetCredentials, Error encountered for id <id> and store <store-id>: A task was canceled.

When a realm starts, it calls SecureAuth services to load its datastore configuration. If that call takes longer than 10 seconds, it times out, and because of a known defect in the retry logic (EE-3943 and EE-3983) the realm keeps the failed result instead of trying again. The datastore's service account can also be locked out in Active Directory.

 

Resolution 13:

To resolve this:

  1. In the Admin Console, open the affected realm, go to the Overview tab, and click Save. This restarts only that realm.
  2. If the error persists, recycle the realm's application pool in IIS Manager on the affected server.
  3. If the datastore's service account was locked out, unlock it in Active Directory.

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. For the affected versions, the status of the SecureStorage GetCredentials timeout, and how to make the timeout less likely, see Bug: Realm Shows 'Error Retrieving Contact Information' or 'Invalid User' After an Application Pool Recycle.

 

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.