The real title of this post should: Users, Users Everywhere And Not A Single One Will Authenticate.
Forms Based Authentication is an amazing feature that allows you to store users in one database and access them from another. It’s the whole basis for single sign-on so you don’t have to create a news user at every site within the same family of websites.
Recently, our client websites went through a domain change and that, of course, played havoc with the Forms Based Authentication. Assuming that you’ve already setup FBA and you’re using SQL Server as the Membership database here the places where you need to modify the Connection String.
There are three, that’s 3, places where you will have to modify the connection string: Share Point Central Admin, Security Token Service Application, and, of course, the SharePoint content site.
In IIS you should find all three of these sites.
- SharePoint Central Administration will be a top level site likely called “SharePoint Central Administration”. Select the site in IIS and find the Connection Strings icon in the explorer window. Double click on it to open the Connection Strings list. One of those connection strings should point to your membership database. Modify the string to account for the new domain names, users, or passwords.
- Security Token Service Application is a sub-site of the Central Admin site and, in my opinion, the hardest to find. You should have another site in IIS called something like “SharePoint Web Services.” Expand that site and you’ll find the “SecurityTokenServiceApplication.” Select the Security Token site and follow the same steps as Central Admin to update the Connection String.
- “SharePoint Content” site is whatever you named your SharePoint site. This one should be easy to find in IIS and then just follow the instructions for Central Admin to change the Connection String.
And now you should be all connected again.
The Microsoft Technext site has a great step-by-step walk through on how to set up Forms Based Authentication called . You can read it here: Plan authentication methods (SharePoint Foundation 2010). Then read Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010) for more detailed information on Forms Based Authentication.
These articles walk you through the setup using the Lightweight Directory Access Protocol (LDAP) as an example. The same instruction will work for SQL Server based membership, except that the web.config entry is going to look a little different. Here’s an example, modify the settings as needed.
<system.web> <roleManager defaultProvider="AspNetWindowsTokenRoleProvider" enabled="true" cacheRolesInCookie="false"> <providers> <add name="ASPNETRole" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="SQLConnectionString" applicationName="DotNetNuke" description="Stores and retrieves roles from SQL Server" /> </providers> </roleManager> <membership defaultProvider="ASPNETMembership"> <providers> <add name="ASPNETMembership" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="SQLConnectionString" enablePasswordReset="true" requiresQuestionAndAnswer="false" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="0" requiresUniqueEmail="false" passwordFormat="Encrypted" applicationName="DotNetNuke" description="Stores and retrieves membership data from the local Microsoft SQL Server database" enablePasswordRetrieval="false" /> </providers> </membership> </system.web>
Then, of course, you’ll need to setup your connection string in this format:
<connectionStrings>
<add connectionString="Data Source={DB Domain};Initial Catalog={Database Name};User ID={User ID};Password={password}" name="SQLConnectionString" />
</connectionStrings>
That should get you a long way toward reestablishing Forms Based Authentication and save a call to Microsoft Tech Support.