Microsoft FrontPage 2000 Server Extensions Resource Kit

Security on Windows NT

 ^{2 of 9}     IIS Authentication Methods

All users must be authenticated before they gain access to resources in IIS. IIS supports Anonymous Authentication, Basic Authentication, Windows NT Challenge/Response Authentication, and Digest Access Authentication.

Anonymous Authentication

Anonymous authentication gives access to users who do not have their own accounts on the host machine via a special "anonymous" account. Each Internet service, such as the World Wide Web service or the FTP service, uses a Windows NT account (a user name and password) to process anonymous requests. Internet Information Services creates the anonymous account for Web services, IUSR_machinename, during its setup. By default, all Web client requests use this account, and clients are given access to Web content when they use it. You can enable both anonymous logon access and authenticated access at the same time.

When IIS receives an anonymous request, it impersonates the anonymous logon account. The request succeeds if the anonymous account has permission to access the requested resource; whether the account has permission is determined by the resource's ACL. If the anonymous account does not have permission, the request fails. The WWW service responds to a failed anonymous request by requiring that the user provide a valid Windows NT user name and password.

Basic Authentication

Basic Authentication is a method of authentication that is supported by the majority of Web servers on the Internet. When a server uses Basic Authentication, the Web browser (or the FrontPage client) prompts the user for a name and password. The user name and password are then transmitted across HTTP, in clear text. Using this user name and password, IIS authenticates the corresponding Windows NT user.

In Basic Authentication, the user is always logged on with local logon rights, which is similar to the user's logging on for an interactive session at the computer's console. (To use Basic Authentication, grant each user account the Log On Locally user right on the IIS server.) There are two potential problems caused by Basic Authentication's use of local logon that administrators should be aware of:

• Basic Authentication will not succeed if the user account does not have local logon rights. Even if the FrontPage, IIS, and Windows NT configuration appears to be correct, the lack of local logon rights granted to the user in the Windows NT User Manager will prevent Basic Authentication from authenticating the user.
• With local logon, if a user can obtain physical access to the host computer running IIS, the user will be permitted to start an interactive session at the console.

Another security risk of Basic Authentication is that user names and passwords are transmitted across the network in an easily decoded format.

If your Web site must support authoring by the FrontPage version 1.1 client (which does not support Windows NT Challenge/Response), or if you want to ensure that your Web site is accessible from all browser types, then you must keep Basic Authentication enabled. Furthermore, Basic Authentication works through a firewall via a proxy server. If users connect to your Web server over the Internet via a proxy server, you must use Basic Authentication instead of Windows NT Challenge/Response.

Basic Authentication is faster than Windows NT Challenge/Response. If you use Basic Authentication in combination with Secure Sockets Layer (SSL), you can have secure and fast authentication.

Windows NT Challenge/Response Authentication

Windows NT Challenge/Response (also called NTLM) is a more secure authentication method than Basic Authentication. When a user is authenticated using Windows NT Challenge/Response, the user is logged on to the Web server computer as a network logon. The Web browser or FrontPage client first attempts to use the credentials the user supplied to log on to the client computer. If those credentials are rejected, Windows NT Challenge/Response will prompt the user for a name and password by means of a dialog box. If a user has logged on as a domain user on a local computer, the user won't have to be authenticated again when he or she accesses a remote computer in that domain.

The user name and password are securely encrypted in a multiple transaction interaction between the client and Web server. This interaction is secure against network spies who attempt to break into systems by monitoring network traffic between a client and a server.

There are some limitations of Windows NT Challenge/Response:

• Windows NT Challenge/Response Authentication cannot be performed through a firewall via a proxy. In this scenario, users must use Basic Authentication.
• Some Web browsers (for example, Netscape Navigator) do not support Windows NT Challenge/Response.
• Windows NT Challenge/Response does not support delegation to secondary servers. The user's credentials cannot be passed on to another machine. For example, when a request comes in to IIS, the user account credentials cannot be passed to Microsoft SQL Server on a secondary machine.

Because Windows NT Challenge/Response Authentication cannot be performed through a firewall, it is most useful on intranets, where communication occurs inside an organization's firewall.

You can enable both Basic Authentication and Windows NT Challenge/Response Authentication. If the Web browser supports Windows NT Challenge/Response, it uses that authentication method. Otherwise, it uses Basic Authentication. Windows NT Challenge/Response authentication is currently supported only by Microsoft Internet Explorer 2.0 or later.

Digest Access Authentication

Like Basic Authentication, Digest Access Authentication is based on a simple challenge-response method. The Digest scheme challenges using a nonce value (a server-specified data string which may be uniquely generated each time a 401 error is made.). A valid response contains a checksum of the user name, the password, the given nonce value, the HTTP method, and the requested URL. In this way, the password is never sent as easily decoded text, which is Basic Authentication's biggest weakness.

Digest Access Authentication requires Internet Explorer 5.0 on the client machine.