To configure SharePoint to support FBA with SQL Membership Provider, you first need to create a SQL Server database file that supports your environment. To help you, ASP.NET provides a tool called ASPNET_REGSQL.EXE, which is available in the Microsoft .NET Framework folder. You invoke ASPNET_REGSQL.EXE within the Microsoft Visual Studio command prompt, and it creates a SQL Server database file. The tool is organized as a wizard (see Figure 4) with four main pages:

Figure 4. The Select The Server And Database page of the ASPNET_REGSQL.EXE wizard.

After you create the database, you need to configure some users and groups to use in SharePoint. For this purpose—and for the sake of simplicity—you can create a new ASP.NET Empty Website project in Visual Studio.

You can configure the website by going to Project | ASP.NET Configuration, which brings up the ASP.NET Web Site Administration Tool. This is a well-known tool with which every ASP.NET developer should be familiar. From there, you can use the Security Setup Wizard to configure your site for supporting FBA using the previously created SQL database. You can also manually configure the web.config file, if you like.

<configuration>
  <connectionStrings>
    <add name="SharePointFBA" connectionString="server=SP2013SQL;database=SP2013_Farm_FBA;integrated security=SSPI;"/>
  </connectionStrings>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
    <authentication mode="Forms" />
    <authorization>
      <deny users="?"/>
    </authorization>
    <membership defaultProvider="FBASQLMembershipProvider">
      <providers>
        <add connectionStringName="SharePointFBA" applicationName="/"
             passwordAttemptWindow="5" enablePasswordRetrieval="false"
             enablePasswordReset="false" requiresQuestionAndAnswer="true"
             requiresUniqueEmail="true" passwordFormat="Hashed"
             name="FBASQLMembershipProvider"
             type="System.Web.Security.SqlMembershipProvider, System.Web, 
Version=4.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
    </membership>
    <roleManager enabled="true" defaultProvider="FBASQLRoleManager">
      <providers>
        <add connectionStringName="SharePointFBA" applicationName="/"
             name="FBASQLRoleManager"
             type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
      </providers>
    </roleManager>
  </system.web>
</configuration>

These configuration elements will be useful when configuring SharePoint 2013 for FBA. While you’re in the Security Setup Wizard, you can also configure some users and groups, for testing purposes. The following roles have been created:

In addition, the following users have been created:

As their names imply, each user belongs to the corresponding role. For example, you can give them a password value of Passw0rd!. You should test your authentication infrastructure by writing a couple of sample pages for logging in and logging out.

Now that you have a working configuration for you site, you are ready to apply that configuration to SharePoint. First, you need to locate the web.config file of the web application where you will configure FBA. By default, the root folder of a SharePoint web application is located in the C:\inetpub\wwwroot\wss\VirtualDirectories folder of every front-end server.

Next, you need to copy the connectionStrings/add element that defines your SQL Server membership database into the connectionStrings element of the target web.config file. Be careful while editing the web.config file, and make a backup copy of it before applying any kind of change. If the connectionStrings section is missing, you must create it from scratch, adding it after the configSections element of the web.config file, as shown:

<connectionStrings>
    <add name="SharePointFBA" connectionString="server=SP2013SQL;database=SP2013_Farm_FBA;integrated security=SSPI;"/>
  </connectionStrings>

Then you need to locate the Membership and RoleProvider sections, within the system.web section of the target web.config file. There, you need to copy only the providers’ configuration, without changing the default providers that were already configured by SharePoint. The result should look like the following:

<membership defaultProvider="i">
  <providers>
    <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral,       PublicKeyToken=71e9bce111e9429c" />
    <add connectionStringName="SharePointFBA" applicationName="/"
          passwordAttemptWindow="5" enablePasswordRetrieval="false"
          enablePasswordReset="false" requiresQuestionAndAnswer="true"
          requiresUniqueEmail="true" passwordFormat="Hashed"
          name="FBASQLMembershipProvider"
          type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </providers>
</membership>
<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
  <providers>
    <add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
    <add connectionStringName="SharePointFBA" applicationName="/"
          name="FBASQLRoleManager"
          type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </providers>
</roleManager>

In the previous example, the code highlighted in bold shows that SharePoint 2013 already has a default membership provider named i and a default role provider named c. These are the providers that manage the claims-based infrastructure.

After you have configured the web.config file of the target web application, you need to configure the web.config file of the SPCA web application in the same way, as well as the web.config file of the internal SharePoint STS. The SPCA web application must be configured so that you can manage users defined in the FBA database from within the administrative pages, as well. You can still find its web.config file in a folder in the C:\inetpub\wwwroot\wss\VirtualDirectories path of every front-end server. The STS web application needs to have access to the FBA database in order to retrieve claims and information about the authenticated users during identity normalization. You can find the STS service of SharePoint and its web.config file in the SharePoint15_Root\WebServices\SecurityToken folder.

To take full advantage of the authentication infrastructure that you have just configured, the application pools of SharePoint need to have access to the SQL Server database you configured for FBA. Thus, you need to properly configure the database’s permissions. This is a simple but fundamental task. To carry it out, you need to enable the Windows identities configured for the following:

All three need the following database role memberships:

You are almost done. Now you simply need to configure the FBA providers—for example, through the SPCA interface. To access the list of available web applications, click Application Management, then click Manage Web Applications, and then choose the FBA target. On the ribbon, click the Authentication Providers command, and in the window that appears, click the Default Configuration link. The Edit Authentication configuration page will open.

Select the Enable Forms Based Authentication (FBA) check box, and provide the name for the membership provider and role provider to use. Figure 5 shows the configuration dialog box, completed with information based on the current sample scenario.

Figure 5. The Edit Authentication configuration page of SPCA.

The last step in configuring FBA is to enable some users or roles to access the site collections defined in your target web application. You can accomplish this task either from SPCA or from the People And Groups page of the target site.

Notice that if you now try to browse for users or roles, you will be able to browse both Windows and FBA users within the same browsing windows. From the perspective of SharePoint 2013, all the users are claims identities, regardless of the authentication provider that was used. Notice how searching for users in Figure 6 returns one result in the role repository of FBA and three more results in the security groups of Windows.

Figure 6. The Share dialog box with multiple authentication providers configured, during a search for users.