Method	Security Level	Server Requirements	Client Requirements	Comments
Anonymous	None	IUSR_computername account	Any browser	Used for public areas of Internet sites.
Basic	Low	Valid accounts	Enter user name and password	Transmits password unencrypted.
Digest	High	Plain text copy of every password. Valid accounts.	Compatibility	Usable across proxy servers and other firewalls.
Integrated Windows	High	Valid accounts	Browser support	Used for private areas of intranets.
Certificates	High	Obtain server certificates. Configure certificate trust lists (CTLs) (for first use only).	Browser support	Widely used for secure transactions over Internet.
FTP Anonymous	None	IUSR_computername account	None	Used for public areas of FTP sites.
FTP Basic	Low	Valid accounts	Enter user name and password	Transmits password unencrypted.

Anonymous Authentication

Anonymous authentication gives users access to the public areas of your Web or FTP site without prompting them for a user name or password. When a user attempts to connect to your public Web or FTP site, your Web server assigns the user to the Windows user account called IUSR_computername, where computername is the name of the server on which IIS is running.

By default, the IUSR_computername account is included in the Windows user group Guests. This group has security restrictions, imposed by NTFS permissions, that designate the level of access and the type of content available to public users.

If you have multiple sites on your server, or if you have areas of your site that require different access privileges, you can create multiple anonymous accounts, one for each Web or FTP site, directory, or file. By giving these accounts differing access permissions, or by assigning these accounts to different Windows user groups, you can grant users anonymous access to different areas of your public Web and FTP content.

IIS uses the IUSR_computername account in the following way:

1. The IUSR_computername account is added to the Guests group on the computer.
2. When a request is received, IIS will impersonate the IUSR_computername account before executing any code or accessing any files. IIS is able to impersonate the IUSR_computername account because the user name and password for this account are known by IIS.
3. Before returning a page to the client, IIS checks NTFS file and directory permissions to see if the IUSR_computername account is allowed access to the file.
4. If access is allowed, authentication completes and the resources are available to the user.
5. If access is not allowed, IIS will attempt to use another authentication method. If none is selected, IIS returns an "HTTP 403 Access Denied" error message to the browser.

Note

• If Anonymous authentication is enabled, IIS will always try to authenticate using it first, even if other methods are enabled.
• In some cases the browser will prompt the user for a user name and password.

You can change the account that is used for Anonymous authentication in the Internet Information Services snap-in, either at the Web server service level, or for individual virtual directories and files. The anonymous account must have the user right to log on locally. If the account does not have the Log On Locally permission, IIS will not be able to service any anonymous requests. The IIS installation specifically grants the Log On Locally permission to the IUSR_computername account. The IUSR_computername accounts on domain controllers are not given to guest accounts by default and must be changed to Log On Locally to allow anonymous logons.

Note   You can change the requirement for Log On Locally rights by using the Active Directory Service Interfaces (ADSI). For information, see the LogonMethod reference in the Active Server Pages Guide.

You can also change the security privileges for the IUSR_computername account in Windows by using the Group Policy Manager snap-in of the MMC. However, if the anonymous user account does not have permission to access a specific file or resource, your Web server will refuse to establish an anonymous connection for that resource. For more information, see Setting Web Server Permissions.

Important   If you change the IUSR_computername account, the changes will affect every anonymous HTTP request that is serviced by a Web server. Use caution if you modify this account.

Basic Authentication

The Basic authentication method is a widely used, industry-standard method for collecting user name and password information. Basic authentication proceeds as follows:

1. The user's Web browser displays a dialog box where users can enter their previously assigned Windows 2000 account user names and passwords.
2. The Web browser then attempts to establish a connection using this information. (The password is Base64 encoded before being sent over the network).
3. If the server rejects the information, the Web browser repeatedly displays the dialog box until the user either enters a valid user name and password or closes the dialog box.
4. When your Web server verifies that the user name and password correspond to a valid Windows user account, a connection established.

The advantage of Basic authentication is that it is part of the HTTP specification, and is supported by most browsers. The disadvantage is that Web browsers using Basic authentication transmit passwords in an unencrypted form. By monitoring communications on your network, someone could easily intercept and decipher these passwords by using publicly available tools. Therefore, Basic authentication is not recommended unless you are confident that the connection between the user and your Web server is secure, such as a direct cable connection or a dedicated line.

Note   Integrated Windows authentication takes precedence over Basic authentication. The browser will choose integrated Windows authentication and will attempt to use the current Windows logon information before prompting the user for a user name and password. Currently, only Internet Explorer, version 2.0 and later, supports integrated Windows authentication.

Digest Authentication

A new feature of IIS 5.0, Digest authentication offers the same features as Basic authentication but involves a different way of transmitting the authentication credentials. The authentication credentials pass through a one-way process, often referred to as hashing. The result of this process is called a hash, or message digest, and it is not feasible to decrypt it. That is, the original text cannot be deciphered from the hash.

Digest authentication proceeds as follows:

1. The server sends the browser certain information which will be used in the authentication process.
2. The browser adds this information to its user name and password plus some other information and performs a hash on it. The additional information will help to prevent someone from copying of the hash value and using it over again.
3. The resulting hash is sent over the network to the server along with the additional information in clear text.
4. The server then adds the additional information to a plain text copy it has of the client's password and hashes all of the information.
5. The server than compares the hash value it received with the one it just made.
6. Access is granted only if the two numbers are absolutely identical.

The additional information is added to the password before hashing so that no one can capture the password hash and use it to impersonate the true client. Values are added that help to identify the client, the client's computer, and the realm, or domain, the client belongs to. As well, a time stamp is added to prevent a client from using a password after it has been revoked.

This a clear advantage over Basic authentication, in which the password can be intercepted and used by an unauthorized person. Digest authentication is structured to be usable across proxy servers and other firewall applications and is available to Web Distributed Authoring and Versioning (WebDAV). Because Digest authentication is a new HTTP 1.1 feature, not all browsers support it. If a non-compliant browser makes a request on a server that requires Digest authentication, the server will reject the request and send the client an error message. Digest authentication is supported only for domains a with Windows 2000 domain controller.

Important   Digest authentication will complete only if the domain server for which a request is made has a plain-text copy of the requesting user's password. Because the domain controller has plain-text copies of passwords, it must be secured from both physical and network attacks. For more information about securing a domain controller, see the Microsoft Windows 2000 Server Resource Kit.

Note   A hash value consists of a small amount of binary data, typically no more than 160 bits. This value is produced by using a hashing algorithm. All hash values share the following properties, regardless of the algorithm used:

• Hash length The length of the hash value is determined by the type of algorithm used, and its length does not vary with the size of the message. The message can be several kilobytes or several gigabytes, it doesn't matter. The most common hash value lengths are either 128 or 160 bits.
• Non-discoverability Every pair of nonidentical messages will translate into a completely different hash value, even if the two messages differ only by a single bit. Using today's technology, it is not feasible to discover a pair of messages that translate to the same hash value.
• Repeatability Each time a particular message is hashed using the same algorithm, the exact same hash value will be produced.
• Irreversibility All hashing algorithms are one-way. Given a hash value, it is impossible to recover the original message, even given the hashing algorithm. In fact, none of the properties of the original message can be determined given the hash value alone.

Integrated Windows Authentication

Integrated Windows authentication (formerly called NTLM or Windows NT Challenge/Response authentication) is a secure form of authentication because the user name and password are not sent across the network. When you enable integrated Windows authentication, the user's browser proves its knowledge of the password through a cryptographic exchange with your Web server, involving hashing.

Integrated Windows authentication can use both the Kerberos v5 authentication protocol and its own challenge/response authentication protocol. If Directory Services is installed on the server, and the browser is compatible with the Kerberos v5 authentication protocol, both the Kerberos v5 protocol and the challenge/response protocol are used; otherwise only the challenge/response protocol is used.

The Kerberos v5 authentication protocol is a feature of the Windows 2000 Distributed Services architecture. In order for Kerberos v5 authentication to be successful, both the client and server must have a trusted connection to a Key Distribution Center (KDC) and be Directory Services compatible. For more information about the protocol, see the Windows documentation.

Integrated Windows authentication proceeds as follows:

1. Unlike Basic authentication, it does not initially prompt users for a user name and password. The current Windows user information on the client computer is used for the integrated Windows authentication.

   Note   Internet Explorer, version 4.0 and later, can be configured to initially prompt for user information if needed. For more information, see the Internet Explorer documentation.

2. However, if the authentication exchange initially fails to identify the user, the browser will prompt the user for a Windows user account user name and password, which it will process by using integrated Windows authentication.
3. Internet Explorer will continue to prompt the user until the user enters a valid user name and password, or closes the prompt dialog box.

Although integrated Windows authentication is secure, it does have two limitations.

1. Only Microsoft Internet Explorer, version 2.0 or later, supports this authentication method.
2. Integrated Windows authentication does not work over HTTP Proxy connections.

Therefore, integrated Windows authentication is best suited for an intranet environment, where both user and Web server computers are in the same domain, and where administrators can ensure that every user has Microsoft Internet Explorer, version 2.0 or later.

Certificate Authentication

You can also use your Web server's Secure Sockets Layer (SSL) security features for two types of authentication. You can use a server certificate to allow users to authenticate your Web site before they transmit personal information, such as a credit card number. Also, you can use client certificates to authenticate users requesting information on your Web site. SSL authenticates by checking the contents of an encrypted digital identification submitted by the user's Web browser during the logon process. (Users obtain client certificates from a mutually trusted third-party organization.) Server certificates usually contain information about your company and the organization that issued the certificate. Client certificates usually contain identifying information about the user and the organization that issued the certificate.

Client Certificate Mapping

You can associate, or map, client certificates to Windows user accounts on your Web server. After you create and enable a certificate map, each time a user logs on with a client certificate, your Web server automatically associates that user to the appropriate Windows user account. This way, you can automatically authenticate users who log on with client certificates, without requiring the use of either Basic, Digest, or integrated Windows authentication. You can either map one client certificate to one Windows user account or many client certificates to one account. For example, if you had several different departments or businesses on your server, each with its own Web site, you could use many-to-one mapping to map all of the client certificates of each department or company to its own Web site. This way each site would provide access only to its own clients.

FTP Authentication

Anonymous FTP Authentication

You can configure your FTP server to allow anonymous access to FTP resources. If Anonymous authentication is enabled, IIS will always try to use it first, even if Basic authentication is enabled. If you select Anonymous authentication for a resource, all requests for that resource will be taken without prompting the user for a user name or password. This is possible because IIS automatically creates a Windows user account called IUSR_computername, where computername is the name of the server on which IIS is running. This is very similar to Web-based anonymous authentication.

Basic FTP Authentication

To establish an FTP connection with your Web server by using Basic authentication, users must log on with a user name and password corresponding to a valid Windows user account. If the FTP server cannot verify a user's identity, the server returns a error message. FTP authentication is not very secure because the user transmits password and user name across the network in an unencrypted form.