Wednesday, March 7, 2012

Things to know about SharePoint 2010 Claims-based Authentication

If you are configuring SharePoint 2010 with Claims-based Authentication for the first time, there are several things you should know before beginning to set up your environment to support Claims-based Authentication:

  1. If you are using Active Directory as your user repository, attributes such as E-mail Address will not be available unless you are using Microsoft Exchange within your organization.  Active Directory does not natively support the E-mail Address attribute, therefore, if your organization uses an alternative Mail Server such as Lotus Notes, you will have to figure out alternative methods to populate this attribute.
  2. Claims-based Authentication and Windows NTLM Authentication (Classic Mode Authentication) for a SharePoint 2010 Web Application are not interchangeable within the Central Administration GUI interface.  If you are performing all of your management activities within the GUI interface and you accidentally configure an NTLM-based Web Application, you will have to delete it and re-create it in order to select Claims-based Authentication.
  3. If you are working with PowerShell in conjunction with using SharePoint Central Administration, you can still convert an NTLM-based Web Application over to Claims-based Authentication. ( Of course, this is a one-way conversion.  If you later decide you really want NTLM Authentication, you will have to once again delete the Web Application and create it.  The PowerShell command to convert a Classic Mode Authentication Web Application (NTLM) over to Claims-based Authentication is the following (
    $ConvertApp = Get-SPWebApplication "http://<web application name>"
    $ConvertApp.UseClaimsAuthentication = "True"
  4. You will need SSL Certificates on your SharePoint Server and your Security Token Service (or on ADFS if you are using ADFS). If you do not purchase 3rd party SSL Certificates, you will either need to use an internal Certification Authority server or issue Self-signed certificates. Of course, using internal or Self-signed certificates may result in a browser security certificate warning when end users browse to your SharePoint website.
  5. If you are planning on setting up an Identity Provider for Claims-based Authentication (such as ADFS), you can provide BOTH Claims-based Authentication using Windows Integrated Authentication as well as Identity Provider authentication.  This allows you to continue to access SharePoint even while configuring or troubleshooting issues with using the Identity Provider authentication and authorization process.
  6. If you are using Claims-based authentication with the NTLM vs. using an Identity provider (such as ADFS), you will get a DIFFERENT set of Claims between the 2 authentication mechanisms.  This will either require you to map Claims to each other or to simplify things simply using a single Claims authentication provider such as your Identity Provider.
  7. You can set up different authentication mechanisms based on different Urls for a SharePoint Web Application.  For example, you may want to support NTLM authentication for all users accessing your web site via the Intranet, while supporting Forms-based authentication for all users accessing your web site via the Extranet or Internet.  
  8. After setting up Claims-based Authentication, you will have to click on the User Policy tab in Central Administration in order to add one or more users with the appropriate permissions to log into the site using Claims Authentication credentials.  
  9. If you are using Claims-based authentication with load balancing, you will need to set up Affinity/Sticky Sessions for your load balancing:
  10. In order to speed up the Claims Authentication process, you may want to DisableLoopbackCheck in the registry as described in this article:

1 comment: