Troubleshooting: Multi-Datastore Web Service Realm Issues

Version Affected: All
 
 

Overview

A realm configured to use Web Service (Multi-Datastore), with two or more realms serving as datastores, can fail to find valid users or can log in very slowly. There are multiple potential causes, distinguished by the exact symptom:

• See Cause 1 - Users see an "Invalid User" error, and the Web Service realm's debug.log shows WebServiceMembershipProvider.GetUser failing to activate the membership service
• See Cause 2 - Users see an "Invalid User" error, but the datastore configuration and connection otherwise appear correct
• See Cause 3 - Login is slow, and can time out, but the user is eventually found

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

 

In this article

• Cause 1: Multiple Site Bindings Not Enabled in web.config
• Cause 2: Web Service Account Username Mismatch
• Cause 3: Sequential Datastore Lookup With Many Users

Cause 1: Multiple Site Bindings Not Enabled in web.config

Users see an "Invalid User" error, and the Web Service realm's debug.log shows an entry similar to:

WebServiceMembershipProvider.GetUser: for user '*' with url https://localhost/secureauth<n>/webservice/membership.svc, exception: The requested service, 'https://localhost/secureauth<n>/webservice/membershipws.svc' could not be activated.

Browsing directly to the Web Service URL endpoint shows an additional error:

This collection already contains an address with scheme https. There can be at most one address per scheme in this collection.

This happens when Multiple Site Bindings is enabled in IIS for the site, but the corresponding setting is not enabled in the SecureAuth realm's web.config.

Resolution 1:

1. In the Admin Console, open the affected realm and go to the System Info tab.
2. Click Decrypt.
3. Open File Explorer and browse to D:\SecureAuth\SecureAuth<n> (where <n> is the realm number).
4. Open web.config in a text editor and search for:
   

   <serviceHostingEnvironment multipleSiteBindingsEnabled="False"/>

5. Change False to True:
   

   <serviceHostingEnvironment multipleSiteBindingsEnabled="True"/>

6. Save the file and test.

This same underlying cause can also affect the SecureAuth Credential Provider -- see Troubleshooting: Credential Provider Login Fails With "This Collection Already Contains an Address With Scheme https" Error if the Credential Provider is showing this same error.

Cause 2: Web Service Account Username Mismatch

Users see an "Invalid User" error because the Web Service account username configured in the lookup realm does not exactly match the one configured in the multi-datastore realm. This comparison is case-sensitive.

Resolution 2:

Confirm the Web Service account username is an exact, case-sensitive match between the lookup realm and the multi-datastore realm, and correct whichever one does not match.

Cause 3: Sequential Datastore Lookup With Many Users

On a realm configured for Web Service (Multi-Datastore) with two or more realms serving as datastores, the Web Service loops through the configured datastores in order, starting with the one listed at the top of the Data Store tab, until it finds the user. If the datastores contain thousands of users, this lookup can take a long time and can time the user out before it finishes.

Resolution 3:

Instead of relying on the sequential lookup, direct the user straight to their specific datastore by appending a pipe and the domain name to the realm entry in the Membership Configuration section. For example, for a realm named secureauth1 serving the domain abc, the entry becomes:

The user can then log in directly against that datastore by prefixing their username with the domain name, for example abc\username.

For more information on Multi-Datastore configuration, see the Web Service (Multi-Data Store) Configuration Guide.


 

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.