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.
Part 1 – Creating the Membership Database
The first thing you need when
configuring FBA for SharePoint is a place to keep all of the usernames and
passwords. ASP.Net comes with a tool that we’ll use to create a membership
database to store the logon information.
- Navigate to c:\windows\Microsoft.NET\Framework64\v4.0.30319\
- Run “aspnet_regsql.exe”
- Navigate to c:\windows\Microsoft.NET\Framework64\v4.0.30319\
- Run “aspnet_regsql.exe”
- A welcome screen will appear. Click Next.
- Select “Configure SQL Server for application services” and click Next.
- Enter the name of your server and your authentication information. In this case SQL Server is installed on the same server as SharePoint 2013 and I am logged in as an administrator and have full access to SQL Server, so I choose Windows Authentication.For the database name, I just leave it as <default>, which creates a database called “aspnetdb”.
- A Confirm Your Settings screen will appear. Click Next.
- A “database has been created or modified” screen will appear. Click finish and the wizard will close.
- Now that the database has been created, we’ll have to give SharePoint permissions to read and write to it. We’re going to connect to the database with Windows Authentication, so we’re going to have to give those permissions to the service account that is being used to run SharePoint.First, let’s find out the service account that’s being used to run SharePoint. Open IIS, go to “Application Pools”. Take a look at the “Identity” that is being used to run the SharePoint application pools. On my test server, it happens to be my administrator account that is being used, but it will probably be different on your machine. Make note of the identity used.
- Now that we know what account is being used to run
SharePoint, we can assign it the appropriate permissions to the membership
database we created. Open up SQL Server Management Studio and log in
as an administrator.
- Under Security/Logins find the user that SharePoint runs as. Assuming this is the same database server that SharePoint was installed on, the user should already exist.Right click on the user and click ‘Properties’.
- Go to the “User Mapping” Page. Check the “Map” checkbox for the aspnetdb database. With the aspnetdb database selected, check the “db_owner” role membership and click OK. This user should now have full permissions to read and write to the aspnetdb membership database.
Part 2: Installing and Configuring the SharePoint 2013 FBA Pack
1.
Open http://sharepoint2013fba.codeplex.com/releases/view/100792
and download SharePoint 2013 FBA pack.
2.
Unzip Sharepoint2013FBAPack.X.X.X.zip to
the SharePoint server.
3.
Open PowerShell and navigate to the
folder the files were unzipped to.
4.
Run the following command:
Set-ExecutionPolicy
Unrestricted
.\deploy [Site Collection URL]
e.g. .\deploy http://demo2010a:13824/
5. The FBA Pack will be deployed
to SharePoint and activated on the specified site collection. If the site
collection url is omitted, you will need to manually activate the 'Forms
Based Authentication Management' feature in each site collection you wish
to use it.
6. To uninstall run:
.\undeploy [Site Collection URL]
Configure the FBA Pack
The configuration and management pages can be opened from
the Site Settings page:
Select ‘FBA Site Configuration’ to open the configuration page:
Enable Roles: Allows users to be assigned Membership Roles instead of SharePoint Groups on the User Management page.
Review Membership Requests: Specifies whether new users requests should be automatically granted, or reviewed by an administrator.
Membership Review Site URLs: URLs for pages that can be used in the email templates.
Membership Email: The XSLT email templates to use.
Note that these items can only been seen and used by the site collection administrators.
Select ‘FBA Site Configuration’ to open the configuration page:
Enable Roles: Allows users to be assigned Membership Roles instead of SharePoint Groups on the User Management page.
Review Membership Requests: Specifies whether new users requests should be automatically granted, or reviewed by an administrator.
Membership Review Site URLs: URLs for pages that can be used in the email templates.
Membership Email: The XSLT email templates to use.
Note that these items can only been seen and used by the site collection administrators.
Add the web parts to pages
There are three highly customizable web parts available:
Membership Request, Change Password andPassword Recovery. They must be manually
added to the page you’d like to use them on:
Change Password:
Membership Request:
Password Recovery:
Changing your Password
A Change Password item has been added to the user menu that
will bring the user to a Change Password page:
Reviewing Membership Requests
If “Review Membership Requests” was selected on the
configuration page, new registered users will appear in the Membership Request
Management page before being enabled on the site. Each user can be edited, and
their status changed to either Approved or Rejected. The user will be sent an
email with the new status of their account request.
Managing Users
Managing Users
Users can be created, deleted and edited and their passwords
reset from the FBA User Management page:
Managing Roles
Managing Roles
Roles can be created and deleted from the FBA Roles Management page:
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
- SecurityTokenServiceApplication
- 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" />
Be sure to
replace the value for Server with the name of your SQL Server.
- In the <membership><providers> section add the following:
<add name="FBAMembershipProvider"
type="System.Web.Security.SqlMembershipProvider,
System.Web, Version=4.0.0.0, 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=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
Save and close the machine.config file.
- 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=4.0.0.0, 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=4.0.0.0, 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.
Part 4 – Configuring SharePoint
- Open SharePoint Central Administration -> Application Management -> Manage Web Applications.
- Click “New” to create a new Web Application.
- Name the web application and adjust any other options to your preferences.
- Check “Enable Forms Based Authentication (FBA)”. Enter the ASP.Net Membership Provider Name and ASP.NET Role Provider Name that you configured in the web.config. For this example we used “FBAMembershipProvider” and “FBARoleProvider” (Without the quotation marks).Also, for this example we left “Enable Windows Authentication” checked. This allows us to login either via Windows Authentication or Forms Based Authentication (SharePoint will prompt you when you login for which method you’d like to use).Click OK.
- An Application Created dialog will appear. Click the “Create Site Collection” link to create the first site collection for this web application.
- From the Create Site Collection dialog, give the site collection a name and URL and select a template.
- For the Primary Site Collection administrator, i’ve left it as my Windows administrator account, so that I can login without FBA. For the Secondary Site Collection Administrator i’ve set it to ‘fbaadmin’ – the FBA account we setup in Part 2 (If you skipped Part 2 because you’re using the SharePoint 2013 FBA Pack, then you can just leave this blank for now and use your domain account to login to SharePoint and create your FBA users). You can set these to whatever is appropriate for your setup. Click OK.
- You’ll get the “Top-Level Site Successfully Created” dialog. You can click on the URL to visit the new site collection you just created.
- When authenticating to the site collection, if you enabled both Windows Authentication and Forms Based Authentication, you’ll be prompted for which method you’d like to use to authenticate. I’m going to choose to authenticate with Forms Authentication.
- You’ll be prompted for a username and password. Enter the username and password that we created in Part 2, and also set as the Secondary Site Collection Administrator.
- You’re now logged into the site as a site collection administrator.
Assign permissions to role
We can assign permissions to a specific role. Below are the steps:
Site
settings à Site
permissions Ã
Grant permissions Ã
show options Ã
Choose group or permission level from Drop down list à Enter name of role à Click Share
Then go to site settings Ã
FBA User Management Ã
Select user from list Ã
choose group/role then Save