Configure Forms Based Authentication (FBA) with SharePoint 2010

Configure Forms Based Authentication (FBA) with SharePoint 2010

  • Comments 32
  • Likes

I got requests may times and I thought I should write the steps to configuration of FBA with SharePoint 2010. I have detailed the steps in this blog.

SharePoint 2010 supports FBA, Like WSS 3.0 or MOSS 2007. It's a feature of ASP .Net which we use with SharePoint. SharePoint 2010 you can create web applications using Classic Based Authentication or Claims based Authentication. However, FBA can only be configured with web applications created using Claims Based Authentication.

What are the differences between Classic Mode Authentication and Claims based Authentication?

Classic Mode Authentication: It refers to the integrated windows authentication. You cannot configure the Forms based authentication if your web application is using Classic Mode Authentication. You can convert a web application from Classic Mode Authentication to Claims Based Authentication. However, that can only be done using PowerShell commands and its an irreversible process. I have detailed steps to convert the web application from Classic Mode authentication to Claims Based Authentication.

Claims Based Authentication: SharePoint 2010 is built on Windows Identity Foundation. It enables authentication from windows as well as non-windows based systems. This also provides the capability to have multiple authentication in a single URL.

Configuration of FBA with SharePoint 2010 involves 4 major steps. The steps to configure the FBA with SQL membership Provider are below:

I> Create or Convert existing web applications to use Claims Based Authentication

II> Create User IDs in SQL Database

III> Modify web.config file

IV> Give Permissions to users present in SQL database

Note: If you want to configure FBA with LDAP membership Provider then you can refer TechNet article.

Please find the detailed steps below:

I> Create or Convert existing web applications to use Claims Based Authentication

Note: - Web Application has to be created from the Central Administration console or PowerShell, however it should be using Claims Based Authentication.

A. Creating web application using Central administration

      • Open Central Administration Console.
      • Click on Manage Web application Under Application Management.
      • Click on new on the Ribbon.
      • Chose Claims based Authentication From the top of the page.
      • Choose the port no for the web application.
      • Click on Enable Forms Based Authentication (FBA) Under Claims Authentication Types. Windows Authentication is enabled by default and if you dont need windows authentication then you need to remove the check the box.
      • Add the Membership Provider & Role Manager Name
      • As soon as web application has been created please verify the Authentication Provider settings for the web application. I have the screenshot below:

clip_image002

Note:- If you want to use Windows Authentication and Forms Based Authentication in Single URL then you have to select Enable Windows Authentication and Enable Forms Based Authentication.

image

Note:- Just for understanding, i am using Membership Provider as “SQL-MembershipProvider” and Role Manager as “SQL-RoleManager”. You can use different names, however you need to remember the name so that you can refer them in web.config files. These names are case sensitive.

B. What if you already have a Web application created using Classic Mode Authentication or How to convert Web application from Classic Mode authentication to Claims based Authentication?

You don’t have to delete that web application. You can convert that web application from classic mode authentication to claims based authentication. However this can only be done using PowerShell and it’s an irreversible process. Follow PowerShell commands to convert the web application from Classic Mode Authentication to Claims based Authentication:

$App = get-spwebapplication “URL”

$app.useclaimsauthentication = “True”

$app.Update()

Example:-

$App = get-spwebapplication “http://sp1:8000”

$app.useclaimsauthentication = “True”

$app.Update()

Once you have the web application using Claims Based Authentication, you can create a site collection. Now if you access the web application, you can access the site choosing Windows Authentication or Forms Based Authentication as shown in below image.

clip_image004

Choose windows authentication and login to site. When you login your currently logged in credentials will be used. Make sure the account you are logged in with has access to SharePoint site; Otherwise, you will get access denied error.

II> Configure the Membership Provider and Role Manager.

  • On SharePoint 2010 server open the command prompt.
  • Navigate to C:\Windows\Micrsooft .Net\Framework64\v2.0.50727
  • Run “aspnet_regsql.exe”. This will open ASP .Net SQL Server Setup wizard. On this click on NEXT.

clip_image006

  • Click on “Configure SQL Server for Application Services”.
  • Specify the Database name. If you don’t specify the database name then it will create a database call aspnetdb.

clip_image008

  • Use membershipseeder tool to create the users in SQL database. You can find the tool and information on that from codeplex.

Note:- I have specified the database name as “SQL-Auth”.

III> Modify the web.config file for Membership Provider and Role Manager.

We need to modify 3 different web.config files for FBA to work. Web.config of FBA Web application, web.config of Central Administration Site & Web.config of STS.

A. Modify web.config of FBA web application.

  • Add connection String:

<connectionStrings>

<add name="SQLConnectionString" connectionString="data source=SQL;Integrated Security=SSPI;Initial Catalog=SQL-Auth" />

</connectionStrings>

Connection String has to be added after </SharePoint> and Before <system.web>

  • Add membership Provider and Role Manager:

<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">

<providers>

<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add connectionStringName="SQLConnectionString" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

<membership defaultProvider="i">

<providers>

<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add connectionStringName="SQLConnectionString" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

</system.web>

B. Modify web.config of the Central Administration web application.

  • Add connection String:

<connectionStrings>

<add name="SQLConnectionString" connectionString="data source=SQL;Integrated Security=SSPI;Initial Catalog=SQL-Auth" />

</connectionStrings>

Connection String has to be added after </SharePoint> and before <system.web>

  • Add membership Provider and Role Manager:

<roleManager defaultProvider="AspNetWindowsTokenRoleProvider" enabled="true" cacheRolesInCookie="false">

<providers>

<add connectionStringName="SQLConnectionString" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

<membership defaultProvider="SQL-MembershipProvider">

<providers>

<add connectionStringName="SQLConnectionString" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

C. Modify web.config of STS. You can locate the STS web.config from %programfiles%\common files\Microsoft Shared\web server extensions\14\WebServices\SecurityToken

<connectionStrings>

<add name="SQLConnectionString" connectionString="data source=SQL;Integrated Security=SSPI;Initial Catalog=SQL-Auth" />

</connectionStrings>

<system.web>

<roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">

<providers>

<add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add connectionStringName="SQLConnectionString" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</roleManager>

<membership defaultProvider="i">

<providers>

<add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

<add connectionStringName="SQLConnectionString" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="false" requiresQuestionAndAnswer="true" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</membership>

</system.web>

Above has to be added before </configuration>

IV> Give permissions to users in SQL database.

  • Access Central Administration console and click on manage web applications under Application Management.
  • Select the web application and click on user Policy on ribbon.
  • Click on Add user and select Default Zone.
  • Now type the user name, add the user to the web application by defining appropriate permission.

Common Issues:

If you are using multiple service accounts as per TechNet article Administrative and service accounts required for initial deployment (SharePoint Server 2010) then you might not able to resolve the usernames or add the users to the web application. If you are using 3 different accounts (Farm Administrator account, Application pool account for web application and service application account) then you need to make sure that you have access to the SQL membership database (SQL-Auth).

Important:

What happens to FBA when we upgrade WSS 3.0 / MOSS 2007 to SharePoint 2010?

Before upgrading to SharePoint 2010 you need to remove the changes you have done to the web.config file. As soon as the process of upgrading finishes all the web applications will be upgraded; however, those will use Classic Mode Authentication. You can convert those web applications from Classic Mode Authentication to Claims Based Authentication.

Comments
  • If you want to use ready-made solutions for the management of FBA users, you should take a look here:

    www.devit.eu/.../121-fba-manager-sp2010-forms-based-authentication.aspx

  • If you don't want to go through all those (tedious) steps, use a point-and-click solution and get advanced user management functionality for your extranet users, consider XtraShare for SharePoint: www.rl-soft.com/.../XtraShare_Presentation.pdf

    The current version supports 2007, but the 2010 version is coming soon!

  • I have created my custome Membership Provider. For the User Validate i want to send one more extar parameter witch is application Name. My default provider used for 3 diffrent web applications. So i need to Application Name in my custom membership provider class for passing param to SQL query.

    can you pls guid me....?

  • Good detailed info on configuring FBA entry until the "Common Issues" paragraph. My search for FBA users returns nothing. Is there any way to troubleshoot this?

  • Tim, the problem is that the membershipseeder may not have created a record in the aspnet_Membership table for the user despite creating one in the aspnet_Users table.  

  • Tim,

    Search FBA users...Are you refering to People Search or finding FBA users to give permission?

  • An exception occurred when trying to issue security token:  I am getting this error when followed the above steps.

  • it's awesome ...great work   it's work well in SharePoint 2010........thank u

  • Is there a way to set the password so it doesn't require you to use a special character?

  • Along Tim's thread I am also not able to have the user's show up in the user policy area to add them.  It looks like the membership tables are fine and have the appropriate records added from the membershipseeder.  Any other advice to get around the "Common Issue" ...my windows account is able to hit the aspnetdb

  • Figured out why the users don't show up in the people picker the back way.  First, if you enable windows authentication and forms authentication for your app then you should not use ntlm for windows..use Negotiate (kerberos). Second do the same for the SharePoint Central Admin site of using Negotiate (kerberos)  Third, the people picker stuff also <PeoplePickerWildcards> in the web.config of your app and central admin has keys pointing to an aspnetmemebershipprovider..make sure its the right one....Fourth, I used donalconlon.wordpress.com/.../configuring-forms-base-authentication-for-sharepoint-2010-using-iis7 after bailing on this example. Fifth, I had to change the web config of the sharepoint web services root to match the security token service and had to set default role provider.  All that finally got me going.  

  • Interesting.  One of the features that worked well in SP2007 seems to have been nerfed.  Extending an application in SharePoint 2007, I could enable the extended application for FBA, leaving my intranet application as windows authentication.  What is the implication to domain users if w convert to claims based authentication?

  • How do you manage users. Is there a webpart for SP2010?

  • I think this has something to do with SQL server permissions. Any suggestions.

    At step II above, I get the error:

    An error occurred during the execution of the SQL file 'InstallCommon.sql'. The SQL error number is 262 and the SqlException message is: CREATE DATABASE permission denied in database 'master'.

    Creating the aspnetdb database...

    ----------------------------------------

    Details of failure

    ----------------------------------------

    SQL Server:

    Database: [aspnetdb]

    SQL file loaded:

    InstallCommon.sql

    Commands failed:

    DECLARE @dbname nvarchar(128)

    DECLARE @dboptions nvarchar(1024)

    SET @dboptions = N'/**/'

    SET @dbname = N'aspnetdb'

    IF (NOT EXISTS (SELECT name

                   FROM master.dbo.sysdatabases

                   WHERE name = @dbname))

    BEGIN

     PRINT 'Creating the ' + @dbname + ' database...'

     DECLARE @cmd nvarchar(500)

     SET @cmd = 'CREATE DATABASE [' + @dbname + '] ' + @dboptions

     EXEC(@cmd)

    END

    SQL Exception:

    System.Data.SqlClient.SqlException: CREATE DATABASE permission denied in database 'master'.

    Creating the aspnetdb database...

      at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)

      at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)

      at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)

      at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)

      at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)

      at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()

      at System.Web.Management.SqlServices.ExecuteFile(String file, String server, String database, String dbFileName, SqlConnection connection, Boolean sessionState, Boolean isInstall, SessionStateType sessionStatetype)

  • Got this working in the end, thanks for the blog. One thing worth noting. It's obvious in hindsight but I missed it for a while. In the web.config modification below, the data source need changing from SQL to your actual datasource.

    <add name="SQLConnectionString" connectionString="data source=SQL;Integrated Security=SSPI;Initial Catalog=SQL-Auth" />