Demistifying Double Hop Issue in SharePoint
You might have experienced the showstopper “Login Failed for user NT AUTHORITY\ANONYMOUS LOGON” message at least once in maintaining or supporting your SharePoint environments. Both are likely caused by what is known as the “double-hop” issue.
From Microsoft’s KB article, the double-hop issue is when the ASPX page tries to use resources that are located on a server that is different from the IIS server.
SharePoint supports different authentication protocols, NTLM and Kerberos. NTLM is the default authentication method for IIS and SharePoint. Kerberos, on the other hand, works with ‘tickets’ in allowing nodes over a network to prove their identity in a secure way. NTLM can’t support delegation. It has a double-hop limitation where an account cannot be impersonated to access resources on behalf of the user. Kerberos addresses this limitation but is a little harder to setup.
Given a simple scenario below:
1. User logs into SharePoint site.
2. User requests data from SharePoint application.
3. Reporting Services application makes a query on the SQL Server database on another server. SQL Server returns data the user has access to.
If everything is setup correctly, then there shouldn’t be any problem as long as the user has access to what is being requested. If you receive the dreaded “Login Failed for user NT AUTHORITY\ANONYMOUS LOGON” error, then you are experiencing the “double-hop issue”. Even though the user is authorized to access the resources on the endpoint, the request is passed to the target with anonymous credentials and thus fails. The credentials cannot be passed correctly to the SQL server.
It can be difficult to identify and troubleshoot these kinds of error so it pays to understand how your environment was setup in trying to diagnose this problem. If the problem is a consistent one and can be replicated every time, it almost always is a Kerberos configuration issue. We came up with the following checklist that admins can go through in these cases.
Configuration of environment, app pools, service accounts, etc.
Go through what has been setup in your environment. What application pools are defined? What are the service accounts used for the IIS application pool, Reporting Services Service, SQL Service? It helps to write these down as this is where you can refer back to setting up the SPNs and delegation.
Service Principal Names (SPNs) in Active Directory
I believe that this is the most critical part in Kerberos configuration. From a Microsoft KB article, Service Principal Name (SPN) is a unique identifier of a service instance. It is used by Kerberos to authenticate a service. In a sense, SPN associates a service instance with a service logon account. Make sure that application services have SPNs properly defined.
Delegation configuration for the service accounts
Forwarding of credentials to another service, in our example from SharePoint to Reporting Services, and from Reporting Services to SQL Server is made possible through delegation. Delegation settings can be set to Full Trust or Constrained Delegation.
Full Trust denotes that credentials can be forwarded to any service.
More secure is the Constrained Delegation where you can define only specific services where you can delegate to.
If all of the above checks out, you can also use some network tracing tools like Fiddler to further investigate. Troubleshooting this issue can be a real pain and it helps to have some sort of a checklist like this, that can guide you through, in making sure everything is correctly setup.
Application Pools, Service Accounts, etc.
Take note of what have been defined on the application pools and what accounts are used as service accounts for configuration of SPNs and Delegation settings later on.
Service Principal Names
SPNs must be correctly defined since this is used by Kerberos for the authentication.
Delegation Settings
Takes care of forwarding the credentials to another service and can either be Full Trust or Constrained Delegation.