SharePoint serendipity is the effect by which one accidentally discovers something fortunate, especially while looking for something else entirely. In this case, it is the occassional musings, observations, and Ouija board readings about the phabulously

Migrating from Windows Classic Auth to Windows Claims Auth in SharePoint 2010 Part 2

Migrating from Windows Classic Auth to Windows Claims Auth in SharePoint 2010 Part 2

  • Comments 21
  • Likes

NOTE:  UPDATED 1/8/2011

I wanted to follow-up on the previous post about migrating authentiation types in SharePoint 2010 that was done here:  I still recommend taking a look at that posting if you haven't already because it includes some good background information about the migration process.  Recently we've been tweaking with the set ot steps to migrate authentication types and having more success than previously so I wanted to share those steps.  These may or may not become the final steps, but it's a pretty good start. 

UPDATED INFO:  Folks, one of the things we discovered is that at least one of the issues we were seeing post-migration can be solved if the account that is running the PowerShell commands described below is a) a local administrator on the server where the commands are being run and b) is added to a Full Control web app policy on the web application that is being migrated.  The script below already created a Full Control web app policy so I've just updated it to indicate that the user running the script should be used.

So here are the steps:

$WebAppName = "http://yourWebAppUrl"

$account = "yourDomain\yourUser"

$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
# this will prompt about migration, CLICK YES and continue

#This step will set the admin for the site
$wa = get-SPWebApplication $WebAppName
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()

#Once the user is added as admin, we need to set the policy so it can have the right access
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")

#Final step is to trigger the user migration process
$wa = get-SPWebApplication $WebAppName

There are a couple of things that may still be a problem for you after doing this that you'll want to take care of or be aware of:

  1. You may find that users cannot log into the site.  You enter your credentials and it says you are domain\user but you don't have access rights.  If you see that then it's likely you have configured the portalsuperuseraccount and portalsuperreaderaccount properties of the web application prior to migration.  You need to go back and change them to use the new claims-based account name.  You can get that by looking at the web application policy for the web app after migration and copying from there.  Note that if you are not working with publishing sites then adding these accounts to the web app properties may in fact block you from logging into a site, like a team site.  Yeah I know, this remains fairly odd and confusing.
  2. Existing alerts may not fire.  Right now the only work-around I've seen is to delete and recreate them.
  3. Double-check the web application policies and make sure that the search crawl account shows the new converted account name.  If it doesn't, you will need to manually create a new policy for the crawl account.

If you follow these steps and use these troubleshooting tips you should be good to go in most cases.



  • Hi,

    I'm having the issue you described in the item number 1. But I don't understand what you mean by "portalsuperuseraccount and portalsuperreaderaccount "

  • Same problem here - users can not log in, although they have permissions.

    Could you please clarify, what you mean by configuring the "portalsuperuseraccount" and "portalsuperreaderaccount"?

    Thanks in advance!

  • Souhil and Stephan:

    By default there are two separate accounts (portalsuperuseraccount and portalsuperreaderaccount) that are used for caching and by default portalsuperuseraccount  account is System Account and for the portalsuperreaderaccount it is NT Authority\Local Servicethese accounts will work for web application in classic mode but will not work for claims and might result in acess denied errors so thats what Steve meant i.e. to change it. Use the following command to change it (there is powershell equivalent also)

    stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue accountname -url http://fqdn

    stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue accountname -url http://fqdn

  • Hi  Ketan,

    i have followed ur  stsadm cmds ,   after applying  this  cmds and iis reset.

    when i tried to login with windows authentication, i am UNABLE TO DO SO.i am not getting any prompt for  entering AD CREDENTIALS.

    and WHEN I SELECT THE FORMS  AUTH. DROPDODOWN ITEM I was navigated to the  defaiult Signin page and when i give the SUPERUSERREADERACOUNT name , i am getting the below error:


    The user does not exist or is not unique.

    Troubleshoot issues with Microsoft SharePoint Foundation.

    Correlation ID: 75e66a48-6c32-4106-b990-733dbdb2e445

    Date and Time: 11/25/2010 12:14:27 AM

    Go back to site


    pls help why i am unable to login to both windows and forms after  migration from cassic  mode to  claims mode.

    i have used custom mebmship provider and role provider and entered the entries in the auth provider s section in the CA -->FBA section.

  • I tried these commands but get access is denied when I run this command

    Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default

    I made sure that I was an administrator on the server as well as dbo on the SQL tables.

    Any ideas why It won't let me run the script?


  • When I try to execute the above:

    Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default

    # this will prompt about migration, CLICK YES and continue

    I get:

    Set-SPWebApplication : Operation is not valid due to the current state of the o


    At line:1 char:21

    + Set-SPwebApplication <<<<  $wa -AuthenticationProvider (New-SPAuthenticationP

    rovider) -Zone Default

       + CategoryInfo          : InvalidData: (Microsoft.Share...tWebApplication:

      SPCmdletSetWebApplication) [Set-SPWebApplication], InvalidOperationExcepti


       + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletSetWebAp


    How do I move beyond this error?

  • @AE8U

    Were able to resolve the issue?

    I am also facing same issue.



  • I was asked to investigate Claims implementation in our SharePoint 2010 environment.  From above, seems like many issues, is this still the case?

  • Does anyone know if this is true? "Authentication enhancements in SharePoint 2013 make the use of claims-based authentication easier"

  • Hi. I was doing SP2013 upgrade so, I did the above commands for my SP2010 classic mode application to claims. It converted successfully but, when i do test-contentdatabse for migrating to SP2013, It says my existing application is still in classic. can you help me

  • I am also gertting access denied after migration toi Claim. I tried both stsadm command but no luck. Is anyone got success? Please share. Thanks!

  • Please username or user account in Webapplication level by using UserPolicy with Full control

  • Please username or user account in Webapplication level by using UserPolicy with Full control

  • Please Add User(Domain\username) in Webapplication using "UserPolicy" with Full will work after migrating.

  • There are so many guides out there for classic to claims or FBA to claims. Where can I find a process for claims to FBA?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment