I just want to know the difference between NTLM and Kerberos. When to use NTLM and Kerberos and when not to use it? Why do you need to use Kerberos for authenticated feeds? Our admin is asking me why? I just told him because this I need it to be able to access authenticated feeds and I know he's not satisfied with that answer. Can somebody please shed some light on this?


  • Thank you guys for your answers, all are very helpful! Now I need to talk with the admin guys ;) Commented May 29, 2011 at 18:23

5 Answers 5


NTLM does only allow 1-hop solutions because it is transferring user credentials to the first server - in most cases it is IIS on your SharePoint Front End Server. If you want to get some data from a SharePoint server code (WebPart etc) and ask another server for data (it could be external back-end system you want to integrate to), you can't pass user context to that 2nd hop. Impersonation is the option.

Kerberos allow to set up trust between servers so you can pass User context to that back-end server and get security-trimmed (or audience-targeted) data for the User.


One thing is missing in this discussion that is asked in the question; the difference between NTLM and Kerberos.

NTLM is a properitary AuthN protocol invented by Microsoft whereas Kerberos is a standard protocol.

The big difference is how the two protocols handle the authentication: NTLM uses a three-way handshake between the client and server and Kerberos uses a two-way handshake using a ticket granting service (key distribution center). In Kerberos the client must have access to a domain controller (which issues the tickets) whereas in NTLM the client contacts the server which contacts the domain controller.

The performance benefits, that SPDoctor talks about, are mainly due to the minimized amount of AuthN traffic between servers, client and DCs.

Also Kerberos are considered to be more secure than NTLM.

IMHO, it's worth the initial pain with Kerberos but make sure that you plan for it.


For you, the big reason is that it solves the "double hop" (delegation) problem, as mentioned in another answer. In addition, the Kerberos authentication mechanism starts to become more efficient as user session time increases, and reduces the load on the domain controller. This is because Kerberos is using an authentication ticket and not having to go back to AD with each request. This is more of an issue if the DC is remote from the server. Kerberos is also more secure than the older NTLM protocol.

Your admin is probably not "satisfied" with your answer because he has heard that setting up Kerberos is difficult and doesn't know where to start. It really is not that difficult, although not trivial. The main task is setting up the Service Principal Names in Active Directory, and it has to be done right. Admins often get this wrong and then everyone gets frustrated and this spreads the notion that setting up Kerberos is a pain, which it can be if you don't know what you are doing. Plus you get that scary warning dialog when you try to enable it in Central Administration.

Make sure you read the technet article and double check when your admin sets the SPNs.

  • 1
    as i understand it this could also be considered a con for low traffic solutions since the ticket is larger in size? So it takes a certain load to take advantage of using Kerb. Another point regarding setup: its a common misconception that you have to "convert to" Kerberos on your entire network, where in fact you can run Kerberos on your SharePoint farm only. Also a good point that you need to train IT to understand Kerberos. Commented May 26, 2011 at 10:14
  • 1
    It can be slower if your user sessions are brief (a few minutes), but the difference is small either way. I wouldn't avoid Kerberos because of this, or choose it just to get performance (the exception is the slow connection to DC situation where NTLM auth can kill you if you have a lot of traffic).
    – SPDoctor
    Commented May 26, 2011 at 10:23

Here's an example of when you need it and when you don't

  1. User >> SharePoint web page with SSRS report viewer via iFrame. NTLM lets user onto the page. User goes direct to SSRS via the iFrame and uses NTLM to authenticate there. Kerberos not required.
  2. User >> SharePoint web page with SSRS report viewer in Integrated Mode. User goes to SharePoint and SharePoint goes to SSRS directly (i.e. no iFrame). For the User to delegate authority to use SharePoint, you need Kerberos. Without it it's like SharePoint saying "trust me, I'm representing Ted, really, I promise". Kerberos is like having a signed, notarized permission from the user to authenticate to an external system.

Here's a few of my top Kerberos bookmarks. The bottom one links to my list on Delicious

  • 1
    I think your 3rd link is to all Delicious posts, not just yours. Commented Mar 5, 2013 at 5:40

Everything here is correct thus far, but generally which one to use? When I'm setting up SharePoint, Single-Server setups are typically NTLM, Multi-Server setups are typically Kerberos. Usually Multi-Server setups one day will involve third party tools, etc. that wish to setup authentication integrated somewhat with SharePoint and being cognizant of that, I typically start at Kerberos from Day one. Also if I hear mention of any third party tools, that will usually push me into a Kerberos setup.

It's not that hard really...just need to practice SPN Setup and Delegation enough.

EDIT: Now another factor at play is typically whether or not the site is external facing and I can fully trust the users. NTLM now has vulnerabilities that can allow others to spoof a login. While Kerberos remains mostly unscsathed. So if I mostly trust the users (aka Intranet with a close group) I may still consider NTLM. If the users are only partially trusted or the site is external facing, it's now Kerberos.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.