Internet Explorer with IIS over an Intranet

Now let's switch some details of the previous scenario. We're on a private intranet that is controlled under one Windows NT domain (see the next section coverage of Windows NT security); the IIS 3.0 server is running on a departmental server machine. We're accessing the IIS server from a Windows 95 client logged on as an Accounting department user, and running Internet Explorer 3.01.

Picking up from Step 4 above, we now have a greatly improved situation:

1. The server sends an access denied HTTP response packet back to the client, but in the header indicates the authentication schemes that the server will support, in the order of preference. At the top of the list is NTLM challenge/response authentication (see next section for details).
   
   
2. IE 3.01 receives the 'access denied' packet, and looks into the header to find the authentication schemes supported by the server and matches it against what it would support. It likes the NTLM challenge/response authentication because it supports it.
   
   
3. IE 3.01 will actually initiate the challenge/response authentication process by informing the NTLMSP. The user will not be asked for the user ID and password, because IE 3.01 can cause it to be passed to NTLMSP (the user ID and password is cached by the system as long as the user remains logged on).
   
   
4. NTLM-based challenge/response authentication takes place over the network across the two nodes using a proprietary (non-HTTP) protocol. See the next section for details of how NTLM challenge/response works.
   
   
5. The challenge/response sequence terminates with the server impersonating the client if authentication is successful, and retries the access to the protected resource on behalf of the remote user.
   
   
6. The server sends the contents of the requested resource back to the browser which promptly displays it.

Note the great improvement of this scenario over the previous one:

• The password of the user is never transmitted over the network; there's no risk of password capture.
  
  
• The user is never prompted for user ID and password. To the user, the protected web pages were accessible just like unprotected pages.

This improvement certainly makes intranet surfing (and intranet resource access control) much simpler to manage. However, there's one potential drawback: everything is from Microsoft, from the desktop OS to the network OS, from the desktop browser to the web server.