Reverting from Claims Authentication to Windows Authentication in SharePoint 2010

[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.]

Sharepoint Tips and Tricks graphicRecently, 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:

SharePoint Screenshot: Authentication Providers set to Claims Based Authentication

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:

SharePoint Screenshot: Authentication Providers now set to Windows Authentication

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:


web.config code is set to: authentication mode = Windows


web.config code is set to: authentication mode = Forms/default

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:

Screenshot excerpt from within SharePoint web application

(the 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: basic migration 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.

Special thanks to my colleague Andy Milsark who helped contribute to this article.

2012-05-10T07:15:53+00:00 May 10th, 2012|


  1. January 14, 2013 at 11:21 pm - Reply

    Your personal posting, “Revert to Windows Authentication in SharePoint 2010” was
    indeed well worth commenting here! Basically wanted to announce you
    did a superb work. Regards -Belinda

  2. Simon January 24, 2013 at 7:18 am - Reply


    Great article!

    I am curious if you have run into any issues since reverting to Claims Based Authentication? I have a client that wants to revert from FBA to Windows Authentication. While I had success after following your instructions in my single-server environment (I used local windows accounts, not AD), I haven’t been able to test every facet of SharePoint to make sure that something, somewhere, isn’t broken. Unfortunately, I do not have the ability to perform proper testing because the client does not have a DEV/TEST environment, nor the ability to replicate their Production environment. Needless to say I am uncomfortable with the idea of forging ahead. I am leaning towards simply removing FBA and sticking with Claims Based Authentication with Windows Authentication enabled, and then migrating all the FBA users to AD users.

    Do you have any suggestions? In hindsight, is there anything you would have done differently? The process seems very straight-forward, but I can’t get out of my head Microsoft’s disclaimer that you cannot revert to Windows Authentication once you go to Claims Based Authentication. I would hope there is a good reason why they say this…



  3. Eric Lough January 24, 2013 at 11:52 am - Reply


    While this article was written using a test environment for demonstration, it did stem from the need to do this in a production environment. The production environment this was performed on was fairly new, so not heavily customized and very much a “vanilla” installation. However, that being said we have not had any adverse reactions to performing this on that production environment. I must stress however that every environment is different and I would be unable to predict if the same would be true for yours. However, if I had any concerns, they would most likely center around any custom developments, and how they use the User accounts, (if they do). For example if you have an application that runs of an Access Database stored in SharePoint, you may need to update your connections to compensate for the change in the username/domainname structure. I wouldn’t see any harm in having both authentication mechanisms, especially on initial roll-out, however would not foresee any harm in switching completely back to Windows Auth. My only advice would be to know what Users have permissions to what, (especially service accounts), as that would be the most likely place to encounter a problem; and in the event you should need to recreate them it will be an easier fix to know what it was beforehand. You do have two “safety nets”, basically, first you can recreate a User if the Move-SPUser process does not work to migrate Users “back in” with the new username/domainname structure and only lose configured Alerts and Permissions. Second Microsoft does not seem to mind moving from Windows Auth to Claims Auth, so the process is reversible. As always, make a copy of the web.config before editing it, and if possible take a quick stsadm or database backup in case something goes really wrong in order to cover all of your bases. Hope this helps!

    P.S. – Thank you for your replies Belinda and Simon and best of luck to you both in your endeavors!

  4. January 26, 2013 at 11:16 pm - Reply

    I actually think this particular post , “Revert to Windows Authentication in SharePoint 2010”, rather compelling not to mention the blog post ended up being a very good read.
    Thanks for your time,Robyn

  5. Pagial July 8, 2014 at 5:59 am - Reply

    Thanks Eric… This saved me a lot of effort. Great post 🙂

  6. Johann Frias July 29, 2014 at 12:10 pm - Reply

    Thanks Eric, this post is awesome!

    I did the steps described in this post and I find some issues with the “Sign in as Different User” menu, every time I do clic in the menu throws an unexpected error.

    Anyone knows how to resolve this issue?

    Thanks in advance!

  7. Eric Lough July 29, 2014 at 1:30 pm - Reply

    @Johann Frias


    I had not noticed this when I performed my variation, and alas that environment is no longer with us as it was a limited test environment.

    Initially, you may try re-running config wizard to see if it will re-establish that function. If that does not work I am afraid it would probably require some coding to return the functionality. If it makes you feel any better, 2013 has this option removed entirely so if worst comes to worst you could present the issue as “preparing for 2013”. The reason this was removed was that it interferes with custom web parts by saving session state and auth cookies. This feature typically will break after switching authentication providers, (such as claims based auth), but some additional theories on how to fix this can be found here:

    An easy, five minute effort however would be to re-run config wizard, (making sure to close out before configuring and DO NOT detach from the Farm), and see if that does the trick. (Also ensure that the User you have logged in with is using the Windows formatted login since that should now be your main authentication method; in the event both are still enabled).

    I hope this helps!

  8. Steven Short August 7, 2014 at 10:50 am - Reply

    Nice job man, this was frustrating me pretty badly 🙂

    Fyi, just:
    $setcba = Get-SPWebApplication “http://YourSiteURL”

    $setcba.UseClaimsAuthentication = 0;


    did the trick for me…

Leave A Comment