Let me start by mentioning this --> C:\Windows\System32\Wininet.dll file calls the InitializeSecurityContext function to build the Kerberos ticket.

The InitializeSecurityContext (Kerberos) function initiates the client side, outbound security context from a credential handle. The function is used to build a security context between the client application and a remote peer. InitializeSecurityContext (Kerberos) returns a token that the client must pass to the remote peer, which the peer in turn submits to the local security implementation through the AcceptSecurityContext (Kerberos) call. The token generated should be considered opaque by all callers.

Typically, the InitializeSecurityContext (Kerberos) function is called in a loop until a sufficient security context is established.

From <https://msdn.microsoft.com/en-us/library/aa375507(VS.85).aspx>

I have explained in my Part1 post about how the kerberos authentication works, I strongly recommend reading that first before troubleshooting so we know what we are doing.

So, when the Kerberos AUTHETICATION FAILS or maybe not yet, This is how you verify/check/resolve:

Test browser authentication:

After configuring Active Directory, DNS and SharePoint Server you can now test whether Kerberos authentication is configured correctly by browsing to your web applications. When testing in the browser, ensure the following conditions are met:

1. The test user is logged into a Windows 7 or higher computer joined to the domain that SharePoint Server is installed in, or is logged into a domain trusted by the SharePoint Server domain.
2. Integrated Windows authentication is enabled in the browser. Under Internet Options in the Advanced tab, make sure Enable Integrated Windows Authentication* is enabled in the Security section:

1. Local intranet is configured to automatically logon clients. Under Internet explorer option, in the Security tab, select Local Intranet and click the Custom level button. Scroll down and make sure that Automatic logon only in Intranet zone is selected.
2. Ensure that Automatically detect intranet network is selected in Internet options->Security->Intranet Zone->Sites.
3. If you are using fully qualified domain names to access the SharePoint Server web applications, ensure that the FQDNs are included in the intranet zone, either explicitly or by wildcard inclusion (for example, "*.vmlab.local").

The easiest way to determine if Kerberos authentication is being used is by logging into a test workstation and navigating to the web site in question. If the user isn't prompted for credentials and the site is rendered correctly, you can assume Integrated Windows authentication is working.

From <https://technet.microsoft.com/en-us/library/gg502602(v=office.14).aspx>

If any of the above is not set properly, then Delegation fails even when Kerberos authentication works:

• Check Internet Explorer Zone used for the URL.

  Kerberos delegation is only allowed for the « Intranet » and « Trusted Sites » zones (in other words, IE sets the ISC_REQ_DELEGATE flag when it calls InitializeSecurityContext only if the zone computed is « Intranet » or « Trusted Sites » )

• The account used for the application pool identity must have the « Trusted for delegation » flag set
  If delegation still fails, you may consider using DELEGCONFIG. This tool allows to diagnose - and resolve - dozens of issues preventing Kerberos authentication from working correctly. Check the following link for more details: https://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx

The next step is to determine if the negotiate protocol was used to negotiate Kerberos authentication as the authentication provider for the request. This can be done in the following ways:

SharePoint server Front-end Windows security logs

If Kerberos authentication is working correctly you will see Logon events in the security event logs on the front-end webs with event ID = 4624. In the general information for these events you should see the security ID being logged onto the computer and the Logon Process used, which should be Kerberos.

Event is here below:

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 5/6/2018 10:27:48 PM

Event ID: 4624

Task Category: Logon

Level: Information

Keywords: Audit Success

User: N/A

Computer: SP.contoso.com

Description:

An account was successfully logged on.

Subject:

Security ID:                NULL SID

Account Name:                -

Account Domain:                -

Logon ID:                0x0

Logon Type:                        3

Impersonation Level:                Impersonation

New Logon:

Security ID:                contoso\spfarm

Account Name:                spfarm

Account Domain:                contoso

Logon ID:                0x15636

Logon GUID:                {02398194-25d2-4852-4d60-026f36f6632a}

Process Information:

Process ID:                0x0

Process Name:                -

Network Information:

Workstation Name:

Source Network Address:        -

Source Port:                -

Detailed Authentication Information:

Logon Process:                Kerberos

Authentication Package:        Kerberos

Transited Services:        -

Package Name (NTLM only):        -

Key Length:                0

Event Xml:

<Event xmlns="https://schemas.microsoft.com/win/2004/08/events/event">

<System>

<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />

<EventID>4624</EventID>

<Version>1</Version>

<Level>0</Level>

<Task>12544</Task>

<Opcode>0</Opcode>

<Keywords>0x8020000000000000</Keywords>

<TimeCreated SystemTime="2018-05-07T02:27:48.081988200Z" />

<EventRecordID>1044763</EventRecordID>

<Correlation />

<Execution ProcessID="620" ThreadID="3800" />

<Channel>Security</Channel>

<Computer>SP.contoso.com</Computer>

<Security />

</System>

<EventData>

<Data Name="SubjectUserSid">S-1-0-0</Data>

<Data Name="SubjectUserName">-</Data>

<Data Name="SubjectDomainName">-</Data>

<Data Name="SubjectLogonId">0x0</Data>

<Data Name="TargetUserSid">S-1-5-21-2477750165-3421169653-395798871-1106</Data>

<Data Name="TargetUserName">spfarm</Data>

<Data Name="TargetDomainName">contoso</Data>

<Data Name="TargetLogonId">0x15636</Data>

<Data Name="LogonType">3</Data>

<Data Name="LogonProcessName">Kerberos</Data>

<Data Name="AuthenticationPackageName">Kerberos</Data>

<Data Name="WorkstationName">

</Data>

<Data Name="LogonGuid">{02398194-25D2-4852-4D60-026F36F6632A}</Data>

<Data Name="TransmittedServices">-</Data>

<Data Name="LmPackageName">-</Data>

<Data Name="KeyLength">0</Data>

<Data Name="ProcessId">0x0</Data>

<Data Name="ProcessName">-</Data>

<Data Name="IpAddress">-</Data>

<Data Name="IpPort">-</Data>

<Data Name="ImpersonationLevel">%%1833</Data>

</EventData>

</Event>

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

Check if the IIS server is actually configured to send the WWW-Authenticate: Negotiate header:

If IIS doesn't send this header, you'll need to use ADSUTIL to set the Negotiate header though the NTAuthenticationProviders metabase property (see https://support.microsoft.com/kb/215383)
Note: by default, the NTAuthenticationProviders property is not set which causes IIS to send both Negotiate and NTLM headers:

To check or set the property: Locate the directory that contains the Adsutil.vbs file. By default, this directory is C:\Inetpub\Adminscripts.

Use the following command to retrieve the current values for the NTAuthenticationProviders metabase property:
cscript adsutil.vbs get w3svc/WebSite/root/NTAuthenticationProviders
In this command, WebSite is a placeholder for the Web site ID number. The Web site ID number of the default Web site is 1.

For Example:

PS C:\Users\Administrator.contoso> cscript "C:\inetpub\AdminScripts\adsutil.vbs" get w3svc/1834077867/root/NTAuthenticat

ionProviders

Microsoft (R) Windows Script Host Version 5.8

Copyright (C) Microsoft Corporation. All rights reserved.

NTAuthenticationProviders : (STRING) "Negotiate,NTLM"

If the command above does not return the string "Negotiate,NTLM," use the following command to enable the Negotiate process:
cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders "Negotiate,NTLM"

Example: cscript adsutil.vbs set w3svc/1834077867/root/NTAuthenticationProviders "Negotiate,NTLM"

Warning: If you edit the metabase incorrectly, you can cause serious problems that may require that you reinstall any product that uses the metabase. Microsoft cannot guarantee that problems that result if you incorrectly edit the metabase can be solved. Edit the metabase at your own risk.

Note: Always back up the metabase before you edit it.

From <https://support.microsoft.com/en-us/help/215383/how-to-configure-iis-to-support-both-the-kerberos-protocol-and-the-ntl>

Check if the client and server are on the same machine:

Kerberos is not enabled in this configuration and a hard coded loopback check will always force usage of NTLM in this scenario. Note that NTLM may also not work in this configuration (see https://support.microsoft.com/kb/896861 for more details).

Workarounds:

Set DisableStrictNameChecking to 1 And

Either

[Preferred method if NTLM is needed]Create "Multi-String Value" BackConnectionHostNames = "HostName of the site" at location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

OR

Create Dword "DisableLoopbackCheck" = 1 at location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Duplicate or Wrong Service principal name set for Application Pool identity:

If a wrong SPN is set for the APP Pool identity or if there are Duplicate SPNs set, kerberos AUTHENTICATION fails because it cannot determine which account to use to Decrypt the Ticket.

We can use these SETSPN.EXE commands to check any SPN related issues:

SETSPN -L [Application Pool account] --> Will list all SPNs registered for that account.

SETSPN -X --> Will show any Duplicate SPNs

SETSPN -Q --> Can be used to Query for Specific or all SPNs.

SETSPN.EXE Usage: C:\Windows\system32\setspn.exe [modifiers switch] [accountname]

Where "accountname" can be the name or domain\name

of the target computer or user account

Edit Mode Switches:

-R = reset HOST ServicePrincipalName

Usage: setspn -R accountname

-S = add arbitrary SPN after verifying no duplicates exist

Usage: setspn -S SPN accountname

-D = delete arbitrary SPN

Usage: setspn -D SPN accountname

-L = list SPNs registered to target account

Usage: setspn [-L] accountname

Query Mode Switches:

-Q = query for existence of SPN

Usage: setspn -Q SPN

-X = search for duplicate SPNs

Usage: setspn -X

Some Example commands with outputs are as below:

PS C:\Users\Administrator.contoso> SetSPN -S HTTP/Kerberos.contoso.com:9090 Contoso\SPAppPool

Checking domain DC=contoso,DC=com

Registering ServicePrincipalNames for CN=SPAppPool,CN=Users,DC=contoso,DC=com

HTTP/Kerberos.contoso.com:9090

Updated object

PS C:\Users\Administrator.contoso> setspn -l contoso\SPAppPool

Registered ServicePrincipalNames for CN=SPAppPool,CN=Users,DC=contoso,DC=com:

HTTP/Kerberos.contoso.com:9090

HTTP/Kerberos:9090

HTTP/Kerberos.contoso.com

HTTP/Kerberos

PS C:\Users\Administrator.contoso> SetSPN -S HTTP/Kerberos Contoso\SPAppPool

Checking domain DC=contoso,DC=com

CN=SPAppPool,CN=Users,DC=contoso,DC=com

HTTP/Kerberos.contoso.com:9090

HTTP/Kerberos:9090

HTTP/Kerberos.contoso.com

HTTP/Kerberos

Duplicate SPN found, aborting operation!

PS C:\Users\Administrator.contoso> setspn -Q http/sp

Checking domain DC=contoso,DC=com

No such SPN found.

PS C:\Users\Administrator.contoso> setspn -Q */SQL

Checking domain DC=contoso,DC=com

CN=SQL,CN=Computers,DC=contoso,DC=com

MSSQLSvc/SQL.contoso.com:1433

MSSQLSvc/SQL.contoso.com

TERMSRV/SQL

TERMSRV/SQL.contoso.com

WSMAN/SQL

WSMAN/SQL.contoso.com

RestrictedKrbHost/SQL

HOST/SQL

RestrictedKrbHost/SQL.contoso.com

HOST/SQL.contoso.com

Existing SPN found!

PS C:\Users\Administrator.contoso> setspn -Q */sp

Checking domain DC=contoso,DC=com

CN=SP,CN=Computers,DC=contoso,DC=com

TERMSRV/SP

TERMSRV/SP.contoso.com

WSMAN/SP

WSMAN/SP.contoso.com

RestrictedKrbHost/SP

HOST/SP

RestrictedKrbHost/SP.contoso.com

HOST/SP.contoso.com

Existing SPN found!

PS C:\Users\Administrator.contoso> setspn -X

Checking domain DC=contoso,DC=com

Processing entry 0

found 0 group of duplicate SPNs.

So, for same Service there should not be 2 different Service accounts for which SPNs are registered otherwise IIS will not know which account to decrypt from.

Tools:

1. Klist
2. Kerberos Authentication tester
3. Fiddler
4. Microsoft network monitor

Klist.EXE:

this command-line tool helps you list and purge tickets on your client machine. You can list tickets to verify the validity of tickets. You can also check for other details, such as the permissible flags, SPN type, the client, and server details.

KLIST output (in this example, for a Site URL: https://kerberos:9090):

PS C:\Users\Administrator.contoso> klist

Current LogonId is 0:0x16958c

Cached Tickets: (2)

#0> Client: Administrator @ CONTOSO.COM

Server: krbtgt/CONTOSO.COM @ CONTOSO.COM

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize

Start Time: 5/6/2018 21:43:29 (local)

End Time: 5/7/2018 7:43:29 (local)

Renew Time: 5/13/2018 21:43:29 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

Cache Flags: 0x1 -> PRIMARY

Kdc Called: DC.contoso.com

#1> Client: Administrator @ CONTOSO.COM

Server: HTTP/kerberos @ CONTOSO.COM

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize

Start Time: 5/6/2018 21:43:29 (local)

End Time: 5/7/2018 7:43:29 (local)

Renew Time: 5/13/2018 21:43:29 (local)

Session Key Type: RSADSI RC4-HMAC(NT)

Cache Flags: 0

Kdc Called: DC.contoso.com

So, if server does not have same Decryption mechanism (Say RC4) so it can't decrypt tickets. In that case, make sure you enable AES encryption for Service account properties.

Run these two commands below if you want to Purge user and System level Kerberos Tickets.

PS C:\Users\Administrator.contoso> klist purge

Current LogonId is 0:0x16958c

Deleting all tickets:

Ticket(s) purged!

PS C:\Users\Administrator.contoso> klist -li 0x3e7 purge

Current LogonId is 0:0x16958c

Targeted LogonId is 0:0x3e7

Deleting all tickets:

Ticket(s) purged!

Kerberos Authentication Tester (It can be found here: https://blog.michelbarneveld.nl/michel/archive/2009/12/05/kerberos-authentication-tester.aspx)

Kerberos Authentication Tester Features:

• It shows what authentication method is used in a web request: None, Basic, NTLM or Kerberos
• It shows the SPN used in case of Kerberos
• It shows the HTTP status
• It shows the HTTP Headers of the request.
• It shows the version of NTLM used (v1 or v2)
• It has a detailed view with a complete breakdown of the Authorization header. (Yep, went through all the RFCs to dissect the Kerberos and NTLM packages)
• It shows your current Kerberos tickets and allows you to remove them (like klist.exe)

The blue details link at the top right shows a new screen with the details of the request, including a breakdown of the Authorization HTTP Header. You can also save this XML.

It shows all kerb Tickets.

Network Monitor/WireShark: network trace capture and review tools. You can review trace to identify Kerberos errors.

Best way to get the network capture is:

1. To reduce the possibility of caching data, do one of the following:

•Close/Reopen client application

•Logoff/Logon client workstation

•Reboot client workstation

2. Start the network capture

3. Clear DNS cache using:

ipconfig /flushdns

4. Clear NetBIOS cache using:

nbtstat –RR

5. Clear user Kerberos tickets using:

klist purge

6. Clear system / computer Kerberos tickets using (Vista or higher only):

Klist –li 0x3e7 purge

7. Reproduce the authentication failure with the application in question

8. Stop the network capture

Now that you have the capture, you can filter the traffic using the string 'Kerberosv5' if you are using Network Monitor. If you are using Wireshark, you can filter using the string 'Kerberos'.

To be more thorough, load the Authentication Traffic filter that shows packets containing Kerberos tickets as well. You can do this by clicking the Load Filter button, choose Standard Filters, and then click Authentication Traffic.

OR add this Filter:

KerberosV5

OR KerberosV5.KrbError.Sname

OR KerberosV5.AsReq

OR KerberosV5.AsRep

OR KerberosV5.TgsReq

OR KerberosV5.TgsRep

Click 'Apply' to begin filtering…

In my Network trace examples below:

I am using SQL as my Client machine

192.168.2.50 is DC (KDC)

SP is SharePoint server

Analysing Network trace……………………….

First, we see AS (Authentication Server) request and response.

DC given AS response Ticket (TGT) to client.

(Service name) Sname requested and sent is krbtgt:

Sname: krbtgt/CONTOSO.COM

Then Client uses AS response Ticket to make TGS request (Service ticket) to KDC.

TGS Response ticket (Service Ticket) is sent to client by KDC.

(Service name) Sname requested and sent is HTTP:

Sname: HTTP/WebApp name

FIDDLER:

1st request will be anonymous if user is not authenticated.

401 is what we see first ……………..

Then we see 302 client Presenting kerberos Ticket to Server (SP) where server responds with a Kerberos Reply after decrypting the ticket with App Pool Identity.

If the Ticket presented by Client is valid then server moves request (302) to the page Client should be going to..

It could be home page of the Site, as in this example is:

Location: https://teams/_layouts/15/start.aspx#/SitePages/Home.aspx

In Next step, Client uses it's Original Kerberos ticket to obtain data.

SO, we see 200 …………….. And we get the page..

Then further, client uses same ticket to access the Site resources (pages, links, files etc.).

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

And that's all you might need for almost all of your Kerberos related issues - Of Course, wrt SharePoint :)

Happy SharePointing !!

Check other Part links in this series too:

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

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

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

Double-hop authentication: Why NTLM fails and Kerberos works

Kerberos configuration known issues (SharePoint Server 2010)

Things to check when Kerberos authentication fails using IIS/IE…

Kerberos and LDAP Error Messages

Kerberos errors in network captures

Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0/7.5

Kerberos RFC:

https://www.ietf.org/rfc/rfc1510.txt

https://www.ietf.org/rfc/rfc4120.txt

SharePoint web application: https://docs.microsoft.com/en-us/sharepoint/administration/create-a-web-application

DNS HOST (A) record: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/add-a-host--a--resource-record-to-corporate-dns-for-a-federation-server

By now, you should have a SharePoint web application with a host header (host header is not mandatory to have)

So, let's go into step 3…..

Set Service principal name (SPN) for the Service account running Application Pool of the Web application:

Now if you try to go to option 4 of setting Delegation without doing step 3, below is what will happen.

Delegation tab in Active directory users and computers (ADUC) for the account will not be available until a SPN is set.

This command will give you a black result:

PS C:\Users\Administrator> setspn -L Contoso\Spsvc

Registered ServicePrincipalNames for CN=SharePoint Service,CN=Users,DC=contoso,DC=com:

'Attribute Editor' tab also shows you servicePrincipalName value that has been set, in our case - It is not Set yet.

Delegation tab is only displayed when there is at least one value set in the servicePrincipalName attribute.

Let me quickly show you an account which has SPN set already (just as an example account beforehand on which I had set SPN - I will show you how to do so in this post later)

This command will show the SPN that is set.

PS C:\Users\Administrator> setspn -L Contoso\Spfarm

Registered ServicePrincipalNames for CN=SharePoint Farm,CN=Users,DC=contoso,DC=com:

host/adfs.contoso.com

And Even 'Attribute Editor' tab also shows servicePrincipalName value that has been set.

NOW, let's move to actually setting SPN.

Setting a ServicePrincipalName (SPN) can be performed in a number of ways; ADSIEdit, Attribute Editor in ADCU and SETSPN.EXE.

You need to first set the SPNs and then enable Delegation on the service accounts (Reason I've already explained above)

We are going to be using SETSPN.EXE Utility to Set ServicePrincipalName (SPN) of the service account.

In Active Directory, the servicePrincipalName (SPN) attribute is a multivalued, nonlinked attribute that is built from the DNS host name. The SPN is used in the process of mutual authentication between the client and the server hosting a particular service. The client finds a computer account based on the SPN of the service to which it is trying to connect.

Setspn.exe:

This command-line tool allows you to read, modify, and delete the Service Principal Names (SPN) directory property for an Active Directory service account. SPNs are used to locate a target principal name for running a service. You can use Setspn to view the current SPNs, reset the account's default SPNs, and add or delete supplemental SPNs.

SPN Format

When you manipulate SPNs with the Setspn tool, the SPN must be entered in the correct format. The format of an SPN is serviceclass/host:port/servicename, in which each item represents a name or value. Unless the service name and port are not standard, you do not have to enter them when you use Setspn. For example, if you have a service with the following characteristics:

• Name: MyService
• Running on a computer named DCA
• Uses the TCP or UDP port 8088
• Service name: MyS
• Location: in the directory under an organizational unit (OU) named CS, in a domain named cpandl.com

the SPN looks like the following:

MyService/DCA.cpandl.com:8088/CN=MyS,OU=CS,DC=cpandl,DC=com

From <https://technet.microsoft.com/pt-pt/library/cc773257(v=ws.10).aspx>

The HOST SPN (host/server.domain.com) works for multiple services like HTTP & RPCSS. If you would like to see the default Host to SPN mappings use LDP or ADSI Edit and navigate to: cn=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=[Your Domain Component]. Then look at the sPNMappings attribute.

In our case, we are going to be using SETSPN command with these Switches below:

General Steps are like these below………

Run setspn command with your web application's Application Pool Service Account – e.g. DomainName/App pool service account. To do so, the Application Pool Service account must have membership in Domain Administrator or Enterprise Administrator.

• Open command prompt "Run as" Administrator.
• (Optional step) Check if any SPN is registered for Application Pool Service Account.
  
  setspn -L App pool service account
• (Important command) Register SPN for Host Name on Application Pool Service Account.
  
  setspn -S HTTP/spn host name <space>App pool service account
  
  Note - The HTTP service above is case insensitive. Do not configure service principal names with "https" even if the web application uses SSL. If your web application has port number (e.g. port number - 1234), then it should be after Host name; else SPN will get registered but service ticket won't get generated.
• (Important command) Now, register SPN for the Full Qualified Domain Name (FQDN) also.
  
  setspn -S HTTP/Full qualified domain name <space>App pool service account
  
  Note - If your web application has port number, then it should be after FQDN name; else SPN will get registered but service ticket won't be generated.
• (Optional step) You can check numbers of service(s) registered for Application Pool Service Account.
  
  "-L" option will list all the service(s).
  setspn -L<space>App pool service account
  
  If the command ran successfully, you can see the list of services associated with the Service Account - App Pool Service Account.
• (Important command) For DB Server, instead of HTTP service, register MSSQLSvc service to register the SPN.

Setting SPNs:

To create the service principal names the following commands were executed:

SetSPN -S HTTP/Kerberos Contoso\SPAppPool

SetSPN -S HTTP/Kerberos.contoso.com Contoso\SPAppPool

SetSPN -S HTTP/Kerberos:9090 Contoso\SPAppPool

SetSPN -S HTTP/Kerberos.contoso.com:9090 Contoso\SPAppPool

In our example we used a new command line switch, -S, introduced in Windows Server 2008 that checks for the existence of the SPN before creating the SPN on the account. If the SPN already exists, the new SPN is not created and you see an error message.

If duplicate SPNs are found, you have to resolve the issue by either using a different DNS name for the web application, thereby changing the SPN, or by removing the existing SPN from the account it was discovered on.

Service Principal Names and SSL

It is common to confuse Kerberos Service Principal Names with URLs for http web applications because the SPN and URI formats are very similar in syntax, but it's important to understand that they are two very separate and unique things. Kerberos service principal names are used to identify a service, and when that service is an http application, the service scheme is "HTTP" regardless if the service is access with SSL or not. This means that even if you access the web application using "https://someapp" you do not, and should not, configure a service principal name with HTTPS, for example "HTTPS/someapp

From <https://technet.microsoft.com/en-us/library/gg502602(v=office.14).aspx>

Now………..

After configuration, if I go to Attribute editor of the Service account, I see SPNs:

SPNs can be added or removed from "Attribute editor" tab also from user's properties but recommended way to do is through SetSPN Utility.

Having Set SPN in step 3, let's move to STEP 4……………..

Allow Trust for delegation from DC ADUC - Delegate the Service account to "Trust the use for delegation to Kerberos".

Go to ADUC, locate your service account and go to it's properties by right clicking on it.

Click on Delegation Tab!

Delegation can be set by any of these 3 options:

Significance of all those 3 options are given below …………..

To configure a service's account for delegation if the service runs under its own domain user account

• Right-click the user object in Active Directory Users and Computers.
• Click Properties.
• Click the Delegation tab.
• If Do not trust this computer for delegation is selected, select the appropriate option:
• If the Trust this computer for delegation to any service (Kerberos only) option is selected, then the account is using unconstrained delegation, which is not recommended.
• If the Trust this computer for delegation to specified services only option is selected, then the account is using constrained delegation.
• If the Use Kerberos Only option is selected, then the account is using constrained delegation without protocol transition.
• If the Use any authentication protocol option is selected, then the account is using constrained delegation with protocol transition.

   

  From <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772815(v=ws.10)>

   

   

  Moving on to Adding Delegation…………………..

  Go to account properties> Delegation tab> Trust this computer for delegation to specified services only> Use any authentication protocol> Click on Add> Users and computers> Type Service account> check names.

  

   

  

   

  Click ok.

   

  

   

  Click 'Select All' to select all services for delegation and click ok.

   

  

   

   

  With that, Moving to Step 5……………..

  Configure Kerberos in IIS: Set Kerberos as 'Top' Authentication 'provider' over NTLM and uncheck "Enable Kernel-mode" authentication.

   

• Go to IIS manager> Sites Tab> Select the web application - and in the middle pane, double click on Authentication under IIS section.
• In the Authentication dialog, select Windows Authentication.
• Click on Providers in the right actions pane.
• Verify that Negotiate and NTLM are listed. Note that Negotiate option should be on the top.
• Click Cancel and then again in the right actions pane, click on Advanced Settings.
• Verify in the Advanced Settings dialog that Extended Protection is Off and that "Enable Kernel-mode" authentication is unchecked.
• Click Cancel.
• Ignore below warnings.
• Update Site Bindings with Host Name and default Port number 80. If the web application's port number is not default port (i.e. port 80), then we need to convert it to port 80; else run SPN commands with non default port number

   

   

  After this, our setup is done but We need to Verify that Kerberos authentication is enabled……………

   

   

  To verify that Kerberos authentication is enabled on the web site

  • Open IIS manager.
  • Select the IIS web site to verify.
  • In Features View, under IIS, double click Authentication.
  • Select Windows Authentication which should be enabled.
  • On the right hand side under Actions, select Providers. Verify Negotiate is at the top of the list.

Also, Verify that Kernel mode authentication is disabled……………..

Kernel mode authentication is not supported in SharePoint Server 2010. By default, all SharePoint Server Web Applications should have Kernel Mode Authentication disabled by default on their corresponding IIS web sites. Even in situations where the web application was configured on an existing IIS web site, SharePoint Server disables kernel mode authentication as it provisions a new web application on the existing IIS site.

To verify that kernel mode authentication is disabled

• Open IIS manager.
• Select the IIS web site to verify.
• In Features View, under IIS, double click Authentication.
• Select Windows Authentication, which should be enabled.
• Click Advanced Settings.
• Verify both EAP and Kernel Mode Authentication are disabled.

From <https://technet.microsoft.com/en-us/library/gg502602(v=office.14).aspx>

If everything is good, then by now, you have successfully configured Kerberos AUTHENTICATION for SharePoint Web application.

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

Next step is to verify that kerberos AUTH is actually working or not!

Steps to verify and best practices are mentioned in my Part3 post here … … .. .. …. .. …. …. --> See you there!

Check other Part links in this series too:

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

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

Double-hop authentication: Why NTLM fails and Kerberos works

Kerberos configuration known issues (SharePoint Server 2010)

Things to check when Kerberos authentication fails using IIS/IE…

Kerberos and LDAP Error Messages

Kerberos errors in network captures

Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0/7.5

Kerberos RFC:

https://www.ietf.org/rfc/rfc1510.txt

https://www.ietf.org/rfc/rfc4120.txt

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.)

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:

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

Double-hop authentication: Why NTLM fails and Kerberos works

Kerberos configuration known issues (SharePoint Server 2010)

Things to check when Kerberos authentication fails using IIS/IE…

Kerberos and LDAP Error Messages

Kerberos errors in network captures

Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0/7.5

Kerberos RFC:

https://www.ietf.org/rfc/rfc1510.txt

https://www.ietf.org/rfc/rfc4120.txt

• We navigated to command prompt > C:\windows\Microsoft.Net\Framework\v2.0.50727
• Ran this command to install SPAdminV4 service:

• It completed successfully.
• Admin service started appearing in services console and we were able to start it successfully on the SharePoint server.