Planning and Configuring Extranets in SharePoint 2010–Part 2

In Part 1 of this series, we walked through creating of the actual databases for managing our FBA users, as well as the general scope of this blog series. Today, we are going to focus on the configuration of SharePoint [insert crowd roar here]. Ok, ok, I know you are excited, this however, is the hardest part IMHO, so, please pay attention, and try to color inside the lines to the best of your ability while we are following this exercise.

Membership and Role Providers

First, let us do a quick definition of what these are.

Membership Providers are the authentication sources for applications. A provider can be a number of back ends (LDAP, SQL, 3rd party application, or a custom membership provider). In our specific case here, we are using SQL, specifically, the ASP.NET Membership Database. If you look at the tables we created in Part 1, you can see how this provider stores a username, password, and other information about the user. Just like active directory, it can hold information about a user, and also be used for authentication.

Role Managers are similar to membership providers, however, these are more like groups in Active Directory. A person in the membership provider can belong to a number of different roles, or groups. We will be configuring these as well.

So, hopefully the brief introduction to these terms above is enough to make sense, so we can move onto our next bit.

At this point, they do not need to have a name. We can name them whatever we’d like to. So, we will use:

• Membership Provider: SQL-MembershipProvider
• Role Manager: SQL-RoleManager

Extending our Web Application with Claims Based Authentication

Now that we have our database up and running, we need to extend our web application in SharePoint 2010, so that we can create an FBA-Only authentication portal, for our partners at Contoso to access.

To do so, we need to enable Claims Based Authentication on our site, because it is already created, we need to enable our existing site to be “Claims aware”.

Note: a great blog on configuring Claims Based Authentication can be found here: http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx] I’ve relied heavily on that article in the past, so you will see a lot of the same information in this article as you will see in my reference above. This is not a swipe of that article, it is more of a homage 🙂

Extending the Web Application and Enabling Claims Authentication

To do so, go into Central Administration.

In Central Administration, go to Application Management > Manage web applications, and click on the site you would like to extend. In this example, I will be using the Intranet site within the SharePoint 2010 Information Worker demo image. Click on that site

And then click on Extend up in the Ribbon.

Now, time to configure the extended site. Give it a name, port, etc. (If you give it a DNS name, make sure you add in a DNS entry!)

Then select the Extranet zone. This doesn’t do anything but classify the extended web application, and allow us to modify the authentication methods used. Then click OK.

Now, once we have done that, you will notice, if you keep the web application selected in the list, click on Authentication Providers in the Ribbon, and then click on Extranet

You will notice that we cannot change the authentication type from Windows to Forms.

Don’t worry, we have a fix for that. To convert the web application from Classic Authentication to Claims Based Authentication, open up the SharePoint 2010 Administration Console (PowerShell – as an administrator)

   1: $webApp = Get-SPWebApplication http://extranet

   2: $webApp.UseClaimsAuthentication = "true"

   3: $webApp.Update()

This will enable Claims authentication on our web application.

Now if we click on Authentication Providers on the ribbon again, you can see that they now show up as Claims Based Authentication

Click on the Extranet again, you will now see that we can change the authentication type for this web application. If you want to have both AD users as well as FBA users to be access the same portal with their respective accounts, go ahead and check both Enable Windows Authentication as well as Enable Forms Based Authentication. Remember how I listed the Membership Provider and the Role Manager at the beginning of this article? Now is when I make use of those.

Note:  If you want to create a custom login page, you can specify that option from here (right below the Claims Authentication Types section). Maybe in an addendum to this article down the road I will write a quick post on how to do that. It’s easy, but, this article is more IT Pro/Admin focused, so we’ll skip that for now 🙂

Now go to the bottom and click on Save.  SharePoint will deal with the configuration of this web application.

Extranet Web Application Configuration

Our next item of concern is the configuration for the extranet. We need to re-configure the web.config settings for this extended web application. To do so, open the web.config file for the extranet web application, in my example, it is located at (C:\inetpub\wwwroot\wss\VirtualDirectories\extranet80\web.config)

Search for </SharePoint>, which should appear right before <system.web>, and insert the following code, after </SharePoint>, and before <system.web>.

   1: <connectionStrings> 

   2:   <add name="SQLConnectionString" connectionString="data source=DEMO2010A;Integrated Security=SSPI;Initial Catalog=aspnetdb" /> 

   3: </connectionStrings>

And where the two highlighted bits are above, insert your SQL server name, and FBA database name respectively. (see Part 1 for creating this database).

Once that is complete, locate the end of the </system.web>, mentioned above, where we just put the connectionStrings information above. It will be right above </system.webServer>. there are many other system.web declarations within this file, so be sure to use the right one. You should see tags in the XML for membership and rolemanager there.

We will leave these AS-IS! No need to modify those lines. Now, we need to add the following code within the <providers> and </providers> tags within the <membership> element, as directed in the image below

   1: <add connectionStringName="SQLConnectionString" 

   2: passwordAttemptWindow="5" 

   3: enablePasswordRetrieval="true" 

   4: enablePasswordReset="true" 

   5: requiresQuestionAndAnswer="true" 

   6: applicationName="/" 

   7: requiresUniqueEmail="true" 

   8: passwordFormat="Hashed" 

   9: description="Stores and Retrieves membership data from SQL Server" 

  10: name="SQL-MembershipProvider" 

  11: type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

Make sure that the connectionStringName and name attributes match the connection string we used above, as well as the membership provider name we used in SharePoint respectively.

Next, the piece of xml we are going to use will fit in between the <providers> and </providers> tags within the <roleManager> element, as directed in the image below

   1: <add connectionStringName="SQLConnectionString" 

   2: applicationName="/" 

   3: description="Stores and retrieves roles from SQL Server" 

   4: name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> 

again, making sure that the connectionStringname and name attributes match the connection string we used above, as well as the role manager name we used in SharePoint respectively.

Then save the web.config file.

Central Administration Web Application Configuration

We now need to modify the Central Administration web.config file as well. In our example here, our Central Admin web.config file is located at: C:\inetpub\wwwroot\wss\VirtualDirectories\44535\web.config

We will be editing in the same places within the config file that we did for our extranet web application above, but with just a few slight changes.

So, first, locate the closing </SharePoint> tag, and the opening <system.web>. Just as we did above, we are going to paste in our connection strings here.

   1: <connectionStrings> 

   2:   <add name="SQLConnectionString" connectionString="data source=DEMO2010A;Integrated Security=SSPI;Initial Catalog=aspnetdb" /> 

   3: </connectionStrings> 

And next, as you may have guessed, just before we close out the </system.web> tag in this web.config, we need to put in our membership provider and role information. This is slightly different from the one we used for the extranet web.config above, notice the default membership provider. Don’t change this – leave this as-is. It is NOT a typo.

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

   2:   <providers> 

   3:     <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" /> 

   4:   </providers> 

   5: </roleManager> 

   6: <membership defaultProvider="SQL-MembershipProvider"> 

   7:   <providers> 

   8:     <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" /> 

   9:   </providers> 

  10: </membership> 

Security Token Web Service Application Configuration

Last, but certainly not least, we must also update the web.config for the SecurityToken service.

Within your SharePoint Root folder, under WebServices\SecurityToken (generally found at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken), you will find another web.config file. Before the end <configuration> </configuration> section, add in the following… again, tailored to your configuration which we have specified above.

   1: <connectionStrings> 

   2:     <add name="SQL-ConnectionString" connectionString="data source=DEMO2010A;Integrated Security=SSPI;Initial Catalog=aspnetdb" /> 

   3: </connectionStrings> 

   4: <system.web> 

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

   6:         <providers> 

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

   8:             <add connectionStringName="SQL-ConnectionString" 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" /> 

   9:         </providers> 

  10:     </roleManager> 

  11:     <membership defaultProvider="i"> 

  12:         <providers> 

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

  14:             <add connectionStringName="SQL-ConnectionString" 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" /> 

  15:         </providers> 

  16:     </membership> 

  17: </system.web>

Once you do that, it would be healthy to restart IIS as well (just humor me on this one, while not required, as changes to the web.config will cause the application pools to recycle, I’ve seen issues where a reset to IIS has been known to do good).

And lastly, once you visit your site, you should get one of these nice choice boxes:

You should be configured, and ready to roll!

Now stay tuned for Part 3… get access to this test environment!