What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as IT Pro, developer, or end user?

We plan to migrate SharePoint 2010 from classic-mode to claims-based authentication to prepare the 2013 upgrade as described in previous article. Although Microsoft describes this is a simple process, it seems the tips and tricks are not provided for different SharePoint users including IT Pro, developer, or end user. This article describes the details what you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as IT Pro, developer, or end user. Several tips and scripts are provided to help you on the smooth migration.

1. What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as IT Pro?

A. Migration steps are simple and in four steps

• Migrate webapp

     $WebAppName = "http://yourWebAppUrl"
     $wa = get-SPWebApplication $WebAppName
     $wa.UseClaimsAuthentication = $true
     $wa.Update()

• Configure the policy to enable the farm admin account to have full access

     $account = "yourDomain\farmAdmin"
     $account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
     $wa = get-SPWebApplication $WebAppName
     $zp = $wa.ZonePolicies("Default")
     $p = $zp.Add($account,"PSPolicy")
     $fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
     $p.PolicyRoleBindings.Add($fc)
     $wa.Update()

• Migrate users

     $wa.MigrateUsers($true)

• Perform provisioning

     $wa.ProvisionGlobally()

B. Tips and scripts to help IT Pro for the migration

• Apply June CU 2012 in SP 2010 environment before migration and advantages of this CU are given below.
• An update enables the MigrateUser method to accept content database names as parameters so that you can perform migrations on the specified list of database. Additionally, this update enables you perform the migration in parallel if you have a large volume of data that contains millions of users.
• An update provides APIs or cmdlets to make sure that the same claim type uses the same encoding character on multiple SharePoint farms.

• Remove manually added IIS host header bindings for the web applications configured to use claim based authentication. Otherwise an authentication failure will happen with 401 errors. You could change the host header URL as described here.

• Keep Kerberos over claims to streamline integration to external system and the reason is list in previous blog

•  Configure C2WTS ‘AllowedCallers’ as described in c2wtshost.exe.confi file is saved in the following location \Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config 

•  Stop the following services and applications before migration

•  User Profile Sync
•  Search crawling
•  Web analytical 
•  Search service application window service
•  World Wide Web Publishing Service window service
•  Third party tool like DocAve process and NextLabs services

• Identify scheduled timer jobs and disable them before migration. Enable them after migration using the following steps I got from out consultant.

• Capture the list of currently enabled jobs                         

             Get-spTimerJob | where { !$_.IsDisabled } | SELECT ID | out-file c:\enabledjobs.txt

• Open c:\enabledjobs.txt and delete the first three lines and save. Then, you will need to delete the last three blank lines in the file (If you do not do this it will disable all jobs)

• Run the following command and make sure the last column says false (this ensures you have edited the enabledjobs.txt file correctly                      

               Get-Content c:\EnabledJobs.txt | Foreach-Object { Get-SPTimerJob -id $_  | SELECT ID, DisplayName, IsDisabled}

• Disable all those jobs run the following                            

               Get-Content c:\EnabledJobs.txt | Foreach-Object {Disable-SPTimerJob $_ }

• Re-enable all those jobs run the following                                 

               Get-Content c:\EnabledJobs.txt | Foreach-Object {Enable-SPTimerJob $_ }

•  Configure the publishing cache accounts to reflect the claim format identities, otherwise publishing sites will fail with “Access Denied” Error

•  Run “Claims to windows token service” if there are external sources used and passing NTLM credentials for authentication. Verify excel services.

2. What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as developer?

      A. Getting the Current User in Claims Mode code change 

HttpContext.Current.Identity;                      //Old way

SPContext.Current.Web.CurrentUser;       //Still works

IClaimsIdentity identity = (ClaimsIdentity)Thread.CurrentPrincipal.Identity; // New way

    B.  After claim migration – Impersonating the user using c2wts

// Check the current claims identity and use the UPN claim

if (SPSecurityContext.IsWindowsIdentityAvailable)

{

    // Use the c2WTS and get the windows identity

    WindowsIdentity wid = SPSecurityContext.Current.WindowsIdentity;

    //Create the Impersonation context

    using ( WindowsImpersonationContext ctxt = wid.Impersonate() )

    {

        // Do work here

    }

}

   C.  Retrieve user name from its claims representation code change

                   SPClaimProviderManager mgr = SPClaimProviderManager.Local;

                   string userName userName =  

                         mgr.DecodeClaim(SPContext.Current.Web.CurrentUser.LoginName).Value;

   D. Get claim from login user name

         SPClaimProviderManager mgr = SPClaimProviderManager.Local;

         SPClaim claim = new SPClaim(SPClaimTypes.UserLogonName, "myuserName", 

            "http://www.w3.org/2001/XMLSchema#string", 

            SPOriginalIssuers.Format(SPOriginalIssuerType.Forms, "myprovider"));

         string userName = mgr.EncodeClaim(claim)

      We have this in out perl WCF code.

                claim = new SPClaim(SPClaimTypes.UserLogonName, userName, 

                              "http://www.w3.org/2001/XMLSchema#string",    

                               SPOriginalIssuers.Format(SPOriginalIssuerType.Forms,  

                               ConfigurationManager.AppSettings["Membership"].ToString()));

   E. Client object model potential code change - add header to request
         WebRequestExecutor.RequestHeaders.Add( "X-FORMS_BASED_AUTH_ACCEPTED", "f");

3. What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as an end user?

  A. FAST Search Server 2010 for SharePoint document preview does not work with SharePoint Server 2010 claims-based Web applications.

   B. Existing alert may not fire. We might need to delete and recreate them.

  C. People picker (in SP 2010) will display the user information in a different way like "i:0#.w|na\harrycx" . This is worth if you want to display the groups. Please see this article for the claim format.

  D. The following SharePoint Server 2010 features do not work when you switch to a claims-based Web application that uses forms-based authentication or Security Assertion Markup Language (SAML) security tokens. These features do not work because claims-based authentication does not generate a Windows security token, which is necessary for these features. Our extranet webapps are using Claims with FBA and will have these issues. However, some of them are still working that need to be verified again.

• Search Alerts
• SharePoint Server 2010 Explorer View
• Claims to Windows Token Service (C2WTS)
• InfoPath Forms Services  
• Search crawling

  E. Any function related to authentication like UNC, exchange connection, workspace, security store, BCS external connections as I have described in previous blog need to be verified.

    F. Some third party tools like NextLabs may not support claims at this time.

There are more functions need to be tested and please refer my previous blog and Microsoft article for more details.