[Editor’s Note: This information is provided as-is and is ONLY recommended for a testing environment. Never perform this setup in a SharePoint production environment without extensive prior planning and testing.]
Recently, I found myself in a situation that required me to move a SharePoint 2010 Web Application from Claims Based Authentication to Windows Based Authentication. Searching online for tips on how to do this yielded few results other than Microsoft says this cannot or should not be done.
Well, I’m someone who has to prove this the hard way, so I tried anyways; and with a little help was actually successful. And if I’m being honest, it wasn’t even as large an undertaking as I thought it would be.
I’ll walk you through the process, but as stated above, please don’t perform this in a production environment.
So, here’s how I did it: First we can see that a Web Application is in Claims Auth through Central Administration, using the Authentication Providers as seen below:
Now, I did manage to find some helpful Powershell script that will “revert” Claims to Windows, and ran this using Powershell ISE. The script can be seen below:
$setcba = Get-SPWebApplication "http://YourSiteURL"
$setcba.UseClaimsAuthentication = 0;
This will set the Authentication Provider to Windows Authentication, but is a bit misleading as this is the only place it changes it. This means that we aren’t even close to finished yet.
Take a look below to see that in the last step, we were able to change the Authentication Provider:
However, the Web Application still doesn’t “know” that it has been changed in its configuration. To update this, we’ll head to the web.config file for this Web Application. To change this successfully let’s compare a web.config file of a Windows Authenticated Web Application to that of a Claims Based, as seen below:
So we can see above that the web.config now needs to be altered to use Windows Auth, and we’ll do so by simply plugging in the correct value. Now a quick IIS reset will reload the web.config and we are almost back in business.
You may notice that you can no longer login to the site. This is because of how the User table in SharePoint has recorded the Users. They will still be in the site, but in Claims format as seen below:
I:0#.w| portion signifies Claims Authentication)
We will need to add the “Windows” version of the account, (in this case Elow\Sp_Search), back into the site. Depending on how many Users you have, this can be quite tedious. First, you will want to re-add the appropriate Users into the Policy for Web Application, which is found on the same page as the Authentication Provider in Central Administration.
Now, for the Users added to the Site Collections, we will need to “migrate” the Users into themselves using Powershell. You can also re-add them manually, but then you would lose any Alerts or Permissions assigned to the User. By migrating the Users from their Claims based format into the Windows format, you will be able to keep your Users’ configurations intact.
If you need help migrating Users, you can find many articles concernting this topic, but below are a couple that I found in five minutes of Google searching:
http://blog.helloitsliam.com/Lists/Posts/Post.aspx?ID=54: basic migration
http://blog.sharepoint-voodoo.net/?p=68: A unique scripted migration function that I have yet to test but seems promising.
Hopefully this saves you some time and/or effort, and if you have any questions, please don’t hesitate to leave a comment. As always, thanks for reading.