Lesson 1: Designing an Authentication Strategy

Windows 2000 supports authenticated logon, which means that when users try to access a Windows 2000 network, they must provide credentials for authentication. These credentials usually take the form of a username and password; however, Windows 2000 can also authenticate credentials that take the form of certificates. IIS supports five authentication models: Anonymous access, Basic authentication, Integrated Windows authentication, Digest authentication, and client certificate mapping. One of these methods must be used to authenticate users before they can gain access to resources in IIS. This lesson describes each of these authentication models and provides information on how to choose an authentication model for your Web site.

After this lesson, you will be able to

• Describe the Web authentication models supported by IIS
• Determine which authentication model to use for your Web site

Estimated lesson time: 30 minutes

IIS Authentication Models

In Windows 2000, authentication refers to the process of verifying the identity of entities that communicate over a network. Authentication allows initial access to the operating system. For example, suppose a user is trying to log on to a computer by providing a username and password. Windows 2000 compares that username and password to an authorized list. If the credentials are valid, the user is allowed to log on to the system and can then access resources controlled by the system.

Once a user is authenticated, Windows 2000 attaches a security token to all processes (applications) that the user runs. The token identifies the user and the Windows groups to which the user belongs. If a user tries to access an object in the network, such as a file, Windows 2000 compares the user information in the token to the information in the object’s access control list (ACL), which is a list of security protections that apply to the object. The ACL determines who can gain access to a resource in a Windows 2000 environment.

Before a user can access resources in IIS, that user must be authenticated. If the Web site is set up for Anonymous access, the IUSR_computername account is used, and users are not prompted for credentials. If the Web site is set up for nonanonymous authentication, they are prompted for credentials. The authentication process includes a number of steps:

• The Web browser requests the page.
• The Web server performs an authentication check. If the authentication check fails, the server sends an error message to the browser, along with information that the browser needs to resubmit the request as an authenticated request.
• The Web browser uses the server’s response to construct a new request that contains authentication information.
• The Web server performs an authentication check. If the check is successful, the server sends the requested page back to the browser.

Each Hypertext Transfer Protocol (HTTP) request from a browser runs within the security context of the user account. The operations that are performed when the HTTP request is executed are limited by the capabilities granted to that account.

IIS supports five authentication models: Anonymous, Basic, Integrated Windows, Digest, and client certificate mapping. This rest of this section discusses each of these models.

Anonymous Access

Windows 2000 allows only valid users to log on to its system. However, the Internet, for the most part, is a very anonymous environment, and relatively few Web sites prompt visitors for a username and password. To work around this situation, IIS provides the IUSR_computername account so that a real Windows account can be used when you want to provide anonymous users access to your resources. The account gives anonymous users the right to log on locally. Windows 2000 uses the IUSR_computername account when anonymous users are authenticated with Anonymous access.

Figure 10.1 illustrates the authentication process that occurs when an anonymous user requests a page from a site that’s set up with Anonymous access. From the user’s perspective, the request is a straightforward process and the page is returned without the user being prompted for a username and password.

Figure 10.1 - Anonymous access to the DEFAULT.HTM file

When IIS is configured for Anonymous access, a password must be created for the IUSR_computername account. This password must be the same in IIS and in Windows 2000. By default, the password is synchronized automatically. (The Allow IIS To Control Password check box in the Internet Services Manager tool is selected.) When this option is enabled, IIS uses a subauthenticator to inform Windows that the password is correct. Although this makes administration easier, it can present problems when a user is trying to access some network resources, such as a Microsoft Access database.

In these cases, you must disable automatic synchronization (by deselecting the check box). Authentication is then performed differently from when it is enabled. Rather than using a subauthenticator, IIS calls the LogonUser() application programming interface (API) in Windows to log the account on to the system. As a result, you must then ensure that the username and password are set up correctly in Windows 2000. If the username and password match when IIS passes them to Windows 2000, the account is successfully logged on, the security token is cached by IIS 5.0, and the account is impersonated.

Basic Authentication

Basic authentication is part of the HTTP 1.0 specification and is supported by most Web servers and most Web browsers. Unlike Anonymous access, Basic authentication requires a user to provide credentials in order to log on to the system. Users must have local logon rights to the Web server in order to be authenticated. You can use Basic authentication to track who has access to which resources, based on the user ID, so that you can restrict access to some parts of the Web server. Basic authentication uses NT file system (NTFS) security to restrict access to files on an IIS Web server.

Figure 10.2 illustrates the authentication process that occurs when a user requests a page from a site that’s set up with Basic authentication. After users request the page, they’re prompted for a user name and password.

Figure 10.2 - Basic access to the DEFAULT.HTM file

In Basic authentication, passwords are encoded, but not securely encrypted, so the authentication process isn’t very secure. HTTP authentication headers can be intercepted and password data decoded. However, you can use Basic authentication along with Secure Sockets Layer (SSL) to establish a secure session. SSL is discussed in more detail in Lesson 3, "Designing an Encryption Strategy."

Integrated Windows Authentication

Integrated Windows authentication, which is more secure than Basic authentication, supports NT LAN Manager (NTLM) authentication and Kerberos authentication. In Integrated Windows authentication, the browser first attempts to use the current user’s credentials from a domain logon. If those credentials are rejected, the user is prompted for a username and password. However, Windows 2000 doesn’t send an NTLM or Kerberos challenge. Instead, it sends a Negotiate header that allows the client and server to negotiate an authentication protocol. The client then sends a response to the server.

Integrated Windows authentication is well suited to an intranet environment where all users have Windows domain accounts. However, Integrated Windows authentication has the following limitations:

• It can’t be used through proxy server connections.
• It’s supported only by Microsoft Internet Explorer 2.0 or later.
• It might not always support delegation to other servers, such as a SQL Server computer, depending on whether Kerberos or NTLM is being used, whether a nonauthenticated protocol (such as the Transmission Control Protocol/Internet Protocol [TCP/IP] network library) is used to connect to the remote server, or whether the remote server is part of a cluster.

Digest Authentication

Unlike Basic authentication, Digest authentication encrypts passwords before transmitting them from the client to the server. Authentication credentials pass through a one-way process in which the original text can’t be deciphered. The server adds additional information to the credentials so that no one can intercept the transmission and use it to impersonate the true client. In addition, Digest authentication can be used though proxy server connections. However, Digest authentication is supported only for Windows 2000 domains, and only a few browsers, including Internet Explorer 5.0, support this authentication model.

Client Certificate Mapping

Windows 2000 supports a public key infrastructure (PKI) that provides the framework of services, technology, protocols, and standards necessary to deploy and manage a security system that’s based on public key technology. Public key technology uses public keys and private keys to provide authentication, confidentiality, integrity, and nonrepudiation. Public keys and private keys must be used together to provide these services; by themselves, they can’t prove that the public and private key set belong to the key set owner. The two keys are different, but they complement each other in function.

In public key technology, an intended recipient’s public key is accessible by other people to use to encrypt information that will be sent to the recipient. Once encrypted, the information is sent to the recipient, who then uses the private key to decrypt that information. Figure 10.3 provides an overview of the public key process.

One of the main components of a PKI is the digital certificate. A digital certificate is a set of electronic credentials that are used to certify the online identities of individuals, organizations, and computers. Certificates are issued and certified by Certification Authorities (CAs). Windows 2000 includes a CA service, which is part of Certificate Services, one of the main components of the Windows 2000 PKI.

A CA issues certificates to provide proof for verifying the identity of online entities. The certificate identifies the certificate’s owner and contains the owner’s public key. Certificates, which are available to anyone, are commonly distributed by means of directories, public folders, e-mail, and Web pages. A PKI provides the foundation for managing certificates and private keys throughout the certificate life cycle.

Figure 10.3 - Public key technology used to encrypt information

IIS can use client certificates to authenticate users by mapping certificates to Windows 2000 user accounts. When a user presents a certificate, IIS looks at the mapping to determine which user account should be logged on, as shown in Figure 10.4. Certificate mapping is based on the client ownership of a valid authentication certificate.

Figure 10.4 - Mapping client certificate to user account

When certificate mapping is enabled in IIS, Windows 2000 authenticates users and grants rights and permissions based on the mapped user account. IIS supports two types of certificate mapping: one-to-one and one-to-many.

You can use the Active Directory service to map client certificates in order to control access to network resources for domain users accounts. However, to control access to Web site resources, you should use IIS.

One-to-One Certificate Mapping

In one-to-one mapping, you map a certificate to the corresponding Windows 2000 user account for the owner of that certificate. IIS authenticates the user and grants access to resources based on user account information. To use one-to-one mapping, clients must have Windows 2000 user accounts.

Many-to-One Certificate Mapping

In many-to-one mapping, you map the certificates of many users to a single user account. The user account becomes the security context for all the users. Rights and permissions granted to the users are based on the rights and permissions granted to the user account. You can configure IIS and NTFS access rights to permit access to users with the mapped certificates or refuse access to those users. You can also use separate many-to-one certificate mappings for each group that you want to grant Web site access. In general, it’s easier to administer many-to-one mappings than one-to-one mappings. One-to-one mapping is practical when you’re supporting a relatively small number of clients, but when you must grant Web access to a large number of users, you should use many-to-one.

Making a Decision

IIS supports five authentication models that you can use to authenticate your Web clients. Table 10.1 provides considerations that you should take into account when choosing an authentication model.

Table 10.1 Client Authentication Models

Authentication Model	Description
Anonymous access	Anonymous access allows all Web clients to access a site and works with most browsers. IIS uses the IUSR_computername account to provide anonymous users with the right to log on locally. Anonymous access provides no authentication. If password synchronization is enabled, Anonymous access can’t access remote resources; however, if synchronization is disabled, Anonymous access can access remote resources.
Basic authentication	Basic authentication requires that a user provide credentials in order to log on to the system. Users must have local logon rights to the Web server in order to be authenticated. Most browsers support Basic authentication. In Basic authentication, passwords are encoded, but not securely encrypted, so the authentication process isn’t very secure. However, you can use Basic authentication along with SSL to establish a secure session.
Integrated Windows authentication	Integrated Windows authentication is more secure than Basic authentication, and it supports NTLM authentication and Kerberos authentication. Integrated Windows authentication can’t be used through proxy server connections and has limited browser support.
Digest authentication	Digest authentication encrypts passwords before transmitting them from the client to the server, and it can be used through proxy server connections. However, Digest authentication is supported only for Windows 2000 domains, and only a few browsers, including Internet Explorer 5.0, support this authentication model. Digest authentication requires Active Directory.
Client certificate mapping	You can use certificate mapping in IIS to authenticate users by mapping certificates to Windows 2000 user accounts. When certificate mapping is enabled in IIS, Windows 2000 authenticates users and grants rights and permissions based on the mapped user account. IIS supports two types of certificate mapping: one-to-one and one-to-many. Certificate mapping is very scalable and secure, but not all browsers support it. In addition, certificate mapping can be cumbersome to configure.

Recommendations

You must first decide whether you even need to authenticate users who are accessing your Web site. If authentication isn’t necessary, you can configure Anonymous access. If authentication is necessary, you must choose one of the other authentication models. If you can’t control the type of browsers that your users are using, then you should most likely use Basic authentication. However, because Basic isn’t secure, you should use it in conjunction with SSL, which is discussed in Lesson 3, "Designing an Encryption Strategy." If you can control which browsers your clients are using, you might consider one of the other authentication models, depending on how your network is configured. If you choose certificate mapping, then you must decide whether to use a one-to-one or a one-to-many mapping strategy, which will depend on the number of users you’re supporting. You can use one-to-one for a small number of users, but for large numbers you should use many-to-one.

Example: Authentication Strategy for Trey Research

Trey Research maintains a Web site that provides services to its online clients. The site includes two components: one public and one private. Any Internet user can access the public component of the site; however, only a specific group of users can access the private one. Each of the users in this group must supply a username and password to access the private Web pages. Users accessing both public and private Web pages use a variety of browsers on their client computers.

The public component of the site uses Anonymous access to allow users to visit the public Web pages. The IUSR_computername account is configured to automatically synchronize the account’s password. The private component uses Basic authentication with SSL to protect the content of this portion of the site.

Figure 10.5 provides an overview of the two authentication models used to support Trey Research clients.

Figure 10.5 - Anonymous access and Basic authentication

Lesson Summary

Before a user can access resources in IIS, that user must be authenticated. IIS supports five authentication models: Anonymous, Basic, Integrated Windows, Digest, and client certificate mapping. Anonymous access allows users to log on locally to the Web server. From the user’s perspective, site access is a straightforward process, and the user isn’t prompted for a username and password. Basic authentication requires that a user provide credentials in order to log on to the system. Users must have local logon rights to the Web server in order to be authenticated. Integrated Windows authentication supports NTLM authentication and Kerberos authentication. However, Integrated Windows authentication can’t be used through proxy servers, has limited browser support, and doesn’t always support delegation to others servers. Digest authentication encrypts passwords before transmitting them from the client to the server. However, Digest authentication is supported only for Windows 2000 domains, and only a few browsers, including Internet Explorer 5.0, support this authentication model. IIS can use client certificates to authenticate users by mapping certificates to Windows 2000 user accounts. IIS supports two types of certificate mapping: one-to-one and one-to-many.