Summit 7 Team Blogs

Claims-based Authentication, ADFS 3.0, and SharePoint 2013 – Beginners Guide

I should know what claims authentication is and how it works inside and out, up ways and down, backwards and forwards. I should… but I’m ashamed to admit that until about 18 months ago I could talk my way through it, I knew “kind of” how it all worked and I could make it all work together but I didn’t really understand the under the hood of how it all works together as much as I probably should have.

With that in mind, along with some project related pressure, I set out to truly understand how claims-based authentication really works under the hood and why it’s a key to SharePoint.

Why a written recap of the journey? Well for one I don’t want to forget and I think it’s always a good idea to have your experiences and lessons learned backed up somewhere. The second, and probably more important reason, is to hopefully help someone that is struggling with the concept of claims-based authentication, especially in relation to SharePoint and might be fighting through some of the same issues I am.

When I first started researching claims and Active Directory Federation Services (AD FS) I found lots of documentation on the how of setting it up which was great. I’m not an advanced PowerShell user by any means and that saved me some work so cool. What wasn’t so cool was the lack of “Why” around the subject which is important to me.

At some point I found A Guide to Claims-Based Identity and Access Control (2nd Edition) which I HIGHLY recommend, specifically the first two chapters introducing Claims-based Authentication and Claims-Based Architectures. Then read the two SharePoint related chapters on Claims-based Single Sign-on and Federated Identities. The document focuses on SharePoint 2010 but is still relevant to 2013 environments.

If you’re a developer this book has a TON of great information on things like Securing REST services, Single Sign-on for the web and Azure, etc… so it’s well worth reading if you’re writing apps.

So for those of non-developers we’ start by talking about the basic concept of claims-based authentication in what I hope is language anyone can understand. I figure if I understand it then most everyone else should too. Let me know if I’m right in the comments section J

Authentication in General

There are a number of different Security Support Provider Interfaces (SSPI) provided by Microsoft that can be used for authentication purposes. The ones that we, as SharePoint people, are most familiar with are probably Microsoft NTLM and Microsoft Kerberos. NTLM and Kerberos are forms of Windows Claims-based Authentication using Active Directory Services (AD DS) as the authentication store and validation of user credentials.


NTLM is a Windows challenge/response authentication protocol that leverages the interactive use of a login box that requires the end user to input their network credentials manually. Those credentials would include the users Username, password and domain name if logging into an organizations domain.

Plain English: end users log in by entering a username, password and domain into a login box. That being said we need to understand at least the basics of the process.

  1. NTLM authenticates end users by first creating an encrypted one-way hash of the users password, discarding the original password and then sending the user name to the server in plain text.
  2. The server responds to the client with a 16-bit challenge called a nonce.
  3. The client encrypts the nonce and the hash of the users password and returns them to the server. This is the Response.
  4. The server in turn sends three items to the domain controller; the users name, the challenge sent to the client and the clients response to the challenge. The domain controller retrieves the hash of the user name is has received from the Security Account Manager (SAM) database and uses that hash to encrypt the challenge.
  5. Once the challenge has been encrypted by the domain controller it is compared to the challenge encrypted by the client and if they match the end user is authenticated successfully.


Plain English: If you enter your password incorrectly the hashes will not match and you won’t be able to log into the network.


The Kerberos security protocol has been a part of Windows since Windows Server 2000 and was intended as a replacement for NTLM. Obviously that hasn’t happened and the two can often be found working together or in a mixture across Windows environments everywhere.

Kerberos is a Windows Security Protocol designed to authenticate users and services on an organizations network and relies on three components; a client, a service and a trusted third party. The trusted third party in most Windows networks would likely be the Key Distribution Center (KDC) which creates the shared secret that is leveraged to allow access to the service. A simple view of the process might look like this:

  1. A user account is created in the domain and assigned a password.
  2. The Kerberos client adds a text string, or a SALT and the Kerberos version number to the unencrypted password and runs them through a process known as the “string2key” This conversion generates the “shared secret”.
  3. At the client the user enters their username and password and requests access to an application or service.
  4. When the user submits their username and password the Kerberos client creates the secret key on the client based on that information. Because the client uses the same key to generate the secret key that the KDC does the two will match, or should anyway. If they don’t match authentication fails and access id denied.

Plain English: If you enter your password incorrectly the hashes will not match and you won’t be able to log into the network.

To the end user the process looks like this:

  1. The user requests a SharePoint site.
  2. SharePoint sends a request for Windows Credentials to the user in the form of a login box asking for a username and password.
  3. The end user enters their Windows credentials and submits them to SharePoint.
  4. SharePoint validates the users account with AD.
  5. SharePoint requests and receives the users group membership from AD.
  6. SharePoint creates a SharePoint security token and sends the authorization code and requested web page to the end user.




Behind the scenes it is a little more complicated than that.


  1. The Client sends an HTTP (GET) request as an anonymous user.
  2. The WFE responds with a 401.2 (unauthorized: Login failed) and with a WWW-Authenticate: Negotiate or WWW-Authenticate: Kerberos header.
  3. The client contacts the KDC on the domain controller requesting a Kerberos ticket for the SPN (service-principal-name) referenced by the client browser.
  4. If the KDC finds a matching SPN it creates and encrypts a ticket and returns it to the client.
  5. The client creates the authenticator and returns it with the ticket to the WFE. The WFE decrypts the ticket and determines identity and checks permissions on the SharePoint server to see what access, if any, is to be granted.
  6. If access is permitted IIS contacts the SQL server through the Web Application service.
  7. The Web Application service requests a ticket for the SQL server from the KDC.
  8. If an SPN is found the KDC returns the ticket which the web application uses to impersonate the user.
  9. SQL Server checks the ticket from the Web Application service and validates it and sends the data back to the server.
  10. .NET compiles the .aspx page and sends it to the users browser.


Claims-based Authentication

In a nutshell the definition a Claim is a statement or assertion of something as a fact. That Claim, or assertion of fact, may be related to a name, permissions to access information or perform a task, your identity, or group you are a member of. These claims, when packaged together by a claims provider make up a security token that provides digitally signed proof of the integrity and validity of the claims and the claim provider.

OK, now in plain English, consider your driver’s license. It’s a legal document, usually issued by a government agency that proves you have permission to operate a motor vehicle in your state, or country of residence. It also contains a number of pieces of information about you; your name, address, height, weight, eye color, corrective lenses required, etc… Each of those claims has a value on your driver’s license that is endorsed, or legally supported, by the government as a fact.

Now all of this is well and good but how does SharePoint know which claims to accept and which to reject?

As the consumer, SharePoint must be configured to recognize and trust the claims issued by specific Identity Providers. Once this is done SharePoint will validate and authenticate users presenting claims from the identity provider. The steps in the claims authentication process are a little more involved than those in the NTLM and Kerberos scenarios.

  1. The end user hits the SharePoint site generating an HTTP (GET) request.
  2. SharePoint redirects the user to the Identity Provider to get a security token.
  3. The end user is prompted for credentials by the Identity Provider.
  4. The Identity Provider validates the provided credentials with the authentication provider (in this case AD DS) and if successful provides the client a security token.
  5. The Identity Provider sends the end user a SAML security token.
  6. The end user submits a new request to SharePoint with the SAML token.
  7. The SharePoint STS generates the SharePoint security token, the FedAuth cookie and the requested SharePoint site.





At this point the user should have been able to access the SharePoint site and perform any assigned tasks.

There have been a number of terms and acronyms in this article that you may want further explanation of. The official list of claims-based authentication terms and definitions can be found at https://msdn.microsoft.com/en-us/library/office/ee534975.aspx.

The Recap

We’ve should now have a basic, but solid, understanding of how claims-based authentication works as well as a better understanding of the underlying processes behind NTLM and Kerberos.

In my next post we’ll introduce Active Directory Federation Services 3.0 (AD FS 3.0). We will walk through the installation and configuration of AD FS to support a SharePoint 2013 farm, and set the foundation for creating our Trusted Identity Provider and configuring SharePoint to use it as an authentication source.

Thanks for reading!


The rest of the series:

Part 2: Installing and Configuring AD FS 3.0
Part 3: Configuring SharePoint 2013 for AD FS
Part 4: Troubleshooting
Part 5: Authentication Across Multiple Forests


[su_service title="Increase your efficiency using our SharePoint platform solutions." icon="icon: dashboard" icon_color="#333333" size="36"]

[su_button url="http://summit7systems.com/solutions/sharepoint-platform-solutions/" background="#a21d21" style="flat" size="10"]Learn More[/su_button]


About Jay Simcox

Jay Simcox is a respected IT Professional, and educator with 10 years of Information Technology experience. Jay is a Senior Consultant with Summit 7 Systems where his background in network and systems administration, SharePoint architecture and Administration and end user support and training are utilized by government agencies seeking to make better use of the tools they are provided.