共用方式為

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

  • 發行項

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:  https://blogs.technet.com/b/speschka/archive/2010/06/12/migrating-a-web-application-from-windows-classic-to-windows-claims-in-sharepoint-2010.aspx. 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 = "https://yourWebAppUrl"

#THIS SHOULD BE THE ACCOUNT THAT IS RUNNING THIS SCRIPT, WHO SHOULD ALSO BE A LOCAL ADMIN
$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")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

#Final step is to trigger the user migration process
$wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)

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.

Comments

  • Anonymous
    January 01, 2003
    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!

  • Anonymous
    January 01, 2003
    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?

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    October 22, 2010
    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 "

  • Anonymous
    October 29, 2010
    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 AuthorityLocal 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

  • Anonymous
    November 24, 2010
    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.

  • Anonymous
    December 13, 2010
    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? Thanks!

  • Anonymous
    January 15, 2013
    @AE8U Were able to resolve the issue? I am also facing same issue. Thanks Santosh

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

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

  • Anonymous
    February 23, 2014
    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

  • Anonymous
    March 10, 2014
    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!

  • Anonymous
    July 15, 2014
    Please username or user account in Webapplication level by using UserPolicy with Full control

  • Anonymous
    July 15, 2014
    Please username or user account in Webapplication level by using UserPolicy with Full control

  • Anonymous
    July 15, 2014
    Please Add User(Domainusername) in Webapplication using "UserPolicy" with Full control.it will work after migrating.

  • Anonymous
    August 02, 2014
    The comment has been removed

  • Anonymous
    September 18, 2014
    The comment has been removed

  • Anonymous
    September 18, 2014
    The comment has been removed

  • Anonymous
    November 13, 2014
    The comment has been removed

  • Anonymous
    March 01, 2015
    In previous blogs for SharePoint 2010 I've talked about how to do claims migration - http://blogs