If your Extradium users cannot sign in and get the following message: "Your sign in attempt was unsuccessful", it is oftentimes a database permission issue, when the account running the SharePoint Security Token Service Application Pool is not the SharePoint Farm account (which is the case in most standard SharePoint installations). Please follow the procedure below:
1. In IIS, please note the account running the SecurityTokenServiceAppPool application pool
2. Verify in SQL Server Management Studio that this account has db_owner permissions on the Extradium database
3. If not, grant db_owner permission for that account
In other cases, enabling the full error stack trace as described in this KB article is not enough to troubleshoot sign-in issues.
Oftentimes, the error stack trace that gets displayed is the following:
If that is the case, it is an indication that the SharePoint Security Token Service (STS) doesn’t work properly.
The most common issue is related to an improper configuration. Normally, the Extradium Web.Config Updater farm feature is supposed to modify the STS web.config files on all web front-end servers, but it sometimes doesn’t always work and in situations where you add a web front-end after deploying Extradium, the new STS web.config file will not be updated.
The first step is thus to review the STS web.config file. In a SharePoint 2010 farm, this file is located in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken folder on each web front-end server. In a SharePoint 2013 farm, it is located in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\WebServices\SecurityToken folder.
Open the web.config file in that folder and make sure it contains the following section (for SharePoint 2010) at the very bottom:
<system.web>
<membership>
<providers>
<add name="ext" type="RLSoft.XtraShare.Providers.XtraShareMembershipProvider, RLSoft.XtraShare.Providers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=ee2f606d34db8cb1" />
</providers>
</membership>
<roleManager enabled="true">
<providers>
<add name="extg" type="RLSoft.XtraShare.Providers.XtraShareRoleProvider, RLSoft.XtraShare.Providers, Version=2.0.0.0, Culture=neutral, PublicKeyToken=ee2f606d34db8cb1" />
</providers>
</roleManager>
</system.web>
For SharePoint 2013, the previous section should be:
<system.web>
<membership>
<providers>
<add name="ext" type="RioLinx.Extradium.Providers. Extradium MembershipProvider, RioLinx.Extradium.Providers, Version=3.0.0.0, Culture=neutral, PublicKeyToken=ee2f606d34db8cb1" />
</providers>
</membership>
<roleManager enabled="true">
<providers>
<add name="extg" type="RLSoft.Extradium.Providers.ExtradiumRoleProvider, RioLinx.Extradium.Providers, Version=3.0.0.0, Culture=neutral, PublicKeyToken=ee2f606d34db8cb1" />
</providers>
</roleManager>
</system.web>
If it does not contain such a section, please update the STS web.config accordingly.
If the providers section is already properly configured in the web.config file, but you still cannot sign in, you will have to configure some additional debug switches in that web.config file to allow the SharePoint page to display the full error stack trace thrown by the STS.
In order to do so, please add the following line right before the closing </behavior> node:
<serviceDebug includeExceptionDetailInFaults="True" httpHelpPageEnabled="True"/>
The <behaviors> section of the STS web.config should now look like this:
After you have performed those modifications, try to reproduce the error and please send us the stack trace message that SharePoint now displays.