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

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

Posted by on Wednesday, February 18th, 2015  

 

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

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.

Kerberos

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.

 

Beginners_Guide_to_Claims_Auth_SP13_blog1

 

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

Beginners_Guide_to_Claims_Auth_SP13_blog2

  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.

 

Beginners_Guide_to_Claims_Auth_SP13_blog2

 

 

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

 

Increase your efficiency using our SharePoint platform solutions.
Learn More

 

Posted by on Wednesday, February 18th, 2015  

Subscribe to RSS Feed

Sign Up for Newsletter

14

14

comments

    Feb 20
    2015

    Soheil

    I am on the same boat as you were 18 month ago. Great blog. It helped me a lot. Can’t wait for ADFS post.

    Reply
      Feb 20
      2015

      Soheil

      It would be nice if you could describe OAuth in plain language as well.

      Reply
    Jun 15
    2015

    anil247

    I just read this article and its definitely a great post which helped me to understand well.

    I have one question related to claims based authentication.

    Why SharePoint needs to generate STS Token and is there any validation done against SAML token and STS token?

    How is the user roll mapping done in this mechanism

    Reply
    Jul 09
    2015

    Jacob

    Thank you very much for the 3-part explanation. It helped get my Sharepoint 2013 site to work externally with ADFS 3.0. But I still don’t understand the benefits ADFS provides w.r.t. SSO, since every time the IE browser is re-initialized I get both an ADFS login window and then another windows login prompt. Where my hope was the user wouldn’t have to re-authenticate anytime after logging on once and the certificate was valid. I don’t see the benefits of ADFS yet.

    Reply
    Jan 05
    2016

    Raj

    Hi – Great blog, when you mention Claims-based Authentication, does it require ADFS, as per your last diagram ? i.e. 2013 by default is Claims-Based, does this mean I require ADFS (currently using 2010 with ADDS)?

    Reply
      Jan 12
      2016

      Jay Simcox

      Hey Raj, no you don’t have to have ADFS unless you have a some kind of requirement to federate identities (allow access from a partner or sister company) or in some cases if you were trying to allow access from outside of your local network (although not necessarily required).

      Hope that helps!

      Reply
    Feb 19
    2016

    Terri

    thank you so much for the great post

    Reply
    Apr 02
    2016

    Kaushal

    The below guide is not available on the link provided by you in the above article:
    A Guide to Claims-Based Identity and Access Control (2nd Edition)

    Please share another source.

    Reply

Leave a Reply