Share via

IIS Authentication Methods

  • Article

Commerce Server supports the following four authentication methods provided by Internet Information Services (IIS) 5.0:

Anonymous Authentication

Basic Authentication

Integrated Windows Authentication

Certificate Authentication

Anonymous Authentication

Anonymous authentication gives users access to the public areas of your Web site without prompting them for a user name or password. When a user attempts to connect to your public Web 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.

Ee825205.note(en-US,CS.10).gif Notes

  • 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 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 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. By default, the IUSR_<computername> accounts on domain controllers are not given to guest accounts; they must be changed to Log On Locally to allow anonymous logons.

Ee825205.note(en-US,CS.10).gif Note

  • You can change the requirement for Log On Locally permissions by using the Active Directory Service Interfaces (ADSI). For information, see the "LogonMethod" reference in the Active Server Pages Guide of the IIS 5.0 Documentation.

You can also change the security privileges for the IUSR_<computername> account in Windows by using the Group Policy Manager snap-in in 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" in the IIS 5.0 Documentation.

Ee825205.important(en-US,CS.10).gif 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 Web browser on the client computer 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.

For information about setting up Basic authentication, see "Enabling and Configuring Authentication" in the IIS 5.0 Online Documentation.

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.

Ee825205.note(en-US,CS.10).gif 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.

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 browser of the user proves its knowledge of the password through a cryptographic exchange with your Web server, involving hashing. (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.)

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 2000 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.

Ee825205.note(en-US,CS.10).gif 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.

  1. 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.

  2. 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 three 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.

  3. Additional TCP ports have to be opened in the firewall.

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 the Secure Sockets Layer (SSL) security features of your Web server  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 Web browser for the user 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, Messaging 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" in the IIS 5.0 online documentation.


All rights reserved.