How windows authentication works with IIS (Http.sys, Kerberos, NTLM)?

IIS sits on top of HTTP.sys, which is the kernel mode driver in the Windows network stack that receives HTTP requests. IIS picks up requests from http.sys, processes them, and calls http.sys to send the response.

IIS introduced Kernel Mode authentication for Windows Auth (Kerberos & NTLM), and it’s enabled by default on all versions. This feature offloads the NTLM and Kerberos authentication work to http.sys. Http.sys, before the request gets sent to IIS, works with the Local Security Authority (LSA, lsass.exe) to authenticate the end user. IIS just receives the result of the auth attempt, and takes appropriate action based on that result.

Let’s look at how Kerberos authentication works with IIS.

Kerberos authentication is currently the default authorization technology used by Microsoft Windows.  Before Kerberos, Microsoft used an authentication technology called NTLM.  NTLM simply an older technology, and you shouldn’t rely upon NTLM to protect sensitive data.

First request is always anonymous.  Client sends below request to server.  I have excluded some of the http header info from request.

Request 1

GET / HTTP/1.1

The default settings for Windows Authentication in IIS include both the “Negotiate” and “NTLM” providers.  Server sends HTTP 401 response with two  “WWW-Authenticate” headers one for “Negotiate” and antoher is “NTLM”.  Clients generally choose the one listed first, which is “Negotiate” in a default setup.  This tells the client how the server expects a user to be authenticated.  Below is the response sent by Server.

Response 1

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET

 

If client does not have cached Kerberos token, it will reach out to Active Directory to get one.   Client and Domain Controller(Authentication Service(AS) and Ticket Granting Service(TGS)) talks to each other to get Kerberos token.  Once client gets it, it caches the token for later use.

Client send this HTTP request back to server with Kerberos token.  Kerberos token starts with YII.

Request 2

GET / HTTP/1.1
Authorization: Negotiate YIIg8gYGKwY[…]hdN7Z6yDNBuU=

Once the server has received the request, http.sys works with Local Security Authority(LSA) to validate that token.  If it is valid, then it sets the user context on the request and IIS gets that request and process the request and deliver it to the client.

Response 2

HTTP/1.1 200 OK
WWW-Authenticate: Negotiate oYG3MIG0oAMKAQChC[…]k+zK
X-Powered-By: ASP.NET

Let’s talk about NTLM authentication now.

Request 1 and Response 1 are same like Kerberos authentication above.  WWW-Authentication header will have value “NTLM”.

Request 1

GET / HTTP/1.1

Response 1

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET

Client sends request to server with authorization header which has user information (NTLM type -1 message).  NTLM token starts with TIRM.

Request 2

GET / HTTP/1.1
Authorization: NTLM TlRMTVN[…]ADw==

Http.sys generates a 16-byte random number (NTLM challenge) and sends it to the client.   makes a call to LSA to retrieve the NTLM challenge based off the user and domain information provided by client.  Once it has been received, http.sys generates below message and send it to client.  Server header value is HTTPAPI which is http.sys, not IIS.

Response 2

HTTP/1.1 401 Unauthorized
Server: Microsoft-HTTPAPI/2.0
WWW-Authenticate: NTLM TlRMTVN[…]AAA

Client encrypts this NTLM challenge with the hash of the user’s password and returns the result to the server.

Request 3

GET / HTTP/1.1
Authorization: NTLM TlRMTVN[… much longer …]AC4A
Host: server

Http.sys sends this information(user info, challenge sent to client, encrypted response received from client) to the domain controller.  The domain controller users the user name to retrieve the hash of the user’s password from the security account manager database.  It uses this password hash to encrypt the challenge and it compares with encrypted challenged sent by server.  If it matches, then authentication successful.  It sets the user context to request and IIS pickes up that request.  IIS processes the request and deliver it to client.

Response 3

HTTP/1.1 200 OK
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET

Hope this helps!

 

Posted in Microsoft Technology Tagged with:

Ads