Export (0) Print
Expand All

Migrating On-Premises SharePoint 2010 Farms to Windows Claims Authentication


Topic Last Modified: 2013-06-26

In preparation for a future upgrade to the next version of Microsoft® SharePoint®, SharePoint Online is migrating all SharePoint 2010 web applications that currently use Windows® Classic authentication to Windows Claims authentication.

Because of this change in SharePoint Online authentication methods, all on-premises customer SharePoint farms used for development, testing, or migrating content to SharePoint Online must also be migrated to Windows Claims authentication. It is vital that these on-premises farms are migrated to Windows Claims so that custom code can be properly validated before being deployed to SharePoint Online. For more details about on-premises farms that are used to migrate content into SharePoint Online, see the Content Migration section.

The migration to Windows Claims is done on a per-web-app basis using an out-of-the-box Windows PowerShell® command. For details about this process, see the TechNet article Migrate from classic-mode to claims-based authentication (SharePoint Server 2010). This process must be carried out on each web app that currently uses Windows Classic authentication. Web applications that use SAML claims (for example, Partner Access) do not need to be migrated.

Windows Claims migration is not reversible. It is highly recommended that you back up all databases associated with the web apps before you perform the migration. For development environments, and possibly some test environments, consider replacing any existing Windows Classic web apps with new Windows Claims web apps, rather than migrating existing ones.

It is possible that custom solutions may not behave as expected after the migration to Windows Claims. For details, see the Windows Claims Authentication section in the Custom Solution Developer's Guide at the Customer Extranet site. There will also be additional MSOCAF rules that will analyze code for potential issues with Windows Claims.

Customers that are currently migrating SharePoint 2010 content into SharePoint Online must synchronize the migration of their on-premises source web applications with the target SharePoint Online web applications. At a high level, the process is as follows:

  1. Suspend the content migration process.

  2. Migrate the on-premises farm from Windows Classic to Windows Claims authentication.

  3. Validate that the on-premises migration was successful.

  4. SharePoint Online farm is migrated to Windows Claims.

  5. Validate that the SharePoint Online migration was successful.

  6. Resume the content migration process.

Customers migrating content other than SharePoint 2010 content (for example, SharePoint 2007 content or content from a file share) using third-party independent software vendor (ISV) migration tools should check with the ISV to determine their support for migrating content into a SharePoint 2010 environment that uses Windows Claims authentication.

There is a known issue with InfoPath® forms that make web service calls to claims-based web apps. If you have an InfoPath form template running in InfoPath Forms Services on a SharePoint 2010 site that uses Kerberos and claims authentication mode, a data connection in this form template makes calls to a web service located in the '_vti_bin' directory of the SharePoint server. When users complete this form in the browser, the following error occurs:

  • “Error Accessing Data Source - Log Id 5566”

The Universal Logging System (ULS) logs will contain entries like the following:

  • OnLoad: The remote server returned an error: (500) Internal Server Error. Server was unable to process request. ---> Attempted to perform an unauthorized operation

The InfoPath forms issue can be resolved with a workaround. For claims sites using only Windows Authentication, use a Secure Store that stores user credentials that will be used to call the out-of-the-box web services. Follow this procedure:

  1. Install this hotfix package on all web front-end servers (WFEs). The hotfix is necessary so that the userName() function in InfoPath will return a result in domain\username format, instead of just username.

  2. Create a new target application in Secure Store Service.

    1. Open Central Administration using Farm Admin credentials and navigate to Application Management>Manage service applications>Secure Store Service Application.

    2. On the ribbon, click New.

    3. Provide the following information, and then click Next:

    • Target Application ID (for e.g. GetUserProfileByNameSSA)

    • Display Name (GetUserProfileByNameSSA)

    • Contact Email Address (any valid email address)

    • Target Application Type: Individual

    • Target Application URL: “Use default page”

    1. On the next page, type the User Name and Password for an account that has at least read-only permissions on the web app, and then click Next.

    2. On the Target Application Administrators page, use the account used in the previous step.

    3. To complete the creation of a new Target application, click OK.

  3. In the UDCX file used by the InfoPath form template that calls the “GetUserProfileByName” web service method, add the Secure Store App created in the previous step and reapprove. The following tag should be added

       <udc:SSO AppId="GetUserProfileByNameSSA" CredentialType="NTLM" />
  4. In the form template, in design mode, modify the GetUserProfileByName data connection so it does not initialize OnLoad.

  5. In the Form Load rule, add actions to set the AccountName query field of the GetUserProfileByName data connection to the userName() function, and then query the data connection.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft