You can require users to provide a valid Microsoft Windows user-account name and password before they access any information on your server. This identification process is 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 to control access to the content on your server:
For information about setting up authentication, see Enabling and Configuring Authentication.
| Method | Security Level | Sends Passwords How? | Usable Across Proxy Servers and Firewalls? | Client Requirements |
| Anonymous | None | N/A | Yes | Any browser |
| Basic | Low | Base64 encoded clear text | Yes; however, sending passwords across a proxy server or firewall in clear text is a security risk because Base64 encoded clear text is not encryption | Most browsers |
| Digest | Medium | Hashed | Yes | Internet Explorer 5.0 or later |
| Advanced Digest | Medium | Hashed | Yes | Internet Explorer 5.0 or later |
| Integrated Windows | High | Hashed when NTLM is used. Kerberos ticket when Kerberos is used |
No, unless used over a PPTP connection | Internet Explorer 2.0 and later for NTLM, and Windows 2000 or later with Internet Explorer 5.0 or later for Kerberos |
| Certificates | High | N/A | Yes, using an SSL connection | Internet Explorer and Netscape |
| FTP Anonymous | None | N/A | Yes | Any FTP client |
| FTP Basic | Low | Clear text | Yes | Any FTP client |
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 connection to the Windows user account 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 different 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.
The following process explains how IIS uses the IUSR_computername account as follows:
Important If you enable Anonymous authentication, IIS always attempts to authenticate the user with Anonymous authentication first, even if you enable additional authentication methods.
You can change the account that is used for Anonymous authentication from the IIS 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. To allow anonymous logons, you must change IUSR_computername accounts to Log On Locally.
Note You can programmatically 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 Microsoft Management Console (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 When you change the IUSR_computername account, the changes affect every anonymous HTTP request that a Web server services. 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.
Important Base64 encoding is not encryption. If a Base64 encoded password is intercepted over the network by a network sniffer, unauthorized persons can easily decode and reuse the password.
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 can easily intercept and decode these passwords 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 with a dedicated line or a Secure Sockets Layer (SSL) connection. For more information, see Encryption.
Note Integrated Windows authentication takes precedence over Basic authentication. The browser chooses integrated Windows authentication and attempts to use the current Windows logon information before prompting the user for a user name and password. Currently, only Internet Explorer versions 2.0 and later support Integrated Windows authentication.
Installation of additional client software is not required, but Digest authentication does rely on the HTTP 1.1 protocol as defined in the RFC 2617 specification at the World Wide Web Consortium Web site. Because Digest authentication requires HTTP 1.1 compliance, not all browsers support it. If a non-HTTP 1.1 compliant browser requests a file from a server using Digest authentication, the server will request the client for digest credentials. The non-HTTP 1.1. compliant client rejects the request because digest is not supported by the client.
Important Digest authentication completes only if the DC has a clear-text copy of the requesting user's password stored in Active Directory. Because the DC stores clear-text copies of passwords, Active Directory must be secured both from physical and from network attacks.
Installation of additional client software is not required; however, Advanced Digest authentication does rely on the HTTP 1.1 protocol as defined in the RFC 2617 specification at the World Wide Web Consortium Web site. Because Advanced Digest authentication relies on the HTTP 1.1 protocol, not all browsers support it. If a non-HTTP 1.1 compliant browser requests a file from a server using Digest authentication, the server will request the client to provide digest credentials. The non-HTTP 1.1. compliant client rejects the request because digest is not supported by the client.
Important You can enable Advanced Digest authentication only when the DC and IIS server are both running Windows XP. If either your DC or IIS server is running Windows 2000 or earlier, IIS defaults to Digest Authentication and does not warn you of this action.
Note In Step 2, the IIS server reports to the client (Internet Explorer) that Digest authentication is used, rather than Advanced Digest authentication because the same Digest authentication algorithm is used between the IIS server and the client for both Digest and Advanced Digest authentication.
Integrated Windows authentication (formerly called NTLM, also referred to as Windows NT Challenge/Response authentication) is a secure form of authentication because the user name and password are hashed before being 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 uses Kerberos v5 authentication and NTLM authentication. If Active Directory Services is installed on a Windows 2000 or later domain controller and the user's browser supports the Kerberos v5 authentication protocol, Kerberos v5 authentication is used; otherwise, NTLM authentication is used.
The Kerberos v5 authentication protocol is a feature of the Windows 2000 Distributed Services architecture. For Kerberos v5 authentication to be successful, both the client and the server must have a trusted connection to a Key Distribution Center (KDC) and be Directory Services compatible. For more information about Kerberos and NTLM, see the Windows XP online documentation.
Note Internet Explorer versions 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.
Because a Windows user account is required to access resources like files, 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 map either 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 provides 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 you select Anonymous FTP authentication for a resource, all requests for that resource are 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. If Anonymous FTP authentication is enabled, IIS always try to use it first, even if you enable Basic FTP authentication. For more information, see Anonymous Authentication.
To establish an FTP connection with your Web server by using Basic FTP 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 an 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.