Claims Based Authentication in SharePoint 2013, SharePoint 2010 and SharePoint Online

What is SharePoint Claims Authentication?

The claims-based identity is an identity model in Microsoft SharePoint that includes features such as authentication across users of Windows-based systems and systems that are not Windows-based, multiple authentication types, stronger real-time authentication, a wider set of principal types, and delegation of user identity between applications.

Claims-based identity is based on the user obtaining a security token that is digitally signed by a commonly trusted identity provider and contains a set of claims. Each claim represents a specific item of data about the user such as his or her name, group memberships, and role on the network. Claims-based authentication is user authentication that utilizes claims-based identity technologies and infrastructure. Applications that support claims-based authentication obtain the security token from the user and use the information within the claims to determine access to resources. No separate query to a directory service like Active Directory is needed.

In a simple analogy:

You check in at the Airport (Authentication)
– present credentials (Passport)
– credentials are validated by security guard

You receive a boarding pass (Signed Claims)
– Seat, Frequent Flyer, Gate etc.

Think of a claim as a piece of identity information (for example, name, e-mail address, age, or membership in the Sales role). The more claims your application receives, the more you know about your user. These are called “claims” rather than “attributes,” as is commonly used in describing enterprise directories, because of the delivery method. In this model, your application does not look up user attributes in a directory. Instead, the user delivers claims to your application, and your application examines them. Each claim is made by an issuer, and you trust the claim only as much as you trust the issuer. For example, you trust a claim made by your company’s domain controller more than you trust a claim made by the user.

Claims-based authentication in Windows is built on Windows Identity Foundation (WIF), which was formerly known as the Security Token Service, or STS. Many areas of SharePoint still refer to the name STS so it’s important to understand that it and WIF are one in the same. The Security Token Service comes pre-baked into the standard SharePoint 2010 install:

The Security Token Service Application in Central Administration:

The Security Token Service Application in IIS:

WIF is a set of .NET Framework classes that is used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML.

Microsoft recommends Claims-based authentication as the preferred provider to use on fresh SharePoint 2010 installs. You can configure this on a per-Web Application basis in SharePoint via the following dialog in Central Admin > Web Applications > Manage Web Applications > Ribbon Bar – New

If you select Classic-Mode Authentication, you configure the Web application to use Windows authentication and the user accounts are treated by SharePoint Server 2010 as Active Directory Domain Services (AD DS) accounts.

If you select Claims-Based Authentication, SharePoint Server automatically changes all user accounts to claims identities, resulting in a claims token for each user. The claims token contains the claims pertaining to the user. Windows accounts are converted into Windows claims. Forms-based membership users are transformed into forms-based authentication claims. Claims that are included in SAML-based tokens can be used by SharePoint. Additionally, SharePoint developers and administrators can augment user tokens with additional claims. For example, Windows user accounts and forms-based accounts can be augmented with additional claims that are used by SharePoint Server 2010.

Claims Based Authentication (Tokens) Classic Mode Authentication
-Windows Authentication: NTLM/Kerberos, Basic-Forms-based Authentication (ASP.NET Membership provider and Role Manager)
-Trusted Identity Providers-Custom Sign-in page
-Windows Authentication (NTLM/Kerberos) only

*Both map authenticated users to the same SPUser object (security principles)

What does Claims look like/feel like?

The core process of Claims is illustrated as follows:

The core currency of Claims is the identity token.



i = Identity Claim all other claims will use “c” as opposed to “i”
: = Colon separator
0 = Reserved to support future Claims
#/? = Claim Type Encoded Value. The out of the box claim types will have a hardcoded encoded value, this will enable parity across farms.
E.g. Key: ? Value:

           Key: # Value:

./0 = Claim Value Type. The out of the box claim value types will have a hardcoded encoded value, this will enable parity across farms.

            E.g. Key: . Value: urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name

            Key: 0 Value:

w/m/r/t/p/s = Original Issuer Type -> w = windows, m = membership, r = role, t = trusted STS, p = personal card, s= local sts claim

Why do I want to use Claims?

1. Decouples Authentication logic from Authorization and Personalization logic – this means speed and flexibility
2. Provides a common way for applications to acquire the identity information the need about users
3. Cloud-ready – lays the foundation to be able to Authenticate against Azure, Facebook, Google, Windows Live ID etc.
4. Federation – Partner networks, business to business, subsidiaries can all interact in the same sphere of authentication, cross machine and cross-farm
5. Supports existing identity infrastructure (Active Directory, LDAP, SQL, WebSSO etc.)
6. Standards-based and interoperable

Bonus Prize:
7. In SP 2010 we can have a single Web Application configured to use multiple authentication types which allows different auth types to be served from one URL:

Claims Gotchas

General issues for all Claims implementations
– Search crawler requires NTLM in the zone it uses
– Office Client Integration (2007 SP2+, 2010 are minimum requirements in order to maintain Client integration e.g. fluid editing of Word Document)
– SharePoint Designer does not support working with Claims Enabled Endpoints for Web Services

Migration issues when moving from Classic to Claims
– When upgrading from Classic to Claims, you will need to migrate users and Test & re-work customizations (Web parts, workflows etc.)
– After you move to Windows claims, you cannot go back to Windows classic. Ensure that you have good backups before you start and try your migration in a lab first before moving into production.
– Existing alerts may not fire, if this occurs the only workaround may be to delete and recreate the alerts
– Search crawl may not function, double-check the web application policies and ensure that the search crawl account shows the new converted account name. If it does not, you must manually create a new policy for the crawl account.


Configure Forms-based Authentication for a Claims-based Web Application
Configure the Security Token Service

SharePoint and Claims-based Identity

A Guide to Claims-based Identity and Access Control

SharePoint Server 2010 IT Professional Evaluation Guide

Plan Authentication Methods (SharePoint Server 2010) on TechNet

Claims-Based identity with Windows

Claims to Windows Token Service Overview (MSDN)
Claims Based Authentication in SharePoint 2010
Friends don’t Let Friends Use Claims Based Authentication

Incoming search terms:

User Profile Synch SharePoint 2010 – The Essential Mix

While I detailed my findings on initial pre-deploy Best Practices in my post Planning SharePoint 2010 User Profile Synchronization, I have since banged out a more organized reading list figured out through more hands-on. You may start UPS in SP 2010 as confident pro but but you’ll end with the thousand yard stare, UNLESS you follow the exact advice presented by the nice folks in the following list, in the order indicated:

1. Make sure you have the SharePoint 2010 August CU (build 14.0.5123.5000 ). Todd Klindt’s complete SharePoint 2010 build number list is here. I personally can’t vouch for newer CU’s as I haven’t tried yet but will post in the future when I learn more about the stablity of those CU’s.

2. Read Technet’s Configure profile synchronization (SharePoint Server 2010)  end-to-end. Do not do the worksheets component at the beginning yet – we will get to those when the basic synch service is up and running smoothly. Do not execute any of the config suggested in that article yet- just breeze through it, familliarize yourself with the config sections they are referring to, but just don’t set anything up yet.

3. Read and execute the steps described on Spencer Harbar’s guide at . As he indicates in his follow-up troubleshooting guide at you need to follow the instructions exactly:

I must stress that the number one reason people have problems is that
they do not follow the procedure! No really, I can’t count the number of
times steps have been missed or I get a response like “oh, I didn’t
think I needed to do that”. If you follow the procedure you will be
successful unless you are hitting an environmental or other known issue.

.. but wait! Not everyone is a super MVP like Spencer so a lot of the little details he refers to will actually be more complex for those who have perhaps have dived straight into SharePoint without a lot of Windows SysAdmin experience. So if you find gaps in your understanding of Spencers instructions, refer to the following article by Microsoft Support Escalation Engineer Steve Chen in point 4. Heck, read it regardless.

If you are at any point not clear on user accounts and rights, refer to Sean Wallbridge’s guidance on SharePoint 2010 Server User Accounts

Steve Chens User Profile Sync articleIn particular sections like detailing how to Grant Replicating Directory Permission in AD will help people who are new to the SysAdmin.

5. At this point you should have your two ForeFront Windows services up and started, and be able to access Central Administration > Synchronization Connections etc. normally. If not, or something else has blown out, do not pass go, do not collect $200 : return to Spencers troubleshooting article and be very sad because you very likely did not pay close enough attention to the steps involved.

6. Read Technet’s Plan for User Profile Synchronization

7. Grab theUser profile properties and profile synchronization planning worksheets for SharePoint Server 2010, forget about being an environmentally friendly, paperless SharePoint zealot and print those suckers out. Post ‘em all over your cube, your bathroom, wherever. Make sure you run through them even if it’s not a mega enterprise deployment you are creating.

8. Deploy!

The preceding links are essential to avoid your first SharePoint 2010 User Profile Synchronization attempt turning into a headbanger where grown men stare anxiously at little service start status indicators.


Incoming search terms:

Recent Comments

  • Angela

    Dang – was hoping for a simpler answer. But thank you for the help!

Follow me on Twitter

Office 365 Service Health

There is a problem - it appears you are using categories and no feeds have been put into those categories.

SharePoint & Office Patches

There is a problem - it appears you are using categories and no feeds have been put into those categories. Service Health

There is a problem - it appears you are using categories and no feeds have been put into those categories.