IIS and Windows Authentication - When does it use NTLM?

Question

I have a gap in my understanding of Windows Authentication in IIS 10 while I was configuring kerberos delegation.

For a client accessing the web server (IIS, with windows authentication enabled) and no delegation scenario or custom SPNs to worry about, this is how I interpret the kerberos authentication:

1. The client requests a TGT (and a session key) from the KDC.

2. After receiving the TGT, The client uses it to request a service ticket from the TGS for the SPN that matches the hostname of the web server. (HTTP/name.company.com).

3. The client base 64 encodes the service ticket and inserts it as the WWW Authentication Header for requests sent to the web server for authentication. The web server can decrypt it to verify the client's identity.

These server fault posts (MSSQLSvc Service Principal Names, Kerberos, and NTLM) and this one (Why use Kerberos instead of NTLM in IIS?) seem to imply that if the TGS does not find a SPN in step #2, the client will fallback to using the NTLM protocol to authenticate to the IIS web server instead of kerberos.

My questions:

1. I seem to be confused whether it is using Kerberos to authenticate or NTLM in this scenario that I described - I have always thought IIS used kerberos for Windows Authentication out of the box.

2. The service ticket from step 2 - I assume the service ticket would still get sent back, albeit it contains no SPNs?

Answer 1

If IIS is configured for Negotiate authentication, it will attempt Kerberos first, providing the client sends a Kerberos token. The response from the IIS server to the initial request (typically 401) will include the header "WWW-Authenticate: Negotiate", aka "send me a Kerberos token".

If Kerberos authentication fails, IIS may be configured to fall back to NTLM, providing the client sends an NTLM token. (The first character of the data is the character "T").

Fallback to NTLM is a mutual concept, and can be enabled, disabled, and configured on both client and server, and applies to most protocols and technologies used when communicating with Windows hosts, such as SMB and RPC.

The semantics for negotiation can be subtle and implementation dependent. Kestrel, for example, prefixes the decoded WWW-Authenticate header response payload with NTLM or HTTP, which means Kerberos.

Note that the fallback only works for accessing resources that are local to the IIS server. For applications that impersonate the user to access other resources like a database or web service, Kerberos must be used. That is usually the more common scenario, the IIS server is only an app server that front ends requests to access another remote resource.

"Failure" in this context doesn't necessarily mean any failure. A specific failure may have a specific exception handler. A typical "failure" that this feature is intended to address is the token size limitation. A Windows Active Directory user may be a member of many groups, which are included in the Privileged Attribute Certificate (PAC) of the token on Windows Kerberos implementations, which is inserted as the WWW-Authenticate header of the response. If it is larger than what IIS allows, it will fail. NTLM tokens are much smaller, typically less than 1kb, and NTLM will work.

Probably the best way to work through this would be to use Fiddler/Wireshark and inspect the packet headers.

https://www.crowdstrike.com/cybersecurity-101/ntlm-windows-new-technology-lan-manager/

https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/windowsauthentication/providers/

https://specopssoft.com/blog/configuring-chrome-and-firefox-for-windows-integrated-authentication/

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/security/authentication/windowsauth.md

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization

https://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header