Note: In all the documentations for kerberos double hop, you will find terms like "Front End", "Back End", "Middle tier", "Web Front End (WFE)"
Front End: When talking about the SharePoint Server and the SQL Server, SharePoint Server is called the Front End
Middle Tier: When taking about Double Hop, The SharePoint Server is a Middle Tier. We access the SharePoint Server from our client machine and the SharePoint server then contacts the SQL Server to fetch the data.
So "Front End" / "Middle Tier" is the same in most of the case - SharePoint Server
We can have multiple Middle Tiers like Excel Services, Analysis Services etc. These server (Middle Tiers) can be alone or in conjunction with other. Like, we can have a SharePoint Server and an Excel Server both on different servers. Sites are hosted on SharePoint Server and Excel data is fetch from the Excel Server.
So, a user on the client machine access a site hosted on the SharePoint Server and tries to view a Excel Sheet. The Excel Sheet is hosted on the Excel Server, so the Sharepoint Server contacts the Excel Sever. Now since all the data is stored on SQL, The Excel Server contacts the SQL Server to get that data
I this scenario, we have 2 Middle Tiers and 1 Back End Server. The bottom line is that what so ever troubleshooting that you will perform for the SharePoint Server, the same set of troubleshooting you have to perform for the Excel Server or for that sake any Middle Tier
Back End: The SQL Server in this scenario is a Back End Server
Web Front End: Also known as WFE, the SharePoint Server is technically known as a WFE
"Trust Computer for Delegation" is turned on by default on all the domain controllers. Still do a recheck
"Trust Computer for Delegation" is NOT turned on by default on the Member Servers. So turn it "ON" on the SharePoint Server or on all the Middle Tier (SharePoint Server being the Middle Tier)
We will get a warning about the delegation being security sensitive operation. Lets talk about delegation in brief
Delegation: What is delegation? Delegation is a way to give authority to someone so that he can do the work on your name. Lets take about delegation in context of SharePoint and SQL
SharePoint Services are running in the context of "SP_Admin"
SQL Services are running in the context of "SQL_Admin"
A user tries to access s SharePoint Site from his client machine. SharePoint Server have to get the data from the SQL Server as all the data is stored on the SQL Server. Now when the SharePoint Server tries to contact the SQL Server, then whose credentials will it use? It will use the credentials of "SP_Admin" becuase you have authorized the SharePoint Server to be Delegated.
A way to check in whose context the SharePoint Site is Running
A way to check in whose context the SQL Services are running on the SQL Server
A way to check under whose context the SharePoint Site is running. On the SharePoint Server, open the IIS Console -> Application Pools -> WebsiteName -> Properties -> Identity
Knowing these account name (SQL and SharePoint) is important as we have to check the option "Account is Trusted for Delegation" on the SharePoint Account and SPNs on the SQL Account
The SPNs can be added either using ADSIEDIT or using Setspn Utility
Where to add the SPNs: If the SharePoint and SQL Services were running the default "Local System" account, then there was no need to add SPNs. The SPNs would have been added automatically under their respective machine accounts - SharePoint SPNs in Win2k3-SP Machine Account and SQL SPNs in Win2k3-SQL Machine Account
But is SharePoint and SQL runnings in the context of local System Account - No
So where should we register the SPNs?
SPNs have to be registered in the service accounts in whose context the services are running - SharePoint SPNs in SP_Admin Account and SQL SPNs in SQL_Admin Account
Note: SP_admin and SQL_Admin are just the names gien to these accounts for this lab. These are not the default or built-in account
Format for SQL SPN
MSSQLSvc/<NetBIOS Name of the SQL Server>:1433
MSSQLSvc/<FQDN of the SQL Server>:1433
Format for SharePoint SPN
HTTP/<Name of the SharePoint Site URL>
HTTP/<Name of the SharePoint Site URL><Domain Name>
HTTP/<NetBIOS Name of the SharePoint Server>
HTTP/<FQDN Name of the SharePoint Server>
Once all the troubleshooting has been done, lets take a Netmon Capture while accessing the SharePoint Site
This time we should be able to browse the site and should see some Kerberos Traffic in Netmon
So here we are.... We can view the site and can see Kerberos Traffic in Netmon...
Trying to view the Kerberos Traffic from another server as well
Along with, we will get Event ID on the Domain Controller stating that the user tried got a Kerberos Ticket while accessing the Site
Recap about the location where we need to enable Kerberos Authentication on SharePoint. Remember, we will not enable Kerberos Authentication on Central Administration bit on the site that has been created by the administrator. If we enable kerberos authentication on the central administration and the central administration goes down then that mean that the complete sharepoint goes down. Then we have to manage the sharepoint through command line only till the time we fix central administration
Our site on Kerbeos!!!
Final Recap of Troubleshooting "The Double Hop"...
