Authentication is the process of determining the identity of a user. Once a user has been positively identified, Internet Information Server (IIS) can then control what resources that user can access.
IIS provides the following three authentication methods to control access to its resources:
Each of these authentication methods establishes a unique context for the other services and resources that your application might use. With IIS, you can select one or more of these authentication methods. If you select some combination of authentication methods, IIS will first try the anonymous method (if enabled), then the basic method (if enabled), and finally the Windows NT Challenge/Response method (if enabled).
If both the basic and Windows NT Challenge/Response methods are selected, IIS responds to access requests indicating that both methods are permitted. It is then up to the client to determine which authentication schemes it supports and to respond appropriately.
Anonymous access is typical for Web applications that don't expect to know who the user is. Authenticated access (either basic or Windows NT Challenge/Response) usually works best within a company's intranet. For example, your application might be appropriate only for certain users; you know who they are, and you must validate each user's access permissions.
Consider the following: if a user browses your application's Web site, and your Windows NT Server has no idea who this user is, how can IIS safely provide data access to unrecognized users? The answer to this question is the anonymous user logon account.
The anonymous user is a standard logon account that provides guest access to designated files and resources. By default, when a browser requests a Web page, IIS will first try to fill the request without authenticating the user. If Allow Anonymous is enabled, all client requests are processed in the context of the anonymous user logon. If IIS, impersonating the anonymous account, can access the requested page, then the page is served to the anonymous user. For example, if your computer's name is macaw, the anonymous user account is IUSR_macaw. Whatever access permissions are granted to the IUSR_macaw account are similarly granted to every user request.
Anonymous authentication is actually not authentication at all. Anyone who can connect to your Web application can access it to the full extent of the permissions granted to the anonymous account. If your Web application needs to provide the same access to all clients, and you don't care who the clients are, then using anonymous authentication is a good choice.
While the anonymous account at first seems a little insecure, there are multiple barriers preventing someone from taking advantage of anonymous access to get to your application's restricted resources. First, they cannot access files that are invisible to them (such as those protected by NTFS file access restrictions). Secondly, even if they could get to the files, they cannot complete the authentication because they do not have all of the account information necessary to gain access to the files they seek.
The use of the anonymous account does not compromise security and is a good choice for your Web-based applications.
Basic authentication is a standard HTTP authentication mechanism that uses clear text (data that is transmitted as clearly readable text characters) to send and receive user security information.
When enabled, basic authentication is used only under the following conditions:
In basic authentication, the client is responsible for displaying a dialog requesting user name and password information to be passed back to the IIS machine. The credentials are then encoded and sent to the server. The user name entered must specify a user account at the IIS computer or in a trusted domain. When using a trusted domain account, the user name must contain the domain name in the following format: domain\account (for example, macaw\johnq).
Basic authentication offers minimal protection for securing your application's data. Using this type of authentication, user credentials are encoded but not encrypted, and are thus vulnerable to detection by anyone able to sniff network packets.
Unlike basic authentication, which forwards clear-text user names and passwords from client to server, Windows NT Challenge/Response authentication follows a more complex encrypted process that can require multiple communications between the client and server.
Windows NT Challenge/Response authentication only works where the client and server computers are located in the same or trusted domains. Windows NT Challenge/Response works within the Windows NT security model to provide a secure and transparent logon procedure for supported clients. It uses encryption when forwarding secure password information between clients and servers on the network.
Note The Windows NT Challenge/Response requires a live connection between the Web client and the server that requires authentication. This can be a problem if a firewall or proxy server is not configured to handle lost or closed sockets.
In a challenge-and-response sequence, the client machine uses its currently established Windows NT user logon information to identify itself securely to the server. The user is not prompted to enter these user credentials. Instead, the information is available within Windows NT after the user first logs on to a Windows NT server. All communication occurs using multiple secure and encrypted communications between the client and server.
This authentication method is simple to use and very secure because of the process involved in securing users. There are several benefits to this method of authentication, including the following:
Windows NT Challenge/Response provides excellent protection for your Web application. Using this type of authentication with an anonymous logon account is generally the best approach.
For More Information Integrating IIS with Your Network, presented in this section, introduces anonymous logon and IIS.