You can require users to provide a valid Windows user account user name and password before accessing any information on your server. This identification process is commonly called authentication. Authentication, like many of the features in IIS, can be set at the Web site, directory, or file level. IIS provides the following authentication methods for controlling access to content on your server:
For information about setting up authentication, see Enabling and Configuring Authentication.
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 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:
Note
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.
The Basic authentication method is a widely used, industry-standard method for collecting user name and password information. Basic authentication proceeds as follows:
For information about setting up Basic authentication, see Enabling and Configuring Authentication.
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. For more information, see Encryption.
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.
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:
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:
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:
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.
Although integrated Windows authentication is secure, it does have two limitations.
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.
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. For more information, see About Certificates.
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. For more information, see Mapping Client Certificates to User Accounts.
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. For more information, see Anonymous 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. For more information, see About Access Control.