Choosing between classic-mode and claims-based authentication should be based on business needs. For example, if you need to support user accounts in identity providers that are not based on Active Directory Domain Services (AD DS), and you implement forms-based authentication, you must use forms-based authentication with claims-based authentication in SharePoint Server 2010. We recommend that you use claims-based authentication whenever possible.

If you are upgrading from Microsoft Office SharePoint Server 2007 to SharePoint Server 2010, you should consider the following information:

If you are upgrading an earlier version solution to SharePoint Server 2010 and the solution includes only Windows accounts, you can use either mode of Windows authentication: Windows Claims or Windows Classic. We recommend that you use claims-based authentication whenever possible. For more information about using claims-based authentication, see Implementing Claims-Based Authentication with SharePoint Server 2010 (whitepaper).

If you are upgrading a solution that requires forms-based authentication, the only option is to upgrade to claims-based authentication.

Custom code that uses Windows identities might have to be updated. If you have custom code that uses Windows identities, you can use classic-mode authentication until your code is updated and tested. For example, if you wrote a custom Web part for Office SharePoint Server 2007 that retrieved the current user identity and you are upgrading to SharePoint Server 2010, you should use SPWeb.CurrentUser() instead of HttpContext.Current.User.Identity() in order to retrieve the identity.

The migration time will vary, depending on the number of users that are listed in the UserInfo table in the content database. When you change a Web application from Windows classic mode to Windows claims, you must use Windows PowerShell to convert Windows identities to Windows claims identities. Be sure to allow for enough time during the upgrade process to complete this task.

You can search and list names in people picker when you are using SAML token-based authentication, but they cannot be checked for validity unless you write a custom claims provider.

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.

Search Alerts

SharePoint Server 2010 Explorer View

Claims to Windows Token Service (C2WTS)

InfoPath Forms Services

Search crawling

Note

If you are using forms-based authentication or SAML token-based authentication, you will still need a separate zone that supports Windows authentication to enable Microsoft Search Server 2010 to crawl your content.

Certificate Authentication

Note

Certificate authentication is not supported in SharePoint Server 2010, but you can configure Unified Access Gateway (UAG) as a front-end to SharePoint Server 2010 to enable certificate authentication by integrating with Active Directory Federated Services (AD FS) and SAML token-based authentication.
For more information about configuring SharePoint Server 2010 with UAG, see Forefront UAG integration (SharePoint Server 2010).

There are several SharePoint Server 2010 features that require additional configuration to work with forms-based authentication or SAML security tokens.

Business Intelligence (BI)

BI clients must either use Windows Claims authentication, Windows Classic authentication, or the Secure Store Service. When you are using the Secure Store Service, SAML claims are not translated to Windows tokens, so other services will not detect the SAML identity; the identity will be the service account, an anonymous account, or an unattended account.