How does IIS authenticate browser clients?

  • 7710928
  • 02-Feb-2007
  • 24-Jan-2013

Environment

NetIQ Directory & Resource Administrator 8.x
Microsoft Internet Information Services version 6.0
Microsoft Internet Information Services version 7.0
Microsoft Internet Explorer 6.0
Microsoft Internet Explorer 7.0
Microsoft Internet Explorer 8.0
 
 

Situation

When DRA Admins use the DRA Web Console to connect to DRA, there is an authentication process that must occur. This process occurs between the Web Browser, Web Server and the DRA Service.

Resolution

Authentication Methods Available for Windows 2003 & Windows 2008
Anonymous - No logon is required and anyone is allowed to gain access to data protected with this method. The server uses a built in account (IUSR_[machine name] by default) to control the permissions on the files. The browser does not send any credentials or user info with this type of request.

Browsers Supported: Any

Limitations: None

User Rights Required: The Anonymous user account defined on the server must have "Log On Locally" permissions.

Encryption Type: None

 

Basic (Clear Text) - The server requests the user to log on and a dialog box appears in the browser that allows the user to enter the credentials that are needed. These credentials must match the user credentials defined on the files that the user is attempting to access.

Browsers Supported: Any

Limitations: Not extremely secure. Passwords are easily deciphered.

User Rights Required: The user account must have "Log on Locally" rights

Encryption Type: Base 64 Encoding (not true encryption)
 

Digest - The server requests the user to log on and also sends a NONCE used to encrypt the password. The browser uses the NONCE to encrypt the password and sends this to the server. The server then encrypts its own copy of the user's password and compares the two. If they match and the user has permissions, access is granted.

Browsers Supported: Internet Explorer 5 only

Limitations: Not as secure as Integrated. Requires the server to have access to an Active Directory Server that is set up for Digest Authentication.

User Rights Required: Requires passwords to have "Save password as encrypted Clear Text"

Encryption Type: Based on NONCE sent by server.
 

Windows Integrated (split into two sub categories).

Kerberos - The server requests a user to log on. If the browser supports Kerberos, The following takes place:

  1. IIS requests authentication.
  2. If the client has not logged on to a domain, a dialog box appears in Internet Explorer requesting credentials, and then contacts the KDC to request and receive a Ticket Granting Ticket. It then sends the Ticket Granting Ticket along with information about the IIS server to the KDC.
  3. If the IE Client has already successfully logged into the domain and received a Ticket Granting Ticket, it sends this ticket along with info about the IIS server to the KDC
  4. The KDC issues the client a Resource Ticket.
  5. The Client passes this ticket to the IIS server.

Kerberos uses tickets generated at a Ticket Granting Server (KDC) to authenticate. It sends this ticket to the IIS server. The browser does NOT send the user's password across to the server.

  • Browsers Supported: Internet Explorer versions 5.0 and above
  • Limitations: the server must have access to an Active Directory server. Both the server and the client must have a trusted connection to a KDC.
  • User Rights Required: The Anonymous user account defined on the server must have "Log On Locally" permissions.
  • Encryption type: Encrypted ticket.

Windows NT Challenge/Response - The server requests the user to log on. If the browser supports Windows NT Challenge/Response, it automatically sends the user's credentials if the user is logged on. If the domain that the user is on is different than the server's domain, or if the user is not logged on, a dialog box appears in Internet Explorer requesting the credentials to send. Windows NT Challenge/Response uses an algorithm to generate a hash based on the user's credentials and the computer that the user is using. It then sends this hash to the server. The browser does not send the user's password across to the server.

  • Browsers Supported: Internet Explorer versions 3.01 and later.
  • Limitations: Requires point-to-point connection. Typically, a circuit is closed after a "401 unauthorized " error message; however, when negotiating an Windows NT Challenge/Response authentication sequence (which requires multiple round trips), the server keeps the circuit open for the duration of the sequence after the client has indicated that it will use Windows NT Challenge/Response. CERN proxies and certain other Internet devices prevent this from working. Also, Windows NT Challenge/Response does not support double-hop impersonations (meaning that once passed to the IIS server, the same credentials cannot be passed to a back-end server for authentication, for example, when IIS uses Windows NT Challenge/Response, it cannot then authenticate the user against a SQL Server database on another computer by using SQL Integrated security).

 

  • User Rights Required: The user account accessing the server must have "Access this computer from the network " permissions.
  • Encryption Type: NTLM Hash algorithm that is also uuencoded

Orders of Precedence: When the browser makes a request, it always considers the first request to be Anonymous. Therefore, it does not send any credentials. If the server does not accept Anonymous or if the Anonymous user account set on the server does not have permissions to the file being requested, the IIS server responds with an "Access Denied" error message and sends a list of the authentication types that are supported by using one of the following scenarios:

If Windows Integrated is the only supported method (or if Anonymous fails), then the browser must support this method to communicate with the server. The server tries Kerberos first, and if this fails, then the server falls back to Windows NT Challenge/Response. If this fails, the server doesn’t try any of the other methods.

If Basic is the only supported method (or if Anonymous fails), then a dialog box appears in the browser to get the credentials, and then passes these to the server. It attempts to send the credentials up to three times. If these all fail, the browser does not connect to the server.

If both Basic and Windows Integrated are supported, the browser determines which method is used. If the browser supports Kerberos or Windows NT Challenge/Response, it uses this method. It does not fall back to Basic. If Windows NT Challenge/Response and Kerberos are not supported, the browser uses Basic or Digest; if it supports these. The order of precedence here is Basic, then Digest.

NOTES:

When your browser establishes a connection with a Web site by using Basic or Windows Integrated authentication, it does not fall back to Anonymous during the rest of that session with the server. If you try to connect to a Web page that is marked for Anonymous only after authenticating, you are denied.

When Internet Explorer has established a connection with the server by using an authentication method other than Anonymous, it automatically passes the credentials for every new request during the duration of the session.

 
 

Additional Information

 
For details on how to configure authentication in IIS 7, see the MSDN Link Below:
 
 
Formerly known as NETIQKB10928