Choosing between SharePoint Kerberos vs NTLM is one of the most critical decisions you will make when architecting a SharePoint farm. While both protocols serve to verify user identities, they operate in fundamentally different ways. Understanding these differences is not just a matter of technical curiosity; it is essential for solving common issues like the 'double-hop' problem and ensuring your environment remains secure and performant.

In this guide, you will learn the mechanics behind NTLM and Kerberos, why your administrators might be hesitant to switch, and exactly when you need to leverage the power of Kerberos delegation to keep your data feeds and integrated services running smoothly.

Understanding the Core Differences: NTLM vs. Kerberos

To understand why one protocol might be preferred over the other, you first need to understand how they handle the 'handshake' between the client, the server, and the domain controller.

What is NTLM?

NTLM (NT LAN Manager) is a proprietary authentication protocol developed by Microsoft. It uses a challenge-response mechanism. When you attempt to access a SharePoint site using NTLM, the server sends a challenge to your browser. Your browser responds with a mathematical hash of your password. The SharePoint server then contacts the Domain Controller (DC) to verify that the hash is correct. This is a three-way handshake that occurs frequently, placing a consistent load on your infrastructure.

What is Kerberos?

Kerberos is an industry-standard protocol that relies on 'tickets' rather than password hashes. In a Kerberos environment, your client machine communicates directly with a Key Distribution Center (KDC)—usually your Domain Controller—to obtain a ticket. This ticket is then presented to the SharePoint server. Because the server can verify the ticket's authenticity without reaching back to the DC for every single request, the process is significantly more efficient.

Solving the Infamous Double-Hop Problem

The most compelling reason to choose Kerberos over NTLM in SharePoint is to solve the 'double-hop' problem. This scenario occurs when a user accesses a SharePoint server (the first hop) and that SharePoint server needs to request data from another backend server, such as a SQL Server or an SSRS report server (the second hop), while maintaining the user's identity.

The NTLM Limitation

NTLM only allows for a single hop. When you authenticate to SharePoint via NTLM, the server knows who you are, but it cannot 'pass' your credentials to a second server. If SharePoint tries to fetch data from an external feed or a database on your behalf, the backend server will see the request as coming from the SharePoint service account or an anonymous user, rather than you. This often results in 'Access Denied' errors or data that isn't security-trimmed to your specific permissions.

The Kerberos Solution

Kerberos allows for delegation. Think of Kerberos delegation as a signed, notarized permission slip. It allows the SharePoint server to say to the backend database, 'I am representing this specific user, and here is the cryptographic proof that they have authorized me to act on their behalf.' This allows for seamless, secure integration across multiple servers in a multi-tier architecture.

Performance and Security Considerations

Beyond solving the double-hop issue, Kerberos offers several technical advantages that make it the preferred choice for enterprise-level SharePoint deployments.

1. Efficiency and DC Load

As your user session time increases, Kerberos becomes significantly more efficient. Because it uses tickets with a specific lifespan, the client does not need to re-authenticate with the Domain Controller for every resource request. This reduces the network traffic between your web front ends (WFEs) and your DCs, which is particularly vital if your Domain Controllers are located in a different physical data center.

2. Enhanced Security

NTLM is an aging protocol with known vulnerabilities. It is susceptible to relay attacks and spoofing, where an attacker might intercept a login attempt. Kerberos, by contrast, is much more robust. It provides mutual authentication, meaning not only does the server verify the user, but the user also verifies that they are connecting to the legitimate server. For external-facing sites or environments with sensitive data, Kerberos is the standard for modern security.

Implementation Challenges: The SPN Hurdle

If Kerberos is faster, more secure, and solves the double-hop problem, why doesn't everyone use it by default? The answer usually lies in the complexity of the initial setup.

To enable Kerberos, your IT administrators must configure Service Principal Names (SPNs) in Active Directory. An SPN is a unique identifier that associates a service instance (like your SharePoint web application) with a specific service account in AD. If the SPNs are configured incorrectly—which is a common mistake—authentication will fail entirely, and users will be prompted for credentials repeatedly.

Furthermore, delegation must be explicitly granted in Active Directory. Administrators must trust the SharePoint service account to delegate credentials to specific backend services. Because this requires coordination between SharePoint admins and Domain admins, many organizations stick with NTLM simply because it 'just works' out of the box for single-server setups.

When to Use NTLM vs. Kerberos

Deciding which protocol to use depends largely on your farm topology and your integration requirements.

Use NTLM When:

  • You are running a simple, single-server SharePoint installation.
  • You do not need to pull data from external backend systems using the user's identity.
  • You are in a testing or development environment where security and performance are not primary concerns.
  • You do not have the administrative access or expertise required to manage Active Directory SPNs.

Use Kerberos When:

  • You have a multi-server SharePoint farm (WFEs, App Servers, SQL on separate boxes).
  • You are using integrated services like SQL Server Reporting Services (SSRS) in Integrated Mode.
  • You need to access authenticated external data feeds (e.g., via Business Connectivity Services).
  • Your site is external-facing or holds highly sensitive information.
  • You want to reduce the authentication load on your Domain Controllers.

Frequently Asked Questions

Can I use both NTLM and Kerberos in the same SharePoint farm?

Yes, SharePoint allows you to configure multiple authentication providers. However, typically you configure a web application to use 'Negotiate (Kerberos).' This setting tells the browser to try Kerberos first; if Kerberos fails (for example, if an SPN is missing), it will gracefully fall back to NTLM. This ensures that users can still log in while you troubleshoot your Kerberos configuration.

Why does my SSRS report work in an iFrame but not as a Web Part?

This is a classic example of the double-hop problem. When you use an iFrame, the user's browser connects directly to the SSRS server, creating a direct 'first hop' authentication. When you use a Web Part or Integrated Mode, the SharePoint server must connect to SSRS on your behalf. Without Kerberos delegation, SharePoint cannot prove to SSRS who you are, and the connection fails.

Is Kerberos required for SharePoint Online and Microsoft 365?

No. SharePoint Online uses modern authentication (OAuth 2.0/OpenID Connect) via Azure Active Directory (Entra ID). Kerberos is primarily a concern for on-premises SharePoint Server deployments or hybrid environments where local identities are being used to access local resources.

Wrapping Up

While NTLM is easier to set up, it lacks the scalability and 'delegation' capabilities required for modern, integrated SharePoint environments. Kerberos is the gold standard for performance, security, and multi-tier data integration. By implementing Kerberos and correctly configuring your Service Principal Names, you eliminate the double-hop problem and provide a more secure, efficient experience for your users. If your project involves third-party tools, external feeds, or complex reporting, starting with Kerberos from day one is always the best practice.