Upgrading Forms based auth – SharePoint 2013

I recently upgraded our SanSpug.org and the instructor.architectingconnectedsystems.com sites to SharePoint 2013.  As part of the process, you have to build a new farm and all the web apps, then attach the content dbs.  As long as you have put your membership providers in the machine.config files (32 and 64bit), you shouldn't have any problems right?  Wrong!  With the same config as in 2010, I just kept getting this error:

 An exception occurred when trying to issue security token: The security token username and password could not be validated..

It was looking for the old aspnetdb and localsqlserver settings. Turns out that ASP.NET 4.0 doesn't actually inherit the machine.config file changes.  That was my perferred method in 2010 so I didn't have to put the stupid settings everywhere.  Alas, my nice shortcut doesn't work in 2013 anymore.  You will see that providers don't inherit for the web apps, including the securitytokenservice.  That means you HAVE to put the membership and role providers in the Root web.config file.

I think this sucks…watch out for this…


More Forms Authentication Madness

Every time you apply an update or change some setting in Central Admin, the Root web.config file gets updated to add the <clear/> element back into the providers.  If you are using the machine.config file to propagate your membership settings, then this will be QUITE annoying. 


SharePoint 2010 Forms Authentication Migration (For Developers)

For IT Pros, it is simple to setup the Forms Auth in SharePoint 2010.  However, when a system is migrated to 2010 that uses the Membership Provider generic factory classes extensively…all hell breaks loose!  The class definition for the Membership provider and MembershipUser is here.  After looking at that, consider a piece of code such as:

MembershipUser.ResetPassword("oldpassword", "newpassword");

The default membership provider set in SharePoint 2010 is  "Microsoft.SharePoint.Claims.SPClaimsAuthMembershipProvider".  The main job of this provider is to play an aggregation patten.  Find all username in all available providers and allow you to select them.  It also does some mapping of those users from the internal formats to a human readable format in the SharePoint web sites.  This particular membership provider as advanced as it is…DOES NOT IMPLEMENT ALL THE METHODS OF THE MEMBERSHIP PROVIDER MODELS!

This means if you used the membership methods extensively in your code (forms and web parts) in 2007, it is NOT going to work in 2010 when you migrate!  You will get several different errors around method not implementing and good luck with getting everything to work.  You will need to update your code to specifically call and instanate an instance of the membership providers that have been loaded in the process.  Such as:

MembershipProvider prov = Membership.Providers["AspNetSqlMembershipProvider"]

From there, you would then make the appropriate calls in your forms and web parts using the defined provider variable.

Good luck with the code migration!  And reference my other blog about other forms based auth migration issues here!

SharePoint 2010 Claims based Forms Authentication

Forms based authentication in SharePoint 2010 has changed.  It is now Claims based Forms Authentication, which means all the forms configuration stuff you see all over the web doesn't quite work in the same way.  Even if you set the membership and role providers in your web
applications and central administration you forms auth still won't work!

In SharePoint 2010, several new WCF services will be handleing the mapping of the claims to the backend forms auth identities.  Out of the box, claims based forms auth doesn't work!  You gotta remove the <clear/> element from the Membership and Role provider sections in the web.config of the {SharePoint Root}WebServicesRoot.