Exam 70-124: Objective 4.1.5, 4.2: Configuring Web Authentication | MCSE/MCSA Implementing and Administering Security in a Windows 2000 Network: Study Guide and DVD Training System (Exam 70-214)

Web authentication is the process of validating a user's credentials. A user cannot access a Windows 2000 Server unless the user has been authenticated and authorized. Since IIS 5.0 runs on Windows 2000, users also cannot access IIS without being authorized first. IIS supports the following types of authentication:

Anonymous
Basic
Digest
Integrated windows
Client certificate mapping

Using Anonymous Authentication

Anonymous authentication is the most commonly used method on the Internet. It is used for public Web sites that are not concerned with user-level authentication. Using anonymous access, companies do not have to maintain user accounts for everyone who will be accessing their sites. Anonymous access works with browsers other than Internet Explorer.

IIS runs all HTTP and FTP requests in the security context of a Windows 2000 user account. Windows 2000 requires a logon. This means that for someone to log on or access files on a server, they must have a user account. For anonymous Web access to work, a Windows 2000 user account must exist. This account is used anytime someone connects to a server anonymously. IIS 5.0 creates a user account for this purpose when it is installed. The account is named IUSR_computername. Computername is a variable that is replaced with your computer's name. This user account is a member of the Everyone group and the Guest group. It also has permission to log on locally to the Web server.

Using Basic Authentication

Basic authentication is used by almost every Web browser to pass usernames and passwords back to the server. It is widely supported in both Web browsers and Web servers. Basic authentication has several benefits, including:

It works through firewalls and proxy servers.
It is compatible with lower versions of Internet Explorer.
It allows users to access resources that are not located on the IIS server.
It allows the use of NTFS permissions on a user-by-user basis to restrict access. Unlike anonymous access, each user has a unique username and password.

Basic authentication also has some drawbacks such as:

Information is sent over the network as cleartext. The information is encoded with base64 encoding (see RFC 1521 for more information), but is sent in an unencrypted format. Someone could easily use a tool such as Network Monitor to view the information as it travels across the cable, and then use a base64 decoder to read it.
By default, users must have the "Log on Locally" permission to use basic authentication.

For Web requests, basic authentication can be made more secure by using SSL to encrypt the session. SSL is a secure communication protocol invented by Netscape that is used to encrypt communication between two computers. SSL is processor-intensive and degrades the performance of a system. SSL must be used during the entire session because the browser sends the username and password to the server every time the user makes a request. If SSL is being used only for the initial logon, as soon as the user requests a different file, their username and password will be sent over the network as cleartext once again. Only use SSL on Web sites containing sensitive data.

Users authenticating with basic authentication must provide a valid username and password. The user account can be a local account or a domain account. By default, the IIS server looks locally or in its local domain for the user account. If the user account is in another domain, the user must specify the domain name during logon. The syntax for this is domain name\username, where domain name is the name of the user's domain. For example, if someone logs in as the user Bob in the Syngress domain, they would enter Syngress\Bob in the username field.

Note

If your Web server is also a domain controller, there are no local accounts.

Using Digest Authentication

Digest authentication has many similarities to basic authentication, but also addresses many of the problems with basic authentication. Digest authentication does not send usernames or passwords over the network. It is more secure than basic authentication, but requires more planning to make it work.

Some of the similarities with basic authentication are:

Users must have the "Log on Locally" permission.
Both methods work through firewalls and proxy servers.

Like all authentication methods, digest authentication has some drawbacks including:

Users can only access resources on the IIS server. Their credentials cannot be passed to another computer.
The IIS server must be a member of a domain.
All user accounts must store passwords using reversible encryption.
Digest authentication works only with Internet Explorer version 5.0 or higher.

Digest authentication is secure due to the way it passes authentication information over the network. Usernames and passwords are never sent. Instead, IIS uses a message digest (also called a hash) to verify the user's credentials. A hash works by applying a one-way mathematical formula to data. The data used here is the user's username and password. Because the hash is one-way, it cannot be reversed to recover a user's information.

For digest authentication to work, all user accounts must be stored using reversible encryption. When an IIS server receives a digest authentication request, it receives a hash value. IIS sends the hash value to Active Directory to verify that the user's information is correct. Active Directory must run the same hashing formula against the user's information. If the hash value that Active Directory receives matches the hash it received from the IIS, the user's information is correct. If Active Directory reaches a different value, the user's information is considered incorrect. Active Directory can only run the hashing formula against the user's information if it has a plaintext copy of the password. Choosing the "Store Passwords Using Reversible Encryption" option on a user account (see Figure 8.27) stores a plaintext copy of the password in Active Directory. After enabling this setting for a user account, the user's password must be changed to create the plaintext copy.

click to expand
Figure 8.27: User Account Properties

Using Integrated Windows Authentication

Integrated Windows Authentication (IWA) is secure because usernames and passwords are not transmitted across the network. IWA is convenient because if a user is already logged on to the domain and has the correct permissions for the site, they are not prompted for their username and password. Instead, IIS attempts to use the user's cached credentials for authentication. The cached credentials are hashed and sent to the IIS server for authentication. If the cached credentials do not have the correct permissions, the user is prompted to enter a different username and password.

IWA uses either NTLM or Kerberos for authentication. The Web browser and the IIS server negotiate which type to use. Both Kerberos and NTLM have their own advantages and disadvantages. Kerberos is less likely to be compromised because it is more secure than NTLM. Unlike NTLM, which authenticates only the client, Kerberos authenticates both the client and the server, which helps prevent spoofing. Kerberos allows users to access remote network resources not located on the IIS server, while NTLM restricts users to the information located on the IIS server.

Kerberos is the preferred authentication method. Following are the requirements for Kerberos to be used instead of NTLM:

The client machine must be in either the same domain as the IIS server or in a trusted domain.
The client machine must be running Windows 2000.
The client must be using Internet Explorer version 5.0 or higher.

IWA has a few limitations including :

It works only with Internet Explorer version 2.0 or higher (for NTLM authentication).
While NTLM can generally get past firewalls, it is usually stopped by proxy servers.
Kerberos can get past the proxy server, but is usually stopped by the firewall.

Using Client Certificate Mapping

Client certificate mapping is the process of mapping a certificate to a user account. There are two types of certificate mappings, both of which require the use of SSL:

One-to-one mapping
Many-to-one mapping

Before discussing the differences between these types of mapping, it is important to understand why mapping is beneficial. Normally, if an administrator wants to give a user access to a site, they create a user account. (assuming they are not allowing anonymous access.) They would give the user the username and password and let them use one of the three authentication methods previously discussed—basic, digest, or Windows Integrated. This is done because the operating system requires the use of user accounts for controlling access. To provide better security and reduce the administrative workload, the administrator can give users a certificate (see Chapter 4). Certificates are used to verify a user's identity. Using a certificate is more efficient than using a user account because certificates can be examined without having to connect to a database. It is also safer to distribute certificates than user accounts because it is much easier to guess or crack someone's password than it is to forge a certificate.

Where does mapping fit into the picture? If certificates are more secure and easier to distribute than user accounts, but the operating system requires a user account to control access, what should be done? A mapping between the user account and the certificate can be created. When a user presents the certificate to the operating system, they are given whatever rights are assigned to the mapped account. The end result is identical to the user logging on with a username and password. This solution provides the best of both worlds because they do not have to distribute usernames and passwords to all users, but can still employ user accounts to secure resources.

One-to-One Certificate Mapping

As the name indicates, one-to-one mappings map one user account to one certificate. The user presents his certificate, and the IIS compares the certificate to the certificate that it contains for the user. If the certificates match, the user is authenticated with their mapped account. For this system to work, the server must contain a copy of all client certificates. Generally, one-to-one mappings are used in small environments. One of the reasons mapping is used is to make networks easier to administer. If one-to-one mapping is used in a large environment, a large database is created because every certificate is mapped to a unique account.

Many-to-One Certificate Mapping

Many-to-one mappings map many certificates to one user account. Many-to-one mappings are processed differently than one-to-one mappings. Since there is no one-to-one association between user accounts and certificates, the server does not have to maintain a copy of individual user certificates. Instead, it uses rules to verify a client. Rules are configured to look for certain items in a client's certificate. If those items are correct, the user is mapped to the shared user account. For example, a rule can be set up to check which certificate authority (CA) issued the certificate. If a company's CA issued the certificate, the mapping would be allowed. If the certificate was issued by another CA, the user would be denied access.

Test Day Tip

It will be useful if you write down the various methods of Web authentication on your scrap paper before beginning the exam. Be sure to write down the pluses and minuses of each method and any special considerations that must be taken into account when working with each method.

Combining Authentication Methods

Table 8.3 summarizes the different authentication methods supported in IIS 5.0. Now it is important to learn how the IIS handles authentication when multiple protocols are allowed. Internet browsers always attempt to use client mappings first, followed by anonymous authentication. If anonymous authentication access fails, it is then the responsibility of the Web server to send a list of alternate authentication methods that are supported. The browser attempts to use the alternate authentication methods that it supports in the following order:

Integrated Windows authentication (Kerberos-based)
Integrated Windows authentication (NTLM-based)
Digest authentication
Basic authentication

Table 8.3: Summary of the Authentication Methods Supported in IIS 5.0
	Anonymous (Password Controlled by IIS)	Anonymous (Password Controlled by AD)	Basic	Digest	Integrated Windows(Kerberos)	Integrated Windows(NTLM)	Certificate Mapping(IIS)	Certificate Mapping (AD)
Works through firewalls	Yes	Yes	Yes	Yes	No^[*]	Yes^[*]	Yes	Yes
Works through proxy servers	Yes	Yes	Yes	Yes	Yes^[*]	No^[*]	Yes	Yes
Compatible with lower versions of Internet Explorer (2.0 and lower)	Yes	Yes	Yes	No	No	Yes	Yes	Yes
Allows users to access remote resources	No	Yes	Yes	No	Yes	No	Yes	No
Compatible with browsers other than Internet Explorer	Yes	Yes	Yes	Varies	No	No	Varies	Varies
Requires Internet Explorer 5.0 or higher	No	No	No	Yes	Yes	No	No	No
^[]Refer back to the discussion on IWA concerning passing through firewalls and proxy servers.*

Exam 70-124: Objective 3.5, 3.5.2, 3.6: Configuring Web Site Authentication

Before certificates can be used on a Web server for authentication, there are two server certificates that must be available. The first is for the CA itself, and the second is for the Web server. There must be two different certificates for these two different functions, even if both reside on the same server. It is assumed that a Windows 2000 CA is already in place (see Chapter 4 for how to configure a CA). To obtain a server certificate for an IIS server, complete the procedure outlined in Exercise 8.10

Exercise 8.10: Requesting a Server Certificate for the IIS Server

Open the Internet Services Manager from the Administrative Tools folder.
Select your Web site, right-click, and select Properties from the context menu (see Figure 8.28).

Figure 8.28: Opening the Web Site Properties
Switch to the Directory Security tab (see Figure 8.29) and click Server Certificate to start the Web Server Certificate Wizard.

Figure 8.29: Configuring Web Site Security
Dismiss the opening page of the Wizard.
Select Create a new certificate and click Next.
If you already have an online CA configured, you should select Send the request immediately to an online certification authority and then click Next to continue.
Configure the certificate name and key length as shown in Figure 8.30, and click Next to continue.

Figure 8.30: Configuring the Certificate Name and Key Length
Enter or select the organization name and OU as shown in Figure 8.31, and click Next to continue.

Figure 8.31: Selecting the Organization Name and OU Information
Enter the IIS server's common name—the FQDN if on the Internet or the NetBIOS name if on an Intranet—and click Next to continue. This name is extremely critical and must be configured exactly the same as the name that users will use to connect to the site.
Enter the required geographical information and click Next to continue.
Select a CA to issue the certificate and click Next.
Click Next after you have reviewed the configuration to start the issuance process.
Click Finish when you are done. You now have a server certificate for your IIS server. The View Certificate and Edit buttons previously grayed out in Figure 8.29 are now available for configuring.

In Exercise 8.11 you will configure various Web site authentication methods that do not use SSL. Exercise 8.12 will examine configuring Web site authentication using SSL based methods.

Exercise 8.11 : Configuring Anonymous, Basic, Digest, and Integrated Windows Web Site Authentication

Open the Internet Services Manager from the Administrative Tools folder.
Select your Web site, right-click, and select Properties from the context menu.
Click the Directory Security tab.
Click Edit in the "Anonymous Access and Authentication Control" section of the Directory Security tab, as shown in Figure 8.32.

Figure 8.32: The Directory Security Tab of a Web Site's Properties
Choose the authentication methods that you want to allow (see Figure 8.33). Anonymous access is enabled by default.

Figure 8.33: Choosing Authentication Methods
You can change the account that the IIS uses for anonymous access by clicking the Edit button. Figure 8.34 shows the configuration window with the default anonymous access account.

Figure 8.34: Changing the Account Used for Anonymous Access
If you enable basic authentication, you will receive the warning dialog shown in Figure 8.35.As the warning states, this is not a big problem if you require SSL connections (Exercise 8.10).

Figure 8.35: The Cleartext Warning Dialog
If your authentication domain is different from the domain the IIS server is located in, you will need to configure authentication domain as shown in Figure 8.36. If it is the same domain, you can safely leave this box blank, which forces the default behavior of the authenticating users to the domain the IIS server is located in.

Figure 8.36: Configuring the Basic Authentication Default Domain
If you configure digest authentication, you will receive the warning dialog shown in Figure 8.37. You will need to ensure that you have configured user accounts for Store Passwords Using Reversible Encryption, as shown in Figure 8.27.

Figure 8.37: The Digest Authentication Warning Dialog Box
Click OK to accept your changes when you are done.

Head of the Class…
Allow IIS to Control Password

When an account is authenticated by the IIS, it is made a member of the Network group. When Windows authenticates a user, they are made a member of the Interactive group. To enable Windows to do the authentication, uncheck the Allow IIS to Control Password box. The Network group consists of users who are given access to resources over the network. The Interactive group consists of users who log on locally.

What does this mean? The "Allow IIS to Control Password" option controls whether users can access network resources or if they are limited to the IIS server only. If the IIS authenticates the anonymous account, the user can only access resources on the IIS server. The network group does not have rights to remote resources. If Windows authenticates the anonymous account, the user can access other network resources. The Interactive group is given the "Log on Locally" permission that can be forwarded to other servers for authentication.

Exercise 8.12: Configuring Web Authentication using SSL

Open the Internet Services Manager from the Administrative Tools folder.
Select your Web site, right-click, and select Properties from the context menu.
Click the Directory Security tab.
Click Edit in the "Secure Communications" section of the Directory Security tab, as shown in Figure 8.32. The window shown in Figure 8.38 will open.

Figure 8.38: Configuring SSL Properties
Configure your secure communication settings as desires.
- Select the Require secure channel (SSL) check box to configure SSL)-encrypted communication for visitors using a Web browser that supports secure communications—URLs starting with https://.
- Select the Require 128-bit encryption check box to require a 128-bit encrypted communication link for a Web browser to connect with this Web site. This setting is only available once you have selected the Require secure channel (SSL) option.
- Selecting the Ignore client certificates option allows users to have access without being prompted to present a client certificate. This is not a recommended setting as it degrades overall security.
- Selecting the Accept client certificates option allows users with client certificates access, but does not require the certificate. A user that has a valid certificate can use certificate mapping; a user without a valid certificate must use one of the previously discussed authentication methods.
- Selecting the Require client certificates will allow only users with a valid client certificate to connect to the Web site. Users without a valid client certificate will be denied access. This setting is only available once you have selected the Require secure channel (SSL) option.
If you want to use certificate mapping, select the Enable client certificate mapping check box and then click Edit to configure the mappings, as previously described.
To create or edit approved certificate trust lists (CTL) for the Web site, enable this option and click New or Edit to configure it. A CTL is a list of approved CAs for a particular Web site.
Click OK to close out the Secure Communications dialog.
Remember that SSL uses port 443 by default, so make sure you have not blocked this at your firewall.

Test Day Tip

If you set the Require 128-bit encryption option and clients attempt to connect with a valid certificate but with a browser that cannot support 128-bit encryption, they will not be able to connect. Also note that this option is available even if your IIS 5.0 computer does not support 128-bit itself. Select this option with care!

Troubleshooting Web Authentication

Any number of issues may occur that will prevent successful Web authentication from occurring. The most common, however, are easily checked and can be prevented with careful planning and execution when it comes time to configure authentication for Web users.

Putting aside any issues that may arise due to network communications problems (which can be many and varied), the most common problems experienced with Web authentication are summarized in Table 8.4.

Table 8.4: Troubleshooting Common Web Authentication Problems
Problem	Possible Cause and Solution
The user is attempting to connect to an incorrect port number.	This can happen if a custom (non-standard port) is configured for a Web server—such as in the case where SSL is enabled and the port is changed to something other than 443. Either the port the server is operating on must be changed to the standard port (best option) or clients must be instructed to access the correct port by appending it onto the URL, such as https://www.myverysecuresite.com:4563
Anonymous users cannot access the Web site.	The Web site is probably not configured for anonymous access. If anonymous access is desired, it must be re-enabled from the Web site Properties page, Directory Security tab. (See Exercise 8.11).
Anonymous users cannot access the Web site.	The anonymous user account either does not exist or is configured incorrectly. The built-in local user account for IIS anonymous access should be used. It is important to ensure that the permissions have not been changed such that this account has the right to log on locally.
Digest authentication users cannot access the Web site.	The user most likely does not have a valid, active Windows 2000 user account in an Active Directory domain. If the Web site is configured to use digest authentication or integrated Windows authentication only (that is, no Basic authentication or certificate mapping), then the user must have a valid, active Windows 2000 user account. Additionally, for digest authentication, the user's account must be in a Windows 2000 Active Directory domain.
Integrated Windows authentication users cannot access the Web site.	The user most likely does not have a valid, active Windows 2000 user account. If the Web site is configured to use digest authentication or integrated Windows authentication only (that is, no basic authentication or certificate mapping), then the user must have a valid, active Windows 2000 user account
SSL users cannot access the Web site.	The user may be attempting to access the wrong port or may not have the required credentials. It is important to ensure that clients are accessing the correct port (443 for HTTP, although SSL can be used for other traffic, such as POP and IMAP).It is also important to ensure that the client has the required credentials and digital certificates to allow for SSL communications.