When SharePoint FBA Goes Bad!–Part 1

Alright I have to be honest, the headline is just to draw you into the site and get your attention. Look it already worked! But with that done I would like to take you through Forms Based Authentication setup within SharePoint and will talk about how to trouble shoot FBA when it does go bad! I promise.

Over the last 4-5 months I have had to do many Forms Based Authentication (FBA) setups. This blog post and follow-up posts will talk about what should happen to make this work in a typical FBA environment. Now you are probably saying there are plenty of blogs that talk about this. I would agree and I will be referencing some of them. However not all of them talk about what are you going to do when things go wrong! That is what we will look at in the last installment.

  1. Beginning FBA Configuration and Settings up Claims based Web Application
  2. Working with Web Configuration Files
  3. Using the CodePlex SharePoint 2010 FBA Pack
  4. When FBA Goes Bad!

One FBA Scenario

In this scenario we are going to be setting up FBA within SharePoint for a typical extranet installation. This solution will not require any development of user management pages or branding, however these are options that need to be considered. So what are the different options when it comes to user management?

  1. Make changes right in SQL – I don’t know about you but in most organizations this is not really a legitimate option. For testing purposes, adding users to SQL is a must. Check out this post from MSDN about this process.
  2. Develop the controls and pages that will be used to support user management. This is not always a viable option if there is not a developer within your organization.
  3. Download the SharePoint 2010 FBA Pack. We are going to talk through this in a later post.

Before Configuration Begins

It would be a good idea to talk a little bit about gathering some information prior to configuration of FBA. Besides the question of which user management solution to use, some discussion needs to be made to determine how many roles need to be considered. Roles within FBA equate to Active Directory (AD) groups. Because everything is in SQL we do not necessary have access to AD groups, this is the typically the purpose of implementing FBA. As you create users within SharePoint FBA you can assign a specific role to them. These roles can then be assigned to SharePoint groups or used within SharePoint permission.

Beginning FBA Configuration

With something like this we need to make some basic assumptions:

  1. You are on Windows Server 2008 R2 for SharePoint and SQL
  2. You are using SharePoint Server 2010 or SharePoint Foundation 2010
  3. Your database is SQL Server 2008 or 2008 R2
  4. And on the SharePoint box you have ASP.NET/IIS Administration up and running
  5. SharePoint 2010 Web Applications are configured to run in Claims Authentication (rather than Classic)

Once all of these assumptions have been realized it is time to create the ASP.NET membership database that will house the FBA members and roles that will be needed for your SharePoint extranet.

Creating the Membership Database

The process for creating the Membership Database within the SharePoint 2010 environment is exactly the same as within SharePoint 2007. We are going to be using the ASP.NET SQL Server Setup Wizard.

  1. On the SQL server navigate to C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe application.
  2. This brings up the Select a Setup Options window. Make sure that Configure SQL Server for application services and click Next.

  1. Add the name of the SQL Server you are going to be accessing with the account information of the user with "Create Database" access.
  2. You can either name the database or use the default, aspnetdb. Click Next.

  1. Confirm the settings and complete the database creation.
  2. Once the database has been created, make sure to grant the SharePoint Farm and SharePoint Content accounts appropriate access
  • Open up the SQL Server Management Studio and open the Security node.
  • Within the Logins make sure that the SharePoint Farm account is there, if not then Right-click on Logins and add the SharePoint Farm account.
  • Make sure to go into the Properties for the SharePoint Farm account and on the User Mapping node sure that the aspnetdb is selected.
  • If the SharePoint Farm is not the owner of the aspnetdb, then select all "aspnet_" access options and then click OK. (This is following least privileged security practices)
  • Repeat steps b-d for the SharePoint Content Account.
           3.  Last thing before leaving SQL is to ensure that mixed authentication mode is enabled.
  • Right-click on the Server in the Object Explorer and select Properties.
  • In the Security node and Server authentication section make sure to select SQL Server and Windows Authentication mode.

Provisioning Claims Based Web Application

  1. Close out SQL Server Management Studio and navigate to SharePoint Central Administration.
  2. Click on Manage Web Applications link and in the SharePoint ribbon click on New.
  3. Make sure to select the Claims Based Authentication radio button.

  1. In the Authentication Type section select Enable Windows Authentication and select NTLM or Kerberos.

A choice needs to be made at this point. How are you planning on staging this SharePoint web application? Here are a couple of scenarios:

Scenario 1: Multiple zones are needed for this installation. The website is an internet web site and we are using FBA for users to log in and manage the content. Then it is suggested the following:

  • Default Zone – Server Name with Anonymous and FBA setup.
  • Internet Zone – Desired URL with only Anonymous setup.
  • Intranet Zone – Specialized URL with only FBA setup. You could also add SSL to this if desired.

Scenario 2: Default zone needed for this installation. Intranet or extranet with outside members needing access so only using the default would be fine.

  1. If you are using scenario 1 or 2 you are going to need to Enable ASP.NET Membership and Role Provider and enter in the Membership Provider and Role Manager names. These could be as simple as ACMEMembershipProvider and ACMERoleProvider. Whatever you choose make sure to document this for later use when configuring the web.config files.

In the next post I will talk about the fun task of configuring the web configuration files within SharePoint.

However before I get there, I need to make sure to recognize the website I found some vital information on the ASP.NET database. Thanks. http://donalconlon.wordpress.com/2010/02/23/configuring-forms-base-authentication-for-sharepoint-2010-using-iis7/

Stay tuned for the next exciting episode of When SharePoint FBA goes Bad!


One thought on “When SharePoint FBA Goes Bad!–Part 1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s