Mixing it up w/ Mixed SSL & SP 2010

The following is a post written by Tim Nugiel with instructions for creating a custom cookie handler for mixed mode authentication.  I reference it in my blog post Mixed Http and Https Content with SharePoint 2010. The original article was posted at: http://www.msngn.com/blog/lists/posts/post.aspx?id=5. I’ve reposted it here, as the original article appears to have gone offline.

 

Here is some very good reading if you want to learn more on the inner workings of federated authentication models w/ claims & sp2010:
http://msdn.microsoft.com/en-us/library/ee517293.aspx
So after much digging with firebug + the Firefox webdev extension to inspect my http sessions, I discovered 2 funny things about the cookie SharePoint is setting

1) It ignores most of the settings we put in our <forms tag and uses its own (see below)

2) No matter what attributes I set, the cookie was being written as a secure cookie, which prevented it from being transmitted via non-secure http requests
ssl_securecookie.png
I inspected the web.config some more and discovered that SharePoint is using a custom cookie handler to read/write cookies:

<cookieHandler mode="Custom" path="/">
<customCookieHandler type="Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</cookieHandler>?

Enter Reflector:

once I opened up this class in reflector and traced the life of a cookie during an authentication session, it turned out that there was a hardcoded reference to the https protocol in the WriteCore method – this was trumping any of the manual settings we were trying to add in the web.config

ssl_reflector.png

The Fix:
 
Fortunately a custom cookie handler class is not that complex, so I created a new MSNGNChunkedCookieHandler class and updated the web.config entry
 
<cookieHandler mode="Custom" path="/" requireSsl="false" > 
 <!-- <customCookieHandler type="Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler, Microsoft.SharePoint.IdentityModel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> -->
 <customCookieHandler type="MSNGN.Utility.MSNGNChunkedCookieHandler, MSNGN.Utility, Version=1.0.0.0, Culture=neutral, PublicKeyToken=38c82c65bfb6cec0" />
 </cookieHandler>

This class invokes its base methods for the most part, I just slightly modified the WriteCore event w/ logic that removes the https hard coded reference.

using System;
using System.Web;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.IdentityModel;
using Microsoft.IdentityModel.Web;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint.Administration.Claims;
 
namespace MSNGN.Utility
{
 /// <summary>
 /// This is an override of the Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler class
 /// with the WriteCore method extended to support both Secure & Non-Secure cookies
 /// </summary>
 public class MSNGNChunkedCookieHandler : Microsoft.SharePoint.IdentityModel.SPChunkedCookieHandler
 {
 
 private ChunkedCookieHandler m_CookieHandler;
 
 public MSNGNChunkedCookieHandler() : base()
 {
 this.m_CookieHandler = new ChunkedCookieHandler();
 this.m_CookieHandler.Path = "/";
 }
 
 public MSNGNChunkedCookieHandler(int chunkSize) : base(chunkSize)
 {
 this.m_CookieHandler = new ChunkedCookieHandler(chunkSize);
 this.m_CookieHandler.Path = "/";
 }
 
 protected override void DeleteCore(string name, string path, string domain, HttpContext context)
 {
 base.DeleteCore(name, path, domain, context);
 }
 
 protected override byte[] ReadCore(string name, HttpContext context)
 {
 return base.ReadCore(name, context);
 }
 
 /// <summary>
 /// Override of the WrieCore method to remove hard coded secure cookie flag
 /// which is required to support both http & non-http sessions
 /// </summary>
 protected override void WriteCore(byte[] value, string name, string path, string domain, DateTime expirationTime, bool secure, bool httpOnly, System.Web.HttpContext context)
 {
 //override the secure cookie setting
 //to enable both https & non https cookie sessions
 secure = false;
 
 if (context == null)
 {
 throw new ArgumentNullException("context");
 }
 if (context.Request == null)
 {
 throw new ArgumentException(null, "context");
 }
 if (null == context.Request.Url)
 {
 throw new ArgumentException(null, "context");
 }
 
 //if (string.Equals(context.Request.Url.Scheme, "https", StringComparison.OrdinalIgnoreCase))
 //{
 // secure = true;
 //}
 //else
 //{
 // secure = false;
 //}
 if (!string.Equals(path, "/", StringComparison.OrdinalIgnoreCase))
 {
 path = "/";
 }
 this.m_CookieHandler.Write(value, name, path, domain, expirationTime, secure, httpOnly, context);
 
 
 }
 
 }
}

InfoQ FBA Pack Interview

I was recently interviewed about the FBA Pack by Jonathan Allen of InfoQ.  The interview is here:

http://www.infoq.com/news/2014/05/SharePoint-FBA

Shufflrr is Being Introduced at the NY Tech Meetup

Shufflrr

Shufflrr is a PowerPoint presentation management web app that I’ve been working on for the past year. This Tuesday, April 1st at 7:00 PM, Shufflrr will be introduced to the world at the NY Tech Meetup.

Link to the meetup and live video stream of the presentation here:
http://nytm.org/blog/entry/14-27-2014/lineup-for-april-1-ny-tech-meetup

Link to Shufflrr:
http://www.shufflrr.com/

Amazon EBS CrystalDiskMark Benchmarks – EBS Standard vs Provisioned IOPS

I recently set up a provisioned IOPS EBS volume on Amazon EC2.  I decided to run CrystalDiskMark against it to see how it compared to a standard EBS volume in terms of performance.  I wanted to know if provisioned IOPS is worth the extra money that you pay for it.  Here are the results:

EBS Standard

Volume Size: 100GB
Server: c3.large
OS: Windows Server 2012

CrystalDiskMark - EBS Standard

———————————————————————–

CrystalDiskMark 3.0.3 x64 (C) 2007-2013 hiyohiyo

Crystal Dew World : http://crystalmark.info/

———————————————————————–

* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 59.218 MB/s

Sequential Write : 34.096 MB/s

Random Read 512KB : 59.173 MB/s

Random Write 512KB : 33.581 MB/s

Random Read 4KB (QD=1) : 7.792 MB/s [ 1902.2 IOPS]

Random Write 4KB (QD=1) : 3.165 MB/s [ 772.7 IOPS]

Random Read 4KB (QD=32) : 60.193 MB/s [ 14695.5 IOPS]

Random Write 4KB (QD=32) : 10.020 MB/s [ 2446.2 IOPS]

Test : 1000 MB [C: 46.3% (46.2/99.7 GB)] (x5)

Date : 2014/03/31 5:59:00

OS : Windows Server 2012 Server Standard (full installation) [6.2 Build 9200] (x64)

EBS Provisioned IOPS

Volume Size: 100GB
Provisioned IOPS: 3000
Server: c3.4xlarge (EBS-Optimized)
OS: Windows Server 2012

CrystalDiskMark - EBS Provisioned IOPS

———————————————————————–
CrystalDiskMark 3.0.3 x64 (C) 2007-2013 hiyohiyo
Crystal Dew World : http://crystalmark.info/
———————————————————————–
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 50.116 MB/s
Sequential Write : 50.102 MB/s
Random Read 512KB : 50.121 MB/s
Random Write 512KB : 50.121 MB/s
Random Read 4KB (QD=1) : 12.634 MB/s [ 3084.6 IOPS]
Random Write 4KB (QD=1) : 8.028 MB/s [ 1959.9 IOPS]
Random Read 4KB (QD=32) : 12.534 MB/s [ 3060.1 IOPS]
Random Write 4KB (QD=32) : 12.534 MB/s [ 3060.2 IOPS]

Test : 1000 MB [C: 55.5% (55.3/99.7 GB)] (x5)
Date : 2014/03/31 5:57:08
OS : Windows Server 2012 Server Standard (full installation) [6.2 Build 9200] (x64)

Conclusion

Although EBS Provisioned IOPS does appear to almost always guarantee consistency in throughput, it also prevents you from attaining the maximum available speeds available through bursting.

Write performance on EBS is considerably slower than read performance.  If you perform a lot of writes, Provisioned IOPS can really help.

If you are going to purchase a provisioned IOPS volume, provision 3000+ IOPS, or you’re likely to get better performance on average with EBS standard.

Unfortunately EBS Provisioned IOPS is not a magic bullet for increased IO performance, only consistency.  No matter which type of EBS volume you choose, it’s going to be slow.

SharePoint 2013 FBA Pack Released

SharePoint 2013 FBA Pack Manage Users

The SharePoint 2013 FBA Pack has been released. It was ported from the SharePoint 2010 FBA Pack (which was originally ported from the SharePoint 2007 CKS Forms Based Authentication Solution), and includes all of the features from the SharePoint 2010 FBA Pack:

  • User Management
  • Role Management
  • Membership Request Web Part
  • Password Recovery Web Part
  • Change Password Web Part
  • Change Password Menu Item

Go and grab it!

Configuring Forms Based Authentication in SharePoint 2013 – Part 4 – Configuring SharePoint

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 1 – Creating the Membership Database

Part 2 – Adding Users to the Membership Database

Part 3 – Editing the Web.Config Files

Part 4 –  Configuring SharePoint

Part 4 –  Configuring SharePoint

Now that the membership and role provider have been configured, we can configure SharePoint to use them.  For this example i’m going to create a new SharePoint web application.  The same settings can be applied to an existing web application through the Authentication Providers dialog.

  • Open SharePoint Central Administration -> Application Management -> Manage Web Applications.
  • Click “New” to create a new Web Application.sharepoint_2013_fba_web_application_1
  • Name the web application and adjust any other options to your preferences.sharepoint_2013_fba_web_application_2
  • 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.sharepoint_2013_fba_web_application_3
  • An Application Created dialog will appear. Click the “Create Site Collection” link to create the first site collection for this web application.sharepoint_2013_fba_web_application_4
  • From the Create Site Collection dialog, give the site collection a name and URL and select a template.sharepoint_2013_fba_web_application_5
  • 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.sharepoint_2013_fba_web_application_6
  • 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.sharepoint_2013_fba_web_application_7
  • 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.sharepoint_2013_fba_login_1
  • 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.sharepoint_2013_fba_login_2
  • You’re now logged into the site as a site collection administrator.sharepoint_2013_fba_login_3

That’s it! Now you can authenticate to the site with Forms Based Authentication. You can also create and edit users using the methods discussed in Part 2. Be sure to check out the SharePoint 2013 FBA Pack, which will allow you to manage your forms based users directly within SharePoint, as well as provide methods for users to register, change their password and recover their password.

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 1 – Creating the Membership Database

Part 2 – Adding Users to the Membership Database

Part 3 – Editing the Web.Config Files

Part 4 –  Configuring SharePoint

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.

BEFORE EDITING ANY .CONFIG FILE – MAKE A BACKUP OF IT. It’s very easy to make a typo.

  • Navigate to “C:\Windows\Microsoft.Net\Framework64\v4.0.30319\Config” and open “machine.config”.sharepoint_2013_fba_config_1
  • 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.sharepoint_2013_fba_config_2

  • 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.

    sharepoint_2013_fba_config_3

  • 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.
    sharepoint_2013_fba_config_3_1

  • 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.sharepoint_2013_fba_config_4
  • 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.

    sharepoint_2013_fba_config_5

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.

Configuring Forms Based Authentication in SharePoint 2013 – Part 2 – Adding users to the Membership Database

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, so if you already have an existing membership database setup from a previous version of SharePoint, feel free to skip forward to Part 3.

Part 1 – Creating the Membership Database

Part 2 – Adding Users to the Membership Database

Part 3 – Editing the Web.Config Files

Part 4 –  Configuring SharePoint

Part 2 – Adding Users to the Membership Database

Now that we’ve created an empty membership database, we need to add some users to it that can be used to login.  You have a couple of options for doing this.  If you’d like to do all of your user management in SharePoint, then you can install the SharePoint 2013 FBA Pack and skip to Part 3. If you’d like to be able to manage the users outside of SharePoint, and setup some inital users, then continue on to learn how to manage the FBA users with IIS.

To manage users in IIS, we’re going to create a dummy site just for managing users.  In SharePoint 2010 and earlier it was possible to edit the users directly from a SharePoint web application site, as long as the default membership provider was set to the membership provider you were going to edit. This is no longer possible, as previous versions of SharePoint ran against ASP.NET 2.0 (3.5), but SharePoint 2013 runs on ASP.NET 4.0.  IIS does not support editing users and roles for ASP.NET 4.0 applications. To get around this, we’ll create a dummy/blank ASP.NET 2.0 web site just for editing users. The asp.net 2.0 and 4.0 membership databases are exactly the same, which makes this possible.

NOTE: These directions were created on Windows 2008 R2.  On Windows 2012 they have reversed things and the .Net Users and .Net Roles options are only available for .Net 4.0 and are not available for .Net 2.0 – So on Windows 2012 please use .Net 4.0 where 2.0 is mentioned in the directions.

  • Open IIS.
  • Right click on Sites and select “Add Web Site…”sharepoint_2013_fba_edit_users_1
  • A configuration dialog will appear. Just give it a meaningful name, point it to an empty folder and give it a random unused port number and click OK.sharepoint_2013_fba_edit_users_2
  • Click on “Application Pools”. An application pool of the same name should have been created. The .Net Framework for that application pool should show as “2.0″.  If it doesn’t, you’ll need to modify it’s settings and change it to “2.0″.sharepoint_2013_fba_edit_users_3
  • You’ll also have to set the identity the account runs as to the same as SharePoint, so that it will have permissions to read and write to the membership database. Select the application pool and click “Advanced Settings…” in the right panel. In the dialog that comes up, click on the Identity to change it. Choose “Custom account” and enter the SharePoint service account username and password. Click OK on all of the open dialogs to close them.sharepoint_2013_fba_edit_users_4
  • The identity should now match the identity used for the SharePoint application pools.sharepoint_2013_fba_edit_users_5
  • We’re now going to create a database connection to the membership database. Select your new site and open the “Connection Strings” page from the Features view.sharepoint_2013_fba_edit_users_6
  • From the Connection Strings page, click “Add…” on the right side panel. On the Add Connection String dialog that appears, give it a name (I used “FBADB”), enter your server name and enter “aspnetdb” for your database name. Select “Use Windows Integrated Security” and click OK. We’ve now created the database connection.sharepoint_2013_fba_edit_users_7
  • We’re now going to create the membership provider, that will let us edit users in the membership database. From the site Features view, click “Providers”. (If “Providers”, “.Net Users” and “.Net Roles” is missing from the features view, then the associated application pool is configured for .Net 4.0. Go back and configure it for .Net 2.0).sharepoint_2013_fba_edit_users_8
  • From the Providers page, select “.Net Users” under Feature. Click “Add…” in the right side panel. In the dialog that appears, chose “SQLMembershipProvider” for type. Give it a name. For this example I used FBAMembershipProvider_2_0.  I added the _2_0 so as not to confuse it with the “FBAMembershipProvider” entry we will be creating when we set it up for SharePoint. Select the different options you want associated with your membership provider.  I have some more detail on the options available in the next section when we setup the membership provider for SharePoint. One thing I must stress though is that the options you pick here MUST match the options you use when you setup the membership provider for SharePoint. If they don’t, the users you create here will not work properly.For options, I chose:
    Option Value
    EnablePasswordReset True
    EnablePasswordRetrieval False
    RequiresQuestionAndAnswer False
    RequiresUniqueEmail True
    StorePasswordInSecureFormat True
    ConnectionStringName FBADB (This must match the database connection we setup earlier)
    ApplicationName /

    Click OK to close the dialog and create the membership provider.

    sharepoint_2013_fba_edit_users_9

  • We’re now going to add users to the membership database. Click “.Net Users” from the Features view.sharepoint_2013_fba_edit_users_11
  • The first thing we have to do before we can create users is configure the default membership provider. Click “Set Default Provider…” in the right side panel.  When the dialog appears, choose the membership provider we just created and click OK.sharepoint_2013_fba_edit_users_12
  • Now that the default membership provider is selected, we’re presented with an empty .Net Users page, as there are not yet any users in the database. Click “Add…” in the right side panel to add a user.sharepoint_2013_fba_edit_users_13
  • From the “Add .Net User” dialog, give the user a name, email and password. In this example i’m creating an admin user that i’m going to use as the SharePoint Site Collection administrator.The password needs to be at least 7 characters long and must contain at least 1 non-alphanumeric character. Since we set RequiresQuestionAndAnswer to false when configuring the membership provider, the Question and Answer fields can be left blank.Click OK to create the user and close the dialog.sharepoint_2013_fba_edit_users_14
  • Now the .Net Users page lists the one user you have created. You can use this page to add and edit users in the future.sharepoint_2013_fba_edit_users_15
  • If you are going to use Roles in SharePoint, you can create a Role provider from the Providers page, and then use the .Net Roles page to add roles – very similar to how we added the membership provider and added users.sharepoint_2013_fba_edit_users_10

Now that we’ve added a user to our membership database, you can continue on to Part 3 to learn how to configure the membership provider for SharePoint.

Configuring Forms Based Authentication in SharePoint 2013 – Part 1 – Creating the Membership Database

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, so if you already have an existing membership database setup from a previous version of SharePoint, feel free to skip forward to Part 3.

Part 1 – Creating the Membership Database

Part 2 – Adding Users to the Membership Database

Part 3 – Editing the Web.Config Files

Part 4 –  Configuring SharePoint

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”sharepoint_2013_fba_1
  • A welcome screen will appear. Click Next.sharepoint_2013_fba_2
  • Select “Configure SQL Server for application services” and click Next.sharepoint_2013_fba_3
  • 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”.sharepoint_2013_fba_4
  • A Confirm Your Settings screen will appear. Click Next.sharepoint_2013_fba_5
  • A “database has been created or modified” screen will appear. Click finish and the wizard will close.sharepoint_2013_fba_6
  • 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.sharepoint_2013_fba_7
  • 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.sharepoint_2013_fba_8
  • 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’.sharepoint_2013_fba_9
  • 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.sharepoint_2013_fba_10

Continue to Part 2 – Adding Users to the Membership Database.

SSD Freezing Fix

A while back I picked up an SSD to speed up my laptop. It worked great – I got a nice improvement in speed, especially when running virtual machines, which I use regularly. I’d really recommend it as an upgrade.

Although it worked great 99% of the time, I ran into an issue where the system would completely freeze for about 1 minute (with the hard drive access light on) and then would return to normal. This would happen every 3 or 4 days. I had heard of freezing issues with SSD’s before purchasing mine, but I assumed this was a thing of the past. Apparently not.

It took a lot of searching (which is why I am reposting it here), but I eventually found a fix:

http://forum.crucial.com/t5/Solid-State-Drives-SSD/Solution-C300-Disk-Freeze-ups-in-Windows-7-solved-for-me/td-p/38766

Essentially the issue is an incompatibility with the LPM (Link Power Management) feature of Intel SATA controllers. LPM is a power saving feature. Considering the prevalence of Intel SATA controllers, I’m really surprised that Crucial didn’t catch this before they shipped their drives, or at least didn’t have a firmware fix available shortly after shipping.

To fix the issue, LPM needs to be disabled. It can be disabled with a registry change:

  • Open up notepad and copy the following into it:
 Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port0]
 "LPM"=dword:00000000
 "LPMDSTATE"=dword:00000000
 "DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port1]
 "LPM"=dword:00000000
 "LPMDSTATE"=dword:00000000
 "DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port2]
 "LPM"=dword:00000000
 "LPMDSTATE"=dword:00000000
 "DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port3]
 "LPM"=dword:00000000
 "LPMDSTATE"=dword:00000000
 "DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port4]
 "LPM"=dword:00000000
 "LPMDSTATE"=dword:00000000
 "DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port5]
 "LPM"=dword:00000000
 "LPMDSTATE"=dword:00000000
 "DIPM"=dword:00000000
 
  • Save the file as “fixssd.reg”.
  • Double click the saved file.
  • You will get a User Account Control prompt asking if you want “Registry Editor” to make changes to your computer. Click “Yes”.
  • You will get a Registry Editor prompt confirming you want to make changes. Click “Yes”.
  • You will get a success message. Click “OK”.
  • Reboot your machine.

SSD freezes should now be a thing of the past!

Notes

I have a Crucial M4 512 MB drive (M4-CT512M4SSD2) running on a Lenovo T500 ThinkPad. It’s running the 000F firmware. This issue could potentially be fixed with a newer firmware that wasn’t available when I solved my problem. At the time of writing, firmware revisions 010G and 040H are available. Firmware 010G includes the following fixes, which sound promising:

  • Improved resume-time from low power modes, and improved reliability of warm reboot
  • Improved power consumption by disabling HIPM (Host Initiated Power Management)

Although I am running a Crucial SSD, I expect the issue has to do more with the controller than the manufacturer of the drive itself. The Crucial M4 drives use a Marvell controller. The following companies (and probably a few others) also produce drives using Marvell controllers, so this fix could potentially apply to them as well:

  • Corsair
  • Plextor
  • OCZ