SharePoint 2013 upgrade preparation - to be or not to be claim-based?

After SharePoint 2012 conference and SharePoint Ignite IT Pro training, I got much inside information to prepare the SharePoint 2013 migration. One of the critical preparation before the 2013 upgrade is the claim-based authentication migration. We were not fan of the claim-based authentication two years ago since we found several major out of box functions were not working when we implemented ADFS at that time. In this blog, I will list the pros and cons to enable claim-based authentication on SharePoint 2013 for your reference.

In SharePoint 2013, claims-based authentication is the default and preferred method of user authentication and is required to take advantage of server-to-server authentication and app authentication. There are several options to upgrade SharePoint classic sites to SharePoint 2013 claims-based authentication. The preferred reproach is to convert them to claims-based web applications within SharePoint 2010 Products, and then migrate them to SharePoint 2013.

Here is the list of the pros to enable claim-based authentication on SharePoint 2013. The majority is the support capability of server-to-server authentication run SharePoint 2013.

1. Utilize Office Web Apps (OWA) to work correctly with the web application – In SP 2013 the authentication provider must be displayed as Claims Based Authentication for Office Web Apps to work correctly with the web application. You can find more information in SharePoint authentication requirements for Office Web Apps.

2. Apps in the SharePoint Store or App Catalog - SharePoint 2013 introduces support for server-to-server authentication and app authentication by utilizing and extending the Open Authorization 2.0 (OAuth 2.0) web authorization protocol. 

3. Azure Workflow Service - SharePoint 2013support this new workflow that is running on separately from SharePoint farm. The server-to-server between SharePoint farm and Azure Workflow Service  makes the use of claims-based authentication.

4. Exchange Server 2013 integration - SharePoint 2013 social functions like Mysite need to communicate with exchange 2013 to auto display users social pages and sites.

5. Lync Server 2013 integration - SharePoint 2013 functions related to display Lync functions will depend on server-to-server claims-based authentication.

6.  eDiscovery functions - SharePoint 2013 eDiscovery will not be able to search other repositories such as exchange or Lync w/o claims-based authentication.

7. Hibernate SharePoint 2013 farms - You could not integrate SharePoint 2013 on-Prem with SharePoint cloud w/o claims-based authentication.

8. SharePoint On-Prem to cloud migration -  SharePoint 2013 cloud only support ADFS claims-based authentication and you will not be able to migrate your sites if not claim-based already.

9. Could not create sites in classic mode easily using UI - You have to use powershell to create them.

It is very clear that you will loss many SharePoint 2013 features with deprecated classic model. My suggestion is you might need to serious consider to convert to claims-based authentication so you could be ready for the 2013 upgrade.

There are some cons you would need to keep in mind and need to be verified and tested. We have not review this with 2013 and the current conclusion is based on previous ADFS conversion.

1. Microsoft project server resource conversion and sync issues - MPS is resource to assign permissions. The resource users need to be converted to claim-based and it's not straight forward. After converted to claim, how the resource sync will work needs to be investigated.

2. People picker usability - Users will see claim user format when move mouse to user. The claim format will cause confusion when select or search users. The group might display as SID so you will not be able to identify from UI after added to the site from people picker.

3. SharePoint server API and client API need to be modified to communicated with SharePoint - You will need to pass token when communicate with SharePoint on claim-based.We will publish the detailed in future blog.

4. Several services need additional configuration and more difficult to set up - this is obvious.

5. External Workflow like Nintex workflow could not be continued and has to be rebuild or republished. All out of box workflow or designer workflows might continue working that need to be verified.

6. Some third party software or integrations might not work on claim-based authentication - Vordel SSO integration for SharePoint with other siteminder protected systems. NextLabs SharePoint entitlement tool is not supporting at this time. You might need to discuss with vendors on the claim-based authentication support of any SharePoint add on components.

7. Files checked out to local location will not be able to checking after conversion. The workaround is to generate a report indicate who has any file checked out and ask them to check in.

8. All the existing external connections including UNC, outlook connections, workspace need to be tested and might cause issues.

9. BCS and security stores need to be verified. C2WT service need to be started and associated with claim-based webapp to streamline the integrations (double hub issues).

10. Custom reports to display user and group names might need to adjust the code.

There might be more issues and risks on  claim-based SharePoint. Please share any issues or concerns if you have such experience.