Configuring Forms Based Authentication in SharePoint 2013 – Part 3 – Editing the Web.Config Files
Configuring forms based authentication (FBA) in SharePoint 2013 is very similar to SharePoint 2010, but there are some differences due to SharePoint 2013 using .Net 4.0. The web.config entries entries are slightly different. As well, IIS doesn’t support editing .Net 4.0 membership provider configuration through the IIS interface, so all of the configuration has to be done directly in the .config files. I’ll go through all of the steps required to setup FBA for SharePoint 2013, from start to finish. I’ve broken down the steps into 4 sections:
Part 3 – Editing the Web.Config Files
The next thing that has to be done to get forms based authentication working with SharePoint is setting up the membership provider. A membership provider is an interface from the program to the credential store. This allows the same program to work against many different methods of storing credentials. For example you could use an LDAPMembershipProvider to authenticate against Active Directory, or a SQLMembershipProvider to authenticate against a SQL Server database. For this example we’re using the SQLMembershipProvider to authenticate against a SQL Server database.
SharePoint is actually divided up into several web applications – Central Administration, the Security Token Service and all of the SharePoint web applications that you create. Each of those web applications needs to know about the membership provider. Most tutorials have you adding the membership provider settings over and over again in each web config (as well as every time you setup a new SharePoint web application). I prefer to add the membership provider settings directly to the machine.config. By adding it to the machine.config, the configuration is inherited by all of the web.config files on the machine – so you only have to make the changes once, and don’t have to remember to make the changes every time you create a new SharePoint web application.
If you don’t have access to the machine.config, or prefer not to edit it, you will have to make all of these changes to the following web.config files:
- SharePoint Central Administration
- Every SharePoint web application you create that you would like to access via FBA.
- Navigate to “C:\Windows\Microsoft.Net\Framework64\v4.0.30319\Config” and open “machine.config”.
- In the <ConnectionString> section, add the following line:
<add connectionString="Server=WIN-C6ES927TE58;Database=aspnetdb;Integrated Security=true" name="FBADB" />
- In the <membership><providers> section add the following:
<add name="FBAMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="FBADB" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" />
You can customize the authentication by modifying each of these options. The most important thing to remember though is that if you define a membership provider in multiple locations for the same database, they MUST ALL USE THE SAME OPTIONS. Otherwise you’ll run into all kinds of problems with users created with one set of options, and later being authenticated against with a different set of options.
Here’s a description of the different options available:
Option Description connectionStringName The name of the database connection to the aspnetdb database. enablePasswordRetrieval true/false. Whether the user’s password can be retrieved. I suggest setting this to false for security purposes. enablePasswordReset true/false. Whether the user can reset their password. I suggest setting this to true. requiresQuestionAndAnswer true/false. Whether accounts also have a question and answer associated with them. The answer must be provided when resetting the password. I suggest setting this to false, as setting it to true prevents an administrator from resetting the user’s password. applicationName Setting the application name allows you to share a single membership database with multiple different applications, with each having their own distinct set of users. The default applicationName is /. requiresUniqueEmail true/false. Determines if multiple users can share the same email address. I suggest setting this to false, in case you ever want to implement a login by email system. passwordFormat Clear, Hashed or Encrypted. Clear stores the password in the database as plain text, so anybody with access to the database can read the user’s password. Encrypted encrypts the user’s password, so although the password isn’t human readable in the database, it can still be decrypted and the user’s actual password retrieved. Hashed stores a one way hash of the password. When a user authenticates, the password they enter is hashed as well and matched against the stored hashed value. Using this method, the user’s password can never be retrieved (even if your database is stolen), only reset. I always recommend using “Hashed” as it is the most secure way of storing the user’s password. maxInvalidPasswordAttempts The number of times in a row that a user can enter an invalid password, within the passwordAttemptWindow, before the user’s account is locked out. Defaults to 5. passwordAttemptWindow The number of minutes before the invalid password counter is reset. Defaults to 10. minRequiredPasswordLength The minimum password length. Defaults to 7. minRequiredNonalphanumericCharacters The minimum number of non-alphanumeric characters required in the password. Defaults to 1. passwordStrengthRegularExpression A regular expression that can be used to validate the complexity of the password.
- In the <roleManager><providers> section add the following:
<add name="FBARoleProvider" connectionStringName="FBADB" applicationName="/" type="System.Web.Security.SqlRoleProvider, System.Web, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
- I mentioned that if you modified the machine.config, you’d only have to put the config in a single place. I wasn’t being completely truthful. The SharePoint Web Services configuration overrides the machine.config and clears the entries we created. For that reason, the membership and role providers also need to be added to the SecurityTokenService (But only there – you won’t have to add them to the central admin or other SharePoint web app web.configs.First we need to find the web.config for the SecurityTokenService. Open up IIS. Under sites, SharePoint Web Services, right click on SecurityTokenServiceApplication and click on Explore. Edit the web.config in the folder that opens.
- Add the following to the web.config, just before the closing </configuration> tag:
<system.web> <membership> <providers> <add name="FBAMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="FBADB" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" /> </providers> </membership> <roleManager> <providers> <add name="FBARoleProvider" connectionStringName="FBADB" applicationName="/" type="System.Web.Security.SqlRoleProvider, System.Web, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </providers> </roleManager> </system.web>
Remember to match all of the options with what was entered in the machine.config.Save and close the file.
The role and membership providers have now been setup for SharePoint. Continue on to Part 4 to configure SharePoint to use the membership provider we just setup.