IIS 4.0 and 5.0 Authentication Methods Chart

By Jim Morey, Web Technology Writer

Internet Information Services Documentation Team
Microsoft Corporation

July 19, 1999

Using this chart

This chart is intended to augment the IIS online product documentation and act as a quick-reference for the authentication methods offered in IIS. With the Internet Service Manager (ISM), some basic knowledge of IIS, and this chart, you can configure these authentication methods in IIS. This chart includes information applicable to both IIS 4.0 and IIS 5.0. For more in-depth information about these methods, or IIS security in general, see the IIS online product documentation (installed by default with IIS).

Anonymous
Basic
Basic/SSL
Challenge/Response
Client Certificates
Digest Authentication
Fortezza
General Notes

Anonymous

Applies to IIS 4.0 and 5.0

Feature name changes in IIS 5.0

Description

ALL users are granted access to the specified resources. No user name and password dialog box pops up in the browser and no user information needs to be entered. Anonymous "impersonates" users and acts on their behalf by using the Windows NT® user account IUSR_computername.

 

Requirements

Client: None. Works for all browsers.
Server: A valid Windows NT user account with Log On Locally rights and belonging to the Everyone user group. The IUSR_computername account is installed by default by IIS for this purpose.

 

Typical Uses

Public information on Internet sites.

 

How To Set Up

1. Select the Anonymous access check box in ISM.
2. Click the Edit button to make sure the IUSR_computername account is being used.
3. Synchronize passwords using Enable Automatic Password Synchronization (Allow IIS to control password in IIS 5.0).

 

Notes

Security: All users gaining access to your server and the resources you specify have the user rights and access permissions given to the IUSR_computername account; do not give this account high-level access.
Firewalls: This method is not affected by the use of proxy servers or other firewalls.

 

Basic

Applies to IIS 4.0 and 5.0

Description

Only users that enter user information matching a valid Windows NT user account will be given access. A dialog box pops up in the browser for the user to enter a user name and password. This information is sent in clear text (unencrypted) to the server.

Requirements

Client: Most browsers support this method.
Server: Valid Windows NT user accounts with the Log On Locally rights and other appropriate user rights for the specified resources. These accounts are NOT installed by IIS.

Typical Uses

Non-secure or semi-secure information on Internet and intranet sites. Membership authentication for membership sites.

How To Set Up

1. Create a valid account and give it Log On Locally rights. (This account is NOT created by IIS.)
2. Select the Basic Authentication check box in ISM.
3. To change the default logon domain, click the Edit button.

Notes

User experience: A dialog box pops up in the browser asking for user information. If the information is not entered correctly or does not correspond to a valid user account on the server, the dialog box will continue to pop up until either valid information is entered or the dialog box is closed manually.
When active: This authentication method will only become active if neither Anonymous authentication or Windows Challenge/Response (Integrated Windows Authentication in IIS 5.0) are not enabled or fail.
Security: The user information is sent to the server in clear text (unencrypted) and can be easily intercepted. This exposes Windows NT user account passwords to unauthorized users and can compromise the security of your Web site and server. To use Basic authentication more securely, use it in conjunction with SSL encryption. This will encrypt the user information being sent to the server. See Basic / SSL.
Default domain: You can tell IIS to assume the logon domain rather than have users enter it every time they log on. By default the logon domain is the server's name. If you need the name to be different than the server's name, you can change it using the Edit button. A trust relationship must exist between the user's domain and the server's domain.
Firewalls: This method is not affected by the use of proxy servers or other firewalls.

Basic / SSL

Applies to IIS 4.0 and 5.0

SSL function improvements in IIS 5.0

Description

Same as Basic authentication, except user information is sent over the network with SSL encryption so that user passwords are not compromised.

 

Requirements

Client: SSL 2.0 and 3.0-compliant browsers only.
Server: A valid Windows NT user account, with Log On Locally rights. This account is NOT installed by IIS. A server certificate (necessary for SSL encryption).

 

Typical Uses

Secure or semi-secure information on Internet sites and intranet sites. Membership authentication for membership sites.

 

How To Set Up

1. Install your server certificate.
2. Create a valid account and give it Log On Locally rights (NOT created by IIS by default).
3. Select the Web site, virtual directory, or file and select the Basic Authentication check box in ISM.
4. If you wish to allow either unencrypted (non-secure) and secure Basic authentication, instruct the secure authentication users to use the HTTPS URL format and the non-secure user to use the normal URL.
5. If you wish to have only secure Basic authentication, select Require Secure Channel when accessing this resource (Require secure channel (SSL) in IIS 5.0) in the ISM. Instruct users to use the HTTPS URL format.

 

Notes

Security: The user information is now sent to the server in encrypted form and cannot be easily intercepted.
When active: This authentication method will only become active if neither Anonymous authentication or Windows Challenge/Response (Integrated Windows Authentication in IIS 5.0) are not enabled or fail.
Performance: Using SSL encryption can cause performance decreases. See Using SSL below.
Firewalls: This method is not affected by the use of proxy servers or other firewalls.

 

Windows Challenge/ Response

Applies to IIS 4.0 and 5.0

Called " Integrated Windows Authentication " in IIS 5.0

Description

Only users with valid Windows NT user accounts are granted access to the specified resources. No user name and password dialog box pops up in the browser and no user information needs to be entered.* User information is not transmitted in clear text over the network, and is not in danger of being compromised.

 

Requirements

Client: Works only in Microsoft Internet Explorer, version 2.0 or later.
Server: A valid Windows NT user account with appropriate user rights and permissions for the specified resources. These accounts are NOT installed by IIS. The Windows NT Challenge/Response (Integrated Windows Authentication in IIS 5.0) check box must be selected.

 

Typical Uses

Secure information on intranet sites. This is due primarily to the proxy server restriction and the need to use Internet Explorer 2.0 or later.

 

How To Set Up

1. Create user accounts and give them appropriate rights (these accounts probably already exist on the server).
2. Select the Web site, virtual directory, or file and select the Windows NT Challenge/Response (Integrated Windows Authentication in IIS 5.0) check box in ISM.

 

Notes

Security: This method uses a hashing technology for a secure exchange with the user's browser in order to establish the user's identity. Information already stored on the user's computer, from a domain logon, is used in the exchange, so the user does not need to enter this information*. If the initial authentication attempt fails, the user will see a dialog box pop up in the browser asking for user information. If this attempt fails, no other attempts will be made and the method will fail.
When active: This authentication method will only become active if Anonymous authentication is not enabled or fails.
Limitations: This method cannot be used across proxy servers or other firewalls, but it can be used within them. The reason for this is that the proxy server or firewall will use its own IP address in the hashing step used by this method. The server will therefore attempt to authenticate the user using incorrect information and the authentication will fail.
Works only in Microsoft Internet Explorer, version 2.0 or later.

 

Client Certificates

Applies to IIS 4.0 and 5.0

Feature name change in IIS 5.0

Description

Client certificates can be used to securely authenticate users and to give them access to resources automatically using client certificate mapping.

 

Requirements

Client: Each client browser must have a copy of the client certificate and its private key. Not all browsers are certificate-compatible.
Server: A server certificate. Enabling and configuring client certificate mapping. A copy of every client certificate used in Basic mapping. The root certificate of every CA issuing client certificates being used.

 

Typical Uses

Secure authentication and access to sensitive information on an individual basis, such as an corporate intranet on which company secrets are held. Secure authentication of users of Internet sites, such as member-only sites. See Basic mapping. DS mapping could also be used for these scenarios on a Windows 2000 domain.
Semi-secure authentication and access to semi-secure data, such as a large corporate intranet where many client certificates would be needed, making mapping management difficult. See Advanced mapping.

 

How To Set Up

1. Each client must obtain a client certificate.
2. The server must have a copy of these client certificates.
3. A server certificate must be installed on the appropriate Web site.
4. To have your server require client certificates, set Require Secure Channel when accessing this resource (Require secure channel (SSL) in IIS 5.0) and Require Client Certificates. This will both require the use of a client certificate and encrypt the data being transferred.
5. To have your server allow client certificates to be used, but not require them, set Accept Client Certificates. It is not necessary to set Require Client Certificates.
6. Instruct clients to use the HTTPS URL format.
To set up client certificate mapping:
1. Obtain copies of the client certificates if using Basic mapping (this is not necessary with Advanced or Directory Service mapping).
2. Enable Client Certificate Mapping on the Secure Communications dialog box.
3. Click Edit.
4. Choose the appropriate method.

 

Notes

There are three possibilities when using client certificates:
1. Do not accept Client Certificates (Ignore client certificates in IIS 5.0) means that if a client certificate is sent by the browser, it will be ignored and the request will be authenticated in another way.
2. Accept Client Certificates means that if a client certificate is sent by the browser, the request will use the client certificate to authenticate. If a client certificate is not sent, the request will be authenticated in another way.
3. Require Client Certificates means that the request will not be accepted, unless a client certificate is sent by the browser and that any data sent will be SSL encrypted.
There are three types of client certificate mapping:
1. Basic (One-to-one in IIS 5.0)—one certificate mapped to one user account; requires a copy of the certificate. Absolutely secure.
2. Advanced (Many-to-one in IIS 5.0)—many certificates mapped to a single account or many accounts; does not require a copy of the certificate. Reasonably secure.
3. Directory Services (DS) (IIS 5.0 only)— Windows 2000 Active Directory features to authenticate users with client certificates.
When active: This authentication method will become active even if Anonymous authentication is enabled, if either Require Client Certificates or Allow Client Certificates is used.

 

Digest

Applies to IIS 5.0 Only

Description

Uses a hashing technology to transmit user information in an undecipherable way. Can be used across proxy servers or firewalls.

Requirements

Client: Works only for Internet Explorer 5 on a Windows 2000 domain.
Server: A Windows 2000 domain controller; otherwise, the feature check box will be grayed out. The server must have a clear text copy of the users' passwords to perform the hashing procedure.

Typical Uses

Very secure authentication on Windows 2000 domains, Internet sites, or extranets.

How To Set Up

See the following Product Support Services article for a step-by-step procedure on how to set up Digest Authentication for IIS 5.0: https://support.microsoft.com/default.aspx?scid=kb;en-us;222028&sd=tech.

Notes

Security: Since the domain controller must have a clear text copy of all user passwords, keep this computer properly secured.
When active: This authentication method will only become active if Anonymous authentication is not enabled or fails.
Firewalls: This method will work across proxy servers and other firewalls, provided that the domain controller on the other side of the firewall is a Windows 2000 computer which meets the requirement mentioned earlier.

Fortezza

Applies to IIS 5.0 Only

Description

Uses a client certificate and private key stored on a smart card.

Requirements

Client: Any Fortezza-compliant computer with a smart card reader.
Server: A Windows 2000 server. Same as with client certificates authentication.

Typical Uses

Very secure authentication on Windows 2000 domains, Internet sites, workstation logons, or extranets. Same as client certificate authentication.

How To Set Up

1. Obtain a non-export copy of Schannel.dll from the Microsoft Web site at https://www.microsoft.com/security/.
2. Install the card reading equipment and its drivers. For information, see the card reader documentation.
3. Install the Cryptographic Service Provider (CSP) provided by the equipment supplier. For information, see the card reader documentation.
4. Run the command–line utility Fortutil.exe.

Notes

Security: Since both the certificate and the private key are kept on the card, if you lose it, you will have to obtained another certificate. The Personal Identification Number (PIN) is required for access; therefore, losing the card is not a security risk (unless you write the PIN on the card).
When active: This authentication method will become active even if Anonymous authentication is enabled, if either Require Client Certificates or Accept Certificates is used.
Firewalls: This method will work across proxy servers and other firewalls, provided that the domain controller on the other side of the firewall is a Windows 2000 server.

General Notes

Certificates

Client: A client certificate is a digital identification for the user, much like a driver license. It is used in authenticating clients.
Server: A server certificate is a digital identification for your server which is used to enable SSL encryption and to authenticate the server. It must be properly installed for SSL or client certificate authentication to work. Server certificates can be obtained from a number of resources, called certification authorities (CAs). In IIS 4.0 the Key Manager utility is used to obtain server certificates; in IIS 5.0 the Certificate Wizard is used.
Root certificates: A root certificate proves the identity of a CA and provides a means of verifying any certificates that the CA creates. Root certificates for most of the major CAs are installed by default by Windows NT, Windows 2000, Internet Explorer, and other browsers.

Certificate Mapping

Client certificates can be mapped to, or associated with, Windows NT user accounts. This allows automatic authentication and access for users with client certificates. There are two methods of mapping certificates in IIS 4.0—Basic and Advanced. In IIS 5.0, a third method is added—Directory Service mapping.
Basic (One-to-one in IIS 5.0) mapping: This associates one particular certificate with one particular Windows NT user account. It requires a copy of the actual certificate to be on the server, and for the user name and password to be entered by the administrator. If the user obtains a new client certificate, even using all of the same information, the mapping will not work with the new certificate. A new mapping for each certificate needs to be made. This mapping method is very secure, since the requesting party needs to have a copy of the client certificate and the private key. Even if a malicious party stole a copy of the client certificate, it would be useless without the private key.
Advanced (Many-to-one in IIS 5.0) mapping: This associates certain information contained in certificates with user accounts by using matching rules. Essentially this means that "certificates that contain this information" are allowed. A copy of a certificates is not required for the mapping. If a user obtains a new certificate it will be accepted as readily as the previous certificate, as long as it conforms to the matching rules. This method is not as secure as Basic mapping because possession of the private key is not required. A malicious party could steal a copy of a client certificate, use it to impersonate the real user, and gain access to resources.
Directory Service (DS) mapping: Directory Service (DS) certificate mapping uses native Windows 2000 Active Directory features to authenticate users with client certificates. You can enable DS mapping only at the Master properties level, and only if you are a member of a Windows 2000 domain. Activating DS mapping will exclude the use of one-to-one and many-to-one mapping for the entire Web service.

Using SSL

Performance: Encryption with SSL requires more server processing resources than clear text transmission. The longer the key length used for encryption, the more server resources are needed. Therefore, transmitting a file using 128-bit SSL encryption will use much more server processing resources than transmitting the same file without encryption.
Server Certificate: SSL encryption requires that a valid server certificate be properly installed on the server.
HTTPS URL Format: The HTTPS URL format ( for example, https://www.microsoft.com) tells IIS to use SSL when transmitting data, including authentication data. When SSL is set up for a Web site, all of the resources on that site can be accessed using the secure format, even if Require Secure Channel when accessing this resource (Require secure channel (SSL) in IIS 5.0) is not used. With Require Secure Channel when accessing this resource, the secure format must be used.
Authentication: If you set Require Secure Channel when accessing this resource on a specific file or files, only those files are encrypted by default. Basic authentication will proceed normally, without SSL encryption for the other files in the virtual directory unless requested using the HTTPS URL format.

IUSR_
computername account

This account is installed by default by IIS and given the correct user rights, permissions, and user group assignment. There is usually no need to change these values or to use another account for Anonymous authentication (unless you have changed the name of the server). However, if you want to do so, remember that ALL of the incoming users will have all of the rights and permissions assigned to the account you use.
Password synchronization: The password used by IIS for Anonymous authentication must match the password for it in Windows NT. If these passwords do not match, Anonymous authentication will not work. To make sure that these passwords are the same, use Enable Automatic Password Synchronization (Allow IIS to control password in IIS 5.0) found by clicking the Edit button.
Server name change: If you change the name of your server, the Windows NT user account IUSR_computername will automatically update upon restart. However, the account used by IIS will still be the old account, which doesn't exist anymore. You need to change the account used by IIS by clicking the Edit button and either typing in the new account name or browsing to it.

Log On Locally

This user right gives the account to which it is assigned the ability to act as if it were physically logging onto the server computer. This right must be assigned for all accounts used in Anonymous and Basic authentication methods. If the right is not assigned, the method will fail and the user will get a 403:Access Denied error message.