This is something that I've never really been able to answer as well as I like: What is the real advantage of using Kerberos authentication in IIS instead of NTLM?
I've seen a lot of people really struggle to get it set up (myself included) and I haven't been able to come up with a good reason for using it. There must be some pretty significant advantages though, otherwise it wouldn't be worth all the trouble to set it up, right?
From a Windows perspective only:
MaxConcurrentAPI, AuthPersistSingleRequest (false), faster DCs.) (Self-referential bonus.)lmcompatibilitylevel)works with currently domain-joined clients only
might be able to traverse a proxy, but see DC point above: you still need to be on the same network as an active DC, as does the server.
ticket is long-lived (10h) meaning less DC communication during ticket lifetime - and to emphasise: this could save thousands to millions of requests per client over that lifetime - (AuthPersistNonNTLM is still a thing; Kerberos PAC validation used to be a thing)
requires a single round-trip to authenticate, but the authentication payload size is relatively large (commonly 6-16K) (401, {(encoded) token size} 200)
can be used with ("please always use Constrained") delegation to enable double-hop scenarios, i.e. Windows authentication of the connecting user to the next service
UserA to access IIS, and for IIS to impersonate that same Windows user account when it accesses a different SQL Server computer. This is "delegation of authentication".is currently the primary security package for Negotiate authentication
requires registration of SPNs, which can be tricky. Rules that help.
requires use of a name as the target, not an IP address
reasons Kerb might fail:
KRB_ERR_AP_MODIFIED)While we're at it:
LogonType to be configured to accomplish this (think the default changed to network cleartext between 2000 and 2003, but might be misremembering)To sum up:
Kerb can be tricky to set up, but there are loads of guides (my one) out there that try to simplify the process, and the tools have improved vastly from 2003 to 2008 (SetSPN can search for duplicates, which is the most common breaking issue; use SETSPN -S anytime you see guidance to use -A, and life will be happier).
Constrained delegation is worth the cost of admission.
From the Microsoft Application Verifier, which detects common developer mistakes. One of those mistakes is the use of NTLM:
NTLM is an outdated authentication protocol with flaws that potentially compromise the security of applications and the operating system. The most important shortcoming is the lack of server authentication, which could allow an attacker to trick users into connecting to a spoofed server. As a corollary of missing server authentication, applications using NTLM can also be vulnerable to a type of attack known as a “reflection” attack. This latter allows an attacker to hijack a user’s authentication conversation to a legitimate server and use it to authenticate the attacker to the user’s computer. NTLM’s vulnerabilities and ways of exploiting them are the target of increasing research activity in the security community.
Although Kerberos has been available for many years many applications are still written to use NTLM only. This needlessly reduces the security of applications. Kerberos cannot however replace NTLM in all scenarios – principally those where a client needs to authenticate to systems that are not joined to a domain (a home network perhaps being the most common of these). The Negotiate security package allows a backwards-compatible compromise that uses Kerberos whenever possible and only reverts to NTLM when there is no other option. Switching code to use Negotiate instead of NTLM will significantly increase the security for our customers while introducing few or no application compatibilities. Negotiate by itself is not a silver bullet – there are cases where an attacker can force downgrade to NTLM but these are significantly more difficult to exploit. However, one immediate improvement is that applications written to use Negotiate correctly are automatically immune to NTLM reflection attacks.
By way of a final word of caution against use of NTLM: in future versions of Windows it will be possible to disable the use of NTLM at the operating system. If applications have a hard dependency on NTLM they will simply fail to authenticate when NTLM is disabled.
Another approach would be to set authentication to negotiate and use both rather than one instead of the other.
You should add a very important point:
Kerberos has been standard and open protocol in Unix over 20 years whereas NTLM is a purely proprietary solution from Microsoft and only known to Microsoft.
Kerberos is required if you need to impersonate the user to access resources that are not on the iis server.
