From a Windows perspective only:
NTLM
works avec both external (non-domain) et internal clients
works avec les deux domain accounts et local user accounts on le IIS box
using domain accounts, only le server requires direct connectivity to a domain controller (DC)
using local accounts, you ne need connectivity anywhere 🙂
you ne need to be logged on as le user in question to use a credential
Aside: c'est pas that uncommon for a DC to be overwhelmed by a busy NTLM server (IIS, Exchange, TMG/ISA, etc) avec le volume of NTLM requests (to mitigate: P0, P1 (false), faster DCs.) (Self-referential bonus.)
requires client connectivity only to le IIS server (on le site port, nothing else. i.e. Everything happens over HTTP (or HTTPS).)
can traverse tout proxy supporting HTTP Keep-Alives
you may be able to use TLS/SSL to work around others
requires multiple round-trips to authenticate, avec small packets
(log pattern is 401.2, 401.1, 200 avec username)
cannot be used in scenarios où double-hop authentication is required
i.e. le user's credentials are to be forwarded to a service on another computer
supports older clients (< Win2000)
Is susceptible to LM Auth Level discrepancies (mismatched P2)
is used as a fallback by le Negotiate package si Kerb fails.
(not "if access is denied avec Kerb", Kerb must break for NTLM to be used - usually this looks like pas getting a ticket. If le client gets a ticket et c'est pas perfect, that ne cause a fallback.)
Kerberos
-
works avec currently domain-joined clients only
- requires client connectivity to an AD DC (tcp/udp 88) AND le server (tickets are retrieved by le client depuis le DC via le Kerb port, et alors provided to le server using HTTP)
-
might be able to traverse a proxy, mais see DC point above: you encore need to be on le même network as an active DC, as does le server.
so in theory si you had a domain in qui internet-connected clients chatted directly to an internet-connected DC, c'est workable. But ne do that sauf si you déjà knew that.
In reverse proxy scenarios (ISA/TMG), le protocol transition server needs to be on that network, i.e. pas le client... mais alors le client n'est pas really le one doing le Kerberos bit (necessarily - think Forms auth to Kerb transition).
-
ticket is long-lived (10h) meaning less DC communication pendant ticket lifetime - et to emphasise: this could save thousands to millions of requests per client over that lifetime - (P3 is encore a thing; Kerberos PAC validation used to be a thing)
-
requires a single round-trip to authenticate, mais le authentication payload size is relatively large (commonly 6-16K) (401, {(encoded) token size} 200)
-
**can be used avec ("please toujours use Constrained") delegation to enable double-hop scenarios**, i.e. Windows authentication of le connecting user to le suivant service
actually, N-hop - it stacks like Lego! Ajoutez uns beaucoup de hops as needed...
par exemple, to allow UserA to access IIS, et for IIS to impersonate that même Windows user account quand it accesses a différent SQL Server computer. Ceci est "delegation of authentication".
(Constrained in this context means "but pas anything else", eg Exchange ou another SQL box)
-
is currently le primary security package for Negotiate authentication
- meaning Windows domain members prefer it quand they can get it
-
requires registration of SPNs, qui can be tricky. Rules that help.
-
requires use of a name as le target, pas an IP address
-
reasons Kerb might fail:
using an IP address à la place of a name
no SPN registered
duplicate SPNs registered
SPN registered against wrong account (KRB_ERR_AP_MODIFIED)
no client DNS / DC connectivity
client proxy setting / Local Intranet Zone pas used for target site
While we're at it:
Basic
can multi-hop. But does so by exposing votre username et password directly to le target web app
qui can alors do anything it wants avec them. Anything.
"Oh, did a Domain Admin juste use mon app? And did I juste read leur email? Then redéfinissez leir password? Awww. Pity"
needs transport layer security (i.e. TLS/SSL) for tout form of security.
et then, see previous issue
works avec tout browser
(but see premier issue)
requires a single round-trip to authenticate (401, 200)
can be used in multi-hop scenarios parce que Windows can perform an interactive logon avec basic credentials
May need le P6 to be configured to accomplish this (think le par défaut changed to network cleartext entre 2000 et 2003, mais might be misremembering)
mais again, see premier issue.
Getting le impression that le first issue is really, really important? It is.
To sum up:
Kerb can be tricky to set up, mais there are loads of guides (my one) out there that essayez de simplify le process, et le tools have improved vastly depuis 2003 to 2008 (SetSPN can recherchez duplicates, qui is le le plus common breaking issue; use P8 anytime you see guidance to use -A, et life will be happier).
Constrained delegation is worth le cost of admission.
