So, your network admin just dropped the news: “We need to switch SQL Server authentication from NTLM to Kerberos.”
Maybe you nodded along like you totally understood what that meant. Or maybe, like any good DBA, you immediately thought, Oh great, another thing that might break at 2 AM.
Either way, let’s cut through the noise and break this down into what actually matters for a SQL Server DBA like you and me.
What is NTLM? (a.k.a. “The Old Way”)
NTLM (New Technology LAN Manager) is like the fax machine of authentication. It still works, but it’s clunky, insecure, and hasn’t been the preferred method for a long time.
Here’s how NTLM works:
- You try to connect to SQL Server.
- The server throws a challenge your way.
- Your machine hashes your password and responds.
- SQL Server checks that hash with the domain controller.
That’s it. Simple, right?
The Big NTLM Problems:
🚨 No Delegation → If you need to pass authentication beyond the initial server (like in Linked Servers or SSRS), NTLM says, nope, not happening.
🚨 No Mutual Authentication → You’re proving who you are to the server, but the server isn’t proving who it is to you.
🚨 Easier to Hack → NTLM uses password hashes that attackers can steal and replay later. Yikes.
🚨 It Authenticates Every. Single. Time. → No session management means every request has to go through the same handshake process.
Bottom line? It works—but it’s outdated, insecure, and a pain for anything beyond a simple, single-hop connection.
What is Kerberos? (a.k.a. “The Modern, Secure Way”)
If NTLM is a fax machine, then Kerberos is a password manager with multi-factor authentication.
Kerberos is a ticket-based system where:
- You authenticate once with Active Directory and get a Ticket Granting Ticket (TGT).
- When you need access to SQL Server, you don’t send your password—you send a Service Ticket.
- SQL Server sees that ticket and grants you access—no extra password challenge needed.
Why This is a Big Deal for SQL Server:
✅ Supports Delegation → Need to pass credentials to a Linked Server? Run SSRS reports that hit SQL? No problem.
✅ Mutual Authentication → SQL Server knows who you are, and you know it’s the real SQL Server, not an imposter.
✅ More Secure → Instead of sending hashed passwords over the network, it uses encrypted tickets.
✅ Faster → You authenticate once, and that ticket works for multiple requests. No unnecessary back-and-forth with Active Directory.
So why aren’t we already using it everywhere?
Because Kerberos setup can be a nightmare if you don’t configure it right.
NTLM vs. Kerberos – The DBA Cheat Sheet
| Feature | NTLM (“Old & Busted”) | Kerberos (“New Hotness”) |
|---|---|---|
| Authentication Type | Challenge-response (slow) | Ticket-based (fast) |
| Mutual Authentication? | ❌ No | ✅ Yes |
| Delegation (Multi-Hop Authentication)? | ❌ No | ✅ Yes (critical for Linked Servers, SSRS, etc.) |
| Security Level | 🚨 Weak (susceptible to replay attacks) | 🔒 Strong (encrypted tickets) |
| Performance | 🐌 Slower (authenticates every time) | ⚡ Faster (session-based) |
| Active Directory Required? | ❌ No | ✅ Yes |
| SQL Server Feature Support | ❌ Limited (doesn’t work with Linked Servers, SSRS, etc.) | ✅ Required for Linked Servers, SSRS, AlwaysOn AG |
If you’re doing basic authentication from a user’s machine straight to SQL Server, NTLM might still work.
But the second you throw in:
🔹 Linked Servers
🔹 SQL Server Reporting Services (SSRS)
🔹 Always On Availability Groups
🔹 Accessing network file shares from SQL Server
…you’re going to need Kerberos.
How to Make Sure SQL Server is Using Kerberos
If your network admin is switching over, you’ll want to verify that SQL Server is actually using Kerberos. Run this query:
SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;- If it returns “KERBEROS” → 🎉 Congrats, you’re using the better authentication method.
- If it returns “NTLM” → 😬 You’re still on the insecure, slow path.
Join me next time for a journey through getting Kerberos setup for SQL Server….
Justin Onstot 