Troubleshooting: Error Retrieving Contact Information

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:

• See Cause 1 - ContextUser.GetUser: GetProfileProperties() exception: The settings property '<property>' was not found.
• See Cause 2 - ContextUser.GetUser: GetProfileProperties() exception: WebServiceProfileProvider.GetPropertyValues: Got error when connecting to Profile Web Service... (Webservice realms only)
• See Cause 3 - The realm is configured to use OpenLDAP as its datastore.
• See Cause 4 - The Warning log shows an SSL Provider "common algorithm" error on a realm using a SQL datastore.
• See Cause 5 - The affected user has duplicate entries in the Cloud tenant's datastore.
• See Cause 6 - The realm's Data tab Profile Provider connection is misconfigured, or profile attributes/fields are missing.
• See Cause 7 - The realm uses AD LDS as an additional Profile Provider over SSL.
• See Cause 8 - The realm is a New Experience realm (up to 24.04.2) using a single service account for both AD and AD LDS lookups.
• See Cause 9 - The realm is a New Experience realm on version 23.07 with multiple datastores configured.
• See Cause 10 - The realm was migrated from a Classic Dual Datastore realm to New Experience.
• See Cause 11 - The realm uses SQL to store some profile entries, and the user has no existing SQL record.
• See Cause 12 - ContextUser.GetUser: GetProfileProperties() exception: End of Stream encountered before parsing was completed.

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
• Cause 2: Webservice Realm Cannot Decrypt Its Stored Password
• Cause 3: Realm Configured for OpenLDAP Uses the Wrong ProfileProvider Directory Server Setting
• Cause 4: SQL Server Does Not Support a Modern TLS Version
• Cause 5: Duplicate User Entries in the Cloud Tenant's Datastore
• Cause 6: Data Tab Profile Provider Is Misconfigured, or Profile Fields Are Missing
• Cause 7: AD LDS Used as an Additional Profile Provider Over SSL
• Cause 8: New Experience Using One Service Account for Both AD and AD LDS Lookups
• Cause 9: New Experience Realm Initialization Race Condition on Multiple Datastores (23.07)
• Cause 10: Leftover ProfileProvider Reference After Migrating a Classic Dual Datastore Realm (22.02 HF2+)
• Cause 11: SQL-Stored Profile Entries With No Existing SQL Record for the User
• Cause 12: PNToken or OATHToken Property Has an Invalid Value

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.:

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.
   
3. Edit the account's userPrincipalName attribute so it matches 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.
   
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 cleared, SecureAuth no longer raises this exception for that user.


 

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.