Part1: Explaining Integrated Windows Authentication in SharePoint and How NTLM fails but Kerberos works in Double-Hop authentication

Article
01/23/2018

This is Part 1 in my Integrated Windows Authentication (Negotiate, NTLM, Kerberos) Blog Series (What is it, how it works, how to setup and how to troubleshoot)..

Kerberos Setup, Troubleshooting and Best Practices are covered in my Part2 and Part3 of this blog series.

I know there are lots of articles talking about it but I've tried to present information in a more practical way using Fiddler and network monitor trace examples…

Alright then, let's get started !!!!

SharePoint Server supports a variety of authentication methods and authentication providers for the following authentication types:

Windows authentication, Forms-based authentication and SAML token-based authentication

In this Post I will be talking about Windows authentication in SharePoint, but before we get there, In simple diagram, this is how Sharepoint Authentication takes place:

Authentication is handled in Windows by a process called LSASS.EXE which accepts user's credentials.

Let's talk about Windows authentication in detail……

The Windows authentication type takes advantage of your existing Windows authentication provider (AD DS) and the authentication protocols that a Windows domain environment uses to validate the credentials of connecting clients. Windows authentication method, which is used by both claims-based authentication include the following:

NTLM
Kerberos
Digest
Basic

When ASP.NET is configured for Windows authentication, it relies on IIS to authenticate its clients using the configured authentication mode. IIS determines the authentication mode for a particular application by examining its metabase settings. After successfully authenticating a user, IIS passes the Windows token representing the authenticated user to the ASP.NET worker process (w3wp.exe) in which the ASP.NET application is hosted. If your application uses a virtual directory that is configured in IIS to support anonymous access, the token represents the anonymous Internet user account; otherwise, the token represents the authenticated user.

IIS supports the following modes of authentication:

Anonymous. Although not a Windows authentication type, SharePoint Server also supports anonymous authentication. Users can access SharePoint content without validating their credentials. Anonymous authentication is disabled by default. Internet Information Services (IIS) websites that are created by SharePoint for serving web applications always have the Anonymous Authentication and Forms Authentication methods enabled, even when the SharePoint setting for Anonymous and Forms Authentication are disabled. This is intentional and disabling Anonymous or Forms Authentication directly in the IIS settings will result in errors in the SharePoint site.

If you do not need to authenticate your clients (or you use a custom authentication mechanism, such as forms authentication), you can configure IIS to allow anonymous access. In this event, IIS creates a Windows token to represent all anonymous users with the same anonymous (or guest) account. The default anonymous account is IUSR_MACHINENAME, where MACHINENAME is the NetBIOS name of the computer that was specified during installation.
Digest and Basic. With the Digest authentication method, the user account credentials are sent as an MD5 message digest to the Internet Information Services (IIS) service on the web server that hosts the web application or zone. With the Basic authentication method, the user account credentials are sent as plaintext in an unencrypted Base64-encoded format. Therefore, you should not use the Basic authentication method unless you are also using SSL to encrypt the website traffic.

You might have to use these older authentication methods if your environment uses web browsers or services that only support Digest or Basic authentication to websites.

To help protect the credentials, you should only use basic authentication with Secure Sockets Layer (SSL). Because the Web server obtains the user's credentials unencrypted, ASP.NET applications can impersonate the caller and use their credentials to access network resources.

Unlike the NTLM, Kerberos, and Anonymous authentication methods, you configure Digest and Basic authentication methods from the properties of the web site that corresponds to the web application or zone in the Internet Information Services (IIS) snap-in.
Integrated Windows. Integrated Windows authentication (formerly called NTLM, and also known as Windows NT Challenge/Response authentication) uses either Kerberos v5 authentication or NTLM authentication, depending upon the client and server configuration. The server negotiates with the client to determine the protocol to use. Kerberos authentication is used if the following conditions are met:
- Your ASP.NET Web application is running under the NetworkService account or a custom domain account. If your application runs under a local account, such as the ASPNET account on Windows 2000 Server, then NTLM authentication will be used.
- A service principal name (SPN) exists in Active Directory for the domain account used to run the service with which the client is authenticating.
- Client and server computers are running at least Windows 2000 Server and are in the same, or trusting, Windows domain.

Understand the Security Support Provider Interface (SSPI) Infrastructure in the Windows Operating System:

The Microsoft Security Support Provider Interface (SSPI) is the foundation for Windows authentication. Applications and infrastructure services that require authentication use SSPI to provide it. SSPI is the implementation of the Generic Security Service API (GSSAPI) in Windows Server operating systems.

The default Security Support Providers (SSPs) that invoke specific authentication protocols in Windows are incorporated into the SSPI as DLLs. These default SSPs are described below. Additional SSPs can be incorporated if they can operate with the SSPI.

The SSPI in Windows provides a mechanism that carries authentication tokens over the existing communication channel between the client computer and server. When two computers or devices need to be authenticated so that they can communicate securely, the requests for authentication are routed to the SSPI, which completes the authentication process, regardless of the network protocol currently in use. The SSPI returns transparent binary large objects—these are passed between the applications, at which point they can be passed to the SSPI layer on that side. Thus, the SSPI enables an application to use various security models available on a computer or network without changing the interface to the security system.

Why is 'NEGOTIATE' Authentication protocol better than Kerberos and NTLM alone individually? - See below:

Integrated Windows authentication includes the Negotiate, Kerberos, and NTLM authentication methods. Negotiate (also known as SPNEGO), a wrapper for Kerberos v5 and NTLM, allows the client application to select the most appropriate security support provider for the situation. Kerberos v5 and NTLM have the following restrictions:

NTLM can get past a firewall but is generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.
Kerberos v5 requires that the client have a direct connection to Active Directory, which is generally not the case in Internet scenarios.
Kerberos v5 requires that both the client and the server have a trusted connection to a Key Distribution Center (KDC) and be Active Directory–compatible.
Kerberos v5 requires SPNs for multiple worker processes. If your Web site uses multiple worker processes, you can use Kerberos authentication, but you must manually register service names. For more information about Kerberos and service registration, see Kerberos and service registration later in this topic.

Integrated Windows authentication has the following limitations:
Integrated Windows authentication does not work over HTTP proxy connections.

Therefore, Integrated Windows authentication is best suited for an intranet environment, where both user and Web server computers are in the same domain.

NTLM Authentication Mechanism

Figure 1 shows the NTLM protocol.

Figure 1. The NTLM challenge/response mechanism

The challenge/response mechanism is outlined below:
(Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.

The client sends the user name to the server (in plaintext).
The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.
The server sends the following three items to the domain controller:
- User name
- Challenge sent to the client
- Response received from the client
The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

[NTLM authentication]This is how it works in form of HTTP status Codes (c and s stand for client and Server):

C --> S GET ...

C <-- S 401 Unauthorized WWW-Authenticate: NTLM
C --> S GET ... Authorization: NTLM <base64-encoded type-1-message>
C <-- S 401 Unauthorized WWW-Authenticate: NTLM <base64-encoded type-2-message>
C --> S GET ... Authorization: NTLM <base64-encoded type-3-message>
C <-- S 200 Ok

Type- 1 -message = Domain name and user name

Type- 2 -message = Challenge

Type- 3 -message = Response (Challenge + Hash)

Fiddler request for NTLM Authentication will show these frames (I am including screenshots):

1st 401 …….. Anonymous request, Server responds saying I understand NTLM only.. Please authenticate using NTLM protocol.

2nd 401.. Client passing credentials (NTLM Type 1: negotiation, provider: NTLMSSP).. Server sends a random number 'Challenge' (NTLM Type 2: Challenge, provider: NTLMSSP) to client..

Then NTLM Type3: Authentication, provider: NTLMSSP happens.

Hence 302… redirect to page URL (Home.aspx) as Authentication was successful..

Then HTTP 200 OK….. Request is made to get the page which server responds with page..

This is how NTLM works essentially.

Now, let's move on and see how Kerberos Authentication works…

Kerberos Authentication

Kerberos authentication offers the following advantages over NTLM authentication:

Delegated authentication: The Kerberos V5 protocol includes a proxy mechanism that enables a service to impersonate its client when connecting to other services. There is no equivalent available with NTLM. Servers that use Kerberos authentication to authenticate clients can impersonate those clients and use the client's security context to access network resources.
Interoperability: Microsoft's implementation of the Kerberos protocol is based on standards-track specifications recommended to the Internet Engineering Task Force (IETF). As a result, the implementation of the protocol in Windows 2000 lays a foundation for interoperability with other networks where Kerberos version 5 is used for authentication.
More efficient authentication to servers: With NTLM authentication, an application server must connect to a domain controller in order to authenticate each client. With the Kerberos authentication protocol, on the other hand, the server is not required to go to a domain controller. Hence it offers improved performance over NTLM authentication.
Simplified trust management. Networks with multiple domains no longer require a complex set of explicit, point-to-point trust relationships.
Mutual authentication: NTLM authentication was designed for a network environment in which servers were assumed to be genuine. The Kerberos protocol makes no such assumption. When a client uses the Kerberos v5 protocol for authentication with a particular service on a particular server, Kerberos provides the client with an assurance that the service is not being impersonated by malicious code on the network.

Kerberos Authentication Mechanism:

A simplified view of the Kerberos authentication protocol is shown in figure below:

Here is an example complimenting the above diagram:

How Kerberos Works:

Kerberos authentication service request (KRB_AS_REQ): The client contacts the Key Distribution Center's authentication service for a short-lived ticket (a message containing the client's identity and SIDs) called a TGT.
Kerberos authentication service response (KRB_AS_REP): The authentication service (AS) constructs the TGT and creates a session key the client can use to encrypt communication with the ticket-granting service (TGS). The TGT has a limited lifetime. At the point that the client has received the TGT, the client has not been granted access to any resources, even to resources on the local computer.
Kerberos ticket-granting service request (KRB_TGS_REQ): The client wants access to local and network resources. To gain access, the client sends a request to the TGS for a ticket for the local computer or some network server or service. This ticket is referred to as the service ticket or session ticket. To get the ticket, the client presents the TGT, an authenticator, and the name of the target server (the Server Principal Name or SPN).
Kerberos ticket-granting service response (KRB_TGS_REP): The TGS examines the TGT and the authenticator. If these are acceptable, the TGS creates a service ticket. The client's identity is taken from the TGT and copied to the service ticket. Then the ticket is sent to the client.
Kerberos application server request (KRB_AP_REQ): After the client has the service ticket, the client sends the ticket and a new authenticator to the target server, requesting access. The server will decrypt the ticket, validate the authenticator, and for Windows services, create an access token for the user based on the SIDs in the ticket.
Kerberos application server response (optional) (KRB_AP_REP): Optionally, the client might request that the target server verify its own identity. This is called mutual authentication. If mutual authentication is requested, the target server will take the client computer's timestamp from the authenticator, encrypt it with the session key the TGS provided for client-target server messages, and send it to the client.

Microsoft Network monitor (NetMon) and Fiddler are our friends here, to locate the AUTH flow…………………………….

Let's see a Netmon screenshot below showing the flow explained above:

I have loaded an Authentication filter here in netmon.

Filter:

KerberosV5

OR KerberosV5_Struct

OR NLMP

OR NLMP_Struct

OR GssAPI

OR SpnegoNegotiationToken

OR GssapiKrb5

It all starts with
KRB_AS_REG… I am focusing on Service ticket in screenshot below..

Let's Look at a sample Fiddler trace of Kerberos AUTH flow
…. …………………………

1st 401… Anonymous request as expected.. Server responds back saying AUTHENTICATE using 'NEGOTIATE' protocol, if not then fall back to NTLM…

Then, Client obtains a valid Kerberos ticket from KDC and presents to server making a Get Request for the Site..

GET / HTTP/1.1

Server Decrypts the ticket using APP pool identity, if SPN is valid then decryption is successful and server redirects request to the page..

Hence 302.. Redirect to the Page URL in response…

HTTP/1.1 302 Redirect

Same frame from AUTH Tab:

Then client uses the ticket to make a request to the page GET /_layouts/15/start.aspx HTTP/1.1 ……………

which is responded by server with HTTP 200 OK.

HTTP/1.1 200 OK

Same frame from AUTH and RAW tabs:

For Every Successful logon of Kerberos AUTH, you will see event ID 4624 on SharePoint Web front end server too in Event Windows Security logs as shown in below Screenshot:

We should see same event on KDC (Domain controller) too:

In case of kerberosV5 AUTH failure, Authentication falls back to NTLM so fiddler will show you NTLM Type 1,2,3 HandShake happening and NetMon will show you kerberos Errors.

Kerberos related Errors can be found here:

https://technet.microsoft.com/en-us/library/bb463166.aspx

https://blogs.technet.microsoft.com/askds/2012/07/27/kerberos-errors-in-network-captures/

Let's Understand Kerberos Authentication steps from browser (IE) to server communication Scenario……….

When a Kerberos ticket is sent from Internet Explorer to an IIS server, the ticket is encrypted using a private key. The private key is a hash of the password used for the user account associated to the SPN. Therefore, only an application running under this account will be able to decode the ticket.
Here is a summary of the Kerberos authentication algorithm's steps:
- Internet Explorer will use the URL typed in the address bar to compute a SPN
- The SPN is passed thought a SSPI API (InitializeSecurityContext) to the system component in charge of Windows security (LSASS process). At this stage, we can note that Internet Explorer code doesn't implement any code to construct the Kerberos ticket : IE just calls SSPI APIs
- Using the SPN that is passed in, LSASS requests a Kerberos ticket to a domain controller (DC). If the DC can serve the request (known SPN), it will create a Kerberos ticket, encrypt it using a key constructed from the hash of the user account's password for the account associated with the SPN. It will then proceed to send it to the client. As far as Internet Explorer is concerned, the ticket is an opaque blob.
- Internet Explorer encapsulates the Kerberos ticket provided by LSASS in the "Authorization : Negotiate" header and sends it to the IIS server
- IIS handles the request and routes it to the right application pool (using the host header specified)
- The application pool tries to decrypt the ticket using SSPI/LSASS APIs :
  - If the ticket can be decrypted, Kerberos authentication succeeds and all services associated to the ticket are available (impersonation, delegation if ticket allows it…etc)
  - If the ticket can't be decrypted, a Kerberos error (KRB_AP_ERR_MODIFIED) is returned. This error is a generic error indicating that the ticket has been altered in some way during its transport and could therefore not be decrypted. This error is also logged in the Windows Event Logs
    If you do not explicitly declare SPN, Kerberos authentication will work only if the application pool identity is « Network Service ». In this case, the Kerberos ticket is built using a default SPN that is created in Active Directory when a computer (in this case the server that IIS is running on) is added in the domain. This « default SPN» is associated to the computer account which, under IIS, maps to « Network Service ».
    If your application pool needs to use an identity other than « Network Service », you'll need to declare a SPN (using SETSPN) and associate it with the account used for your application pool identity. A common mistake is to create similar SPNs with different accounts.

And, That is how Kerberos Authentication works….

Now, We all know that NTLM fails but Kerberos works in Double-Hop authentication and that's why Kerberos is so popular..

Simply because it is able to delegate the Authentication request using the kerberos ticket which NTLM can't do.

What is Delegation?

Impersonation gives access to local resources only. Delegation is an extended impersonation capability that enables you to use an impersonation token to access network resources.

If your application uses Kerberos v5 authentication to authenticate its users, you can use Kerberos delegation to pass the user's identity through the layers of your application and to access network resources. If your application does not use Kerberos v5 authentication, you can use protocol transition to switch to Kerberos, and then use delegation to pass on the identity.

Constrained delegation in Windows Server 2003 requires Kerberos authentication. If your application cannot use Kerberos authentication to authenticate its callers, you can use protocol transition to switch from an alternate, non-Windows authentication mode (such as forms or certificate authentication) to Kerberos authentication. You can then use Kerberos with constrained delegation to access downstream network resources.

Why NTLM fails and Kerberos succeeds?

Because that way NTLM works is : Server requires access to the client's real password (Hash) but for security purposes the domain controller doesn't hand out this password, which means the service server has to pass along the client's authentication hash to the DC for verification.

So, there is a need for a round trip to the DC for authentication when using NTLM, something Kerberos doesn't require.

The fact that NTLM depends directly on the base password of the client for each authentication, we can't just pass that around to servers for their own use. This is why NTLM can't be used to give a process the power of delegation of user identity and it can't do double HOP.

Whereas Kerberos doesn't depend on the original user password for authentication. The only time the original password is necessary is when the user first logs on to the Kerberos realm (AD domain) and authenticates to the Authentication Server (a role played by the Domain Controller). After that point, authentication to other services is based on the user possessing session-specific keys which it would only know if it originally authenticated properly to the Authentication Server.

So, when a client authenticates to a front-end server using Kerberos, the server doesn't need to contact a DC for verification. The fact that the client knows the session-specific key for this service proves that it must already have proven its identity with the DC, and that's all the server needs to know.(No DC round trip necessary)

Hence, for the server process to authenticate to the next-hop server process, it no longer needs access to the client's real password! All it needs is the session-specific key for the session with the next server, something we can feel a little more comfortable passing along. The original client forwards this key, along with a ticket for the back-end service, to the front-end server, which can then use it for the next-hop authentication, the service now presenting itself to the next-hop service as the original client.

For more info, Visit https://blogs.msdn.microsoft.com/besidethepoint/2010/05/08/double-hop-authentication-why-ntlm-fails-and-kerberos-works/

Here are a few Things to know conceptually before setting up Kerberos……..

How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0

Overview

When an ASP.NET application impersonates the original caller, it accesses resources by using the security context of the authenticated user. However, the application can only access local resources. To access network resources while impersonating a remote user, your application must use delegation. If your application uses Kerberos authentication to authenticate its users, you can use delegation to pass the caller's identity through the layers of your application, and use it to access network resources. If your application does not use Kerberos authentication, you can use protocol transition to switch from a non-Kerberos authentication mechanism to Kerberos, and then use delegation to pass the identity on.

Protocol Transition

In many situations—for example, if your users access a Web site over the Internet—you cannot use Kerberos authentication because firewalls prevent the client computer from directly communicating with the domain controller. Instead, your application must authenticate the client by using another approach, such as forms authentication, or in an extranet scenario, client certificate authentication.

Windows Server 2003 has a protocol transition feature that permits applications to use a non-Windows authentication mechanism to authenticate users, but still use Kerberos authentication and delegation to access downstream network resources. This allows your application to access downstream servers that require Windows authentication and it allows you to use Windows auditing to track user access to backend resources.

The use of protocol transition to access downstream resources relies on two extensions to the Kerberos protocol. Both extensions are implemented in Windows Server 2003. These extensions are:

Service-for-User-to-Self (S4U2Self) , which allows you to obtain a Windows token for the client by supplying a user principal name (UPN) without a password.
Service-for-User-to-Proxy (S4U2Proxy) , which allows an administrator to control exactly which downstream services can be accessed with the S4U2Self token.

Constrained and Unconstrained Delegation

Kerberos delegation on Windows Server 2000 is unconstrained and servers that are configured as trusted for delegation in Active Directory can access any network resources or any machine on the network while using the impersonated user's security context. This represents a potential security threat, particularly if the Web server is compromised.

To address this issue, Windows Server 2003 introduces constrained delegation. This allows administrators to specify exactly which services on a downstream server or a domain account can access when using an impersonated user's security context.

Note The list of services that can be accessed by delegation is maintained in an Active Directory list referred to as the A2D2 list.

This How To shows how to use protocol transition and constrained delegation in Windows Server 2003 to solve the following common problems:

Using a non-Windows authentication mechanism for external clients and then transitioning to Kerberos authentication to access network resources.
Impersonating Kerberos-authenticated clients and then using their Windows security context to pass their identities through multiple tiers to access network resources.

From <https://msdn.microsoft.com/en-us/library/ms998355.aspx>

From<*https://msdn.microsoft.com/en-us/library/aa480475.aspx*\>

Claims to Windows Token Service (c2WTS) Overview

Windows Identity Foundation

[Starting with the .NET Framework 4.5, Windows Identity Foundation (WIF) has been fully integrated into the .NET Framework. The version of WIF addressed by this topic, WIF 3.5, is deprecated and should only be used when developing against the .NET Framework 3.5 SP1 or the .NET Framework 4. For more information about WIF in the .NET Framework 4.5, also known as WIF 4.5, see the Windows Identity Foundation documentation in the .NET Framework 4.5 Development Guide.]

The Claims to Windows Token Service (c2WTS) is a feature of Windows® Identity Foundation (WIF) that extracts UPN claims from non-Windows security tokens, such as SAML and X.509 tokens, and generates impersonation-level Windows security tokens. This allows a relying party (RP) application to impersonate the user. This might be needed to access back-end resources, such as SQL Servers, that are external to the computer on which the RP application runs.

The c2WTS is a Windows service that is installed as part of WIF. For security reasons, however, the c2WTS works strictly on an opt-in basis. It must be started manually and it runs as the local system account. Furthermore, an administrator must manually configure the c2WTS with a list of allowed callers. By default, the list is empty. For more information, see How to: Request a Token from the c2WTS. WIF invokes the c2WTS using IPC, and the c2WTS does not open any network ports.

If your RP application runs as the local system account, it does not need to use the c2WTS. However, if your RP application runs as the network service account, or is an ASP.NET application, for example, it might need to use the c2WTS to access resources on another computer.

Suppose you have a Web farm that consists of a server that runs an ASP.NET application, which accesses a SQL database on a back-end server. You want to make this application claims-aware. However, the application cannot access the SQL database using the claim that it receives from an STS. Instead, it uses the c2WTS to convert the UPN claim to a Windows security token. This allows it to access the SQL database as before.

(Note that to allow an application to access resources on a different server, a domain admin must configure Active Directory to enable constrained delegation. For information on how to enable constrained delegation, see How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0.)

Note

If the c2WTS is enabled, and the binding is cookie-mode secure conversation, the c2WTS will be used to rehydrate the Windows identity from the UPN that is serialized out into the secure conversation cookie. This means it is possible for authentication to fail when switching between cookie mode and session mode secure conversation, if the c2WTS is enabled but not properly configured.

How to Use the c2WTS to Obtain a Windows Security Token

There are two ways to use the c2WTS: mapToWindows or on-demand calling to the UpnLogon method. If your application always requires impersonation-level Windows security tokens, then you may choose to enable the mapToWindows property on samlSecurityTokenRequirement on the <securityTokenHandlers> element. On the other hand, if your application requires impersonation-level Windows security tokens only for certain use cases, then you may choose to programmatically call the UpnLogon method when required. Note that the useWindowsTokenServiceproperty must be set to true and c2WTS configuration must be added with an appropriate callers list for successful invocation of this method.

WIF provides a method, UpnLogon, which an RP application can call, passing in the UPN claim that it has received from the STS. WIF then invokes the local c2WTS using IPC. UpnLogon returns a WindowsIdentity that represents the user. The following illustration shows how this works:

A client request arrives at the RP application. This request requires the RP application to access an external resource. To do this, the RP application must impersonate the user.
The RP application redirects the client to the IP-STS for authentication.
The IP-STS authenticates the user and issues a SAML token that contains a UPN claim (that is, a claim of type https://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn). Note that c2WTS requires a UPN string to perform its operations.
The client submits the SAML token to the RP application.
The RP application validates the SAML token and extracts the UPN claim.
The RP application passes the UPN claim to the UpnLogon method as a parameter and gets back a Windows security token. This method call is automatically done by the Saml 1.1 and Saml 2 SecurityTokenHandlers when the mapToWindows property on the SamlSecurityTokenRequirement on these SecurityTokenHandlers is set to true and the value of useWindowsTokenService on the <windowsClaimsIdentity> element in the <microsoft.IdentityModel> is set to true.
The RP application uses the Windows Identity to impersonate the user and accesses the resource.

From <https://msdn.microsoft.com/en-us/library/ee517278.aspx>

How to configure Claim to Windows Token Services in SharePoint 2010 with Kerberos Authentication

From <https://support.microsoft.com/en-in/help/2722087/how-to-configure-claim-to-windows-token-services-in-sharepoint-2010-wi>

SharePoint: Facts and Troubleshooting the Claims To Windows Token Service (C2WTS)

The Claims to Windows Token Service (from here on denoted as "C2WTS") is only used when SharePoint needs to get data from an external system that does not understand claims. Examples include (but are not limited to):

SQL Server Reporting Services (SSRS)
Excel Web Services (EWS)
PowerPivot / Power View
Business Data Connectivity (BDC) / Business Connectivity Services (BCS) / External Content Types (ECT) / External Lists.
Other SharePoint "BI" stuff.
Custom Code that does user impersonation.

From <https://blogs.technet.microsoft.com/spjr/2017/06/27/sharepoint-facts-and-troubleshooting-the-claims-to-windows-token-service-c2wts/>

Service Principal Names

A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name.

If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. For more information about SPN format and composing a unique SPN, see Name Formats for Unique SPNs.

The Kerberos v5 authentication protocol uses service principal names (SPNs) for the following reasons:

To support mutual authentication.
To enable a client to request tickets, which in turn, enables the client to communicate with a particular service.

For example, if a client needs to obtain a ticket and authenticate with a particular service (MyService), which is running on a computer (MyServer) that is listening on port 4766, then the client requests a ticket from the KDC by using a name constructed from that information, as shown here:

MyService/MyServer:4766

An SPN that is registered in Active Directory maintains a mapping between this name and the domain account under which the requested service is running. By using this mechanism, it becomes difficult for a malicious user to impersonate a service on the network

For more info, Visit https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx

Kerberos authentication and Kernel Mode Authentication:

Note: Kernel Mode Authentication is not supported in SharePoint 2010 Products. This information is provided for informational purposes only.

Beginning in IIS version 7.0, there is a new authentication feature called Kernel Mode Authentication. When an IIS web site is configured to use Kernel Mode authentication, HTTP.sys will authenticate the client's requests instead of the application pool's worker process. Because HTTP.sys runs in kernel mode this yields better performance but also introduces a bit of complexity when configuring Kerberos. This is due to HTTP.sys running under the computer's identity and not under the identity of the worker process. When HTTP.sys receives a Kerberos ticket, by default it will attempt to decrypt the ticket using the server's encryption key (aka secret) and not the key for the identity the worker process is running under.

If a single web server is configured to use Kernel Mode authentication, Kerberos will work without any additional configuration or additional SPNs because the server will automatically register a HOST SPN when it is added to the domain. If multiple web servers are load balanced, the default Kernel Mode Authentication configuration will not work, or at least will intermittently fail, because the client has no way of ensuring the service ticket they received in the TGS request will work with the server authenticating the request.

To work around this issue you can do the following:

Turn off Kernel Mode Authentication
Configure HTTP.sys to use the IIS application pool's identity when decrypting service tickets. See Internet Information Services (IIS) 7.0 Kernel Mode Authentication Settings.
You may also need a hotfix when configuring HTTP.sys to use the application pool's credentials: FIX: You receive a Stop 0x0000007e error message on a blue screen when the AppPoolCredentials attribute is set to true and you use a domain account as the application pool identity in IIS 7.0

----------------------------------------------------------------------------------------------------------------------------

And, That's all for introduction and understanding of Windows AUTHENTICATION.

This was Part 1 in my Integrated Windows Authentication (Negotiate, NTLM, Kerberos) Series. Kerberos Setup and Troubleshooting, Best Practices are covered in my Part2 and Part3 of this series. I highly recommend to check them out too for complete information around this Topic! Links below:

Until then, Happy SharePointing !!

Check other Part links in this series too:

Part2: Step by step Guide for Configuring Kerberos Authentication in SharePoint 2013/2016

Part3: Troubleshooting Kerberos authentication and things to check when it fails

Additional References:

Explained: Windows Authentication in ASP.NET 2.0

Windows Authentication Deep Dive What Every Administrator Should Know

Kerberos Survival Guide

Kerberos Authentication Demo

Kerberos Explained

How the Kerberos Version 5 Authentication Protocol Works

Kerberos messages and tickets