Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

The HTTP protocol specification includes a set of specific HTTP headers to deal with authentication in a Web environment. The HTTP specification also defines Web authentication methods: basic authentication— which is a part of the HTTP version 1.0 specification—and digest authentication—which is a part of the HTTP version 1.1 specification. Both authentication protocols are explained next.

Figure 6.4 shows the different messages that are exchanged between a Web browser^[4] and server during an HTTP-based authentication exchange:

Figure 6.4: Typical HTTP authentication exchange.

1. The browser requests data from the Web server using an HTTP GET verb.

2. If the Web server requires the client to authenticate himself or herself, it sends an HTTP 401 error back to the browser, along with:

   • A list of the authentication schemes it supports

   • A challenge. Not all web authentication protocols use this challenge. When using digest authenticaton for example the browser uses it to calculate the authentication reply that is sent back to the server. The challenge is sent as one or more WWW-Authenticate headers in the server’s response.

3. The browser chooses one of the Web authentication protocols that it supports and constructs an authentication response. The response is based on the user’s credentials and—depending on the authentication protocol used—also on the challenge that was sent by the server. To obtain the user’s credentials the browser will prompt the user. The response is sent back to the server as part of an authorization header.

4. The server authenticates the data it got from the browser and, assuming everything is okay, sends the response, and the requested resource, back to the user. The latter message includes an HTTP 200 status code—which is a “no errors” message.

Step 2 of this authentication exchange begins with “if the Web server requires the client to authenticate himself of herself.” Authentication is indeed an option. Many Web sites do not care about the identity of a user—good examples are Web sites containing public information that should be available to everyone. For such sites authentication is just over- head, slowing down the information exchange. That is why most Web servers (including IIS) also provide an anonymous access method. If a Web site is configured to use this access method, anyone is allowed to access the site, even those users who do not provide credentials. Anonymous access is explained in more detail in the next section.

Figure 6.5: Anonymous access exchange.

Examining Web Authentication Exchanges A great tool for testing and troubleshooting Web servers is the IIS 6.0 Resource Kit tool WebFetch (wfetch) (illustrated in Figure 6.6). WebFetch does not render the HTTP content that it receives from the Web server—which makes it an interesting tool for analyzing HTTP messages. Note the WWW- Authenticate headers that are sent back by the Web server in the example of Figure 6.6.

Figure 6.6: Using the IIS Resource Kit WebFetch (WFetch) tool.

The IIS 6.0 Resource Kit tools can be downloaded from the following URL:

http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499&DisplayLang=en.

6.3.1 Anonymous access

Even though—from an end-user point of view—“anonymous access” appears as “no identification at all,” there will be an authentication process at the Web server level. IIS always authenticates every anonymous session against the Windows security infrastructure using a preconfigured anonymous account. By default, this account is the IUSR_<computername> account (which is also known as the Internet guest account). This account is created automatically in the Windows Security database (SAM or AD) when an IIS Web server is installed. Figure 6.5 shows an anonymous access message exchange between a Web browser and server. In this instance the web server has been enabled for anonymous access and thus any request that does not contain credentials is a valid request.

The advantage of the back-end anonymous authentication process is that regular Windows authorization settings can be applied to Web resources that are accessed by anonymous users. This also means that if a Web resource has specific authorization settings that do not give access to the Internet guest account, the user will be asked to provide credentials.

The Internet guest account can be changed for every individual Web server, virtual directory, directory, and file. This can be done by clicking the Browse button in the anonymous access section in the Authentication Methods dialog box (see also Figure 6.2). Changing the Internet guest account on a particular virtual directory allows you to set different authorization settings on that directory. For example you may not want everyone to have access to every directory on every server using the same anonymous access account.

By default, IIS performs a network logon when an authentication occurs using the Internet guest account (by default, the Internet guest account is assigned the network logon user right). In IIS 5.0 and earlier versions the default logon type was interactive. Interactive logon requires the interactive logon user right. The latter imposes a security risk, because of the high amount of system privileges that are associated with it. The use of network logon as the default logon type in IIS 6.0 is another proof of how much more IIS 6.0 is secure by default.

6.3.2 Basic authentication

The basic authentication protocol is part of the HTTP 1.0 protocol specification. Because of this it can work with any browser type. Basic authentication provides a simple mechanism to transmit user credentials (a user ID and password) to a Web server.

Figure 6.7 shows the different messages that are exchanged between a Web browser and server during a basic authentication exchange.^[5]

Figure 6.7: Basic authentication exchange.

1. The browser requests data from the server by using an HTTP GET verb.

2. If the Web server requires the client to authenticate himself or herself, it sends an HTTP 401 error back to the browser, along with:

   • A list of the authentication schemes it supports, this time including the “basic” verb

   • The name of the basic authentication realm. The concept of a realm will be explained below.

3. Before replying to the challenge, the browser prompts the user for its username and password (as illustrated in Figure 6.8). This credential prompt will not occur if the user has previously cached his or her credentials in the user profile (using the “Remember my password” option) or if the URL that was used to access the website contains the username and password. The browser then responds to the authentication request by base64 encoding its username, password, and the authentication realm and sending the encoded blob back to the Web server as an authorization host header.

   Figure 6.8: Basic authentication credential prompt.

4. The server authenticates the browser’s response and, if everything is okay,^[6] sends the response, and the requested resource, back to the user. The latter message includes an HTTP 200 status code.

The credential information, which is sent between a Web browser and server when using basic authentication is not secured, it is just base64 encoded. Because it is relatively easy to decode a base64 encoding (see also the following sidebar on decoding base64 encoding), it is advisable to secure the HTTP traffic using the SSL-TLS (Secure Sockets Layer—Trans- port Layer Security) protocols. We will come back to these protocols later in this chapter. When enabling basic authentication on a Web resource, IIS warns you about this potential security hole (as shown in Figure 6.9).

Figure 6.9: Basic authentication warning.

Decoding Base64 Encoding Decoding Base64-encoded messages is relatively easy. Base64 encodes messages by storing every three 8-bit characters in four 6-bit characters.

The easiest way to decode base64 is to use one of the online base64-decoder tools such as the tool at http://www.robertgraham.com/tools/base64coder.html.

Try to decode the following basic authentication string at the above URL:

ZG9tYWluXHVzZXJuYW1lOnBhc3N3b3Jk

What is the result of the decoding?

When setting basic authentication for a Web resource, you can also configure the default domain and realm at the bottom of the ISM authentication methods dialog box (see also Figure 6.2).

• The default domain allows you to set the domain to which a user should be authenticated when no domain is provided during the authentication process. In the example of Figure 6.8, the user provided an authentication domain called “dc” by preceding his or her username with dc\ In the example of Figure 6.8, the default domain specified in the authentication properties will be ignored. To enable User Principal Name (UPN) -based logon in a Windows 2000 or later domain environment you must specify “\” in the default domain field.

• The realm is a level within the IIS metabase hierarchy that a user is allowed to access when using basic authentication. By default, it is the IIS computer name—which provides access to all levels in the IIS metabase hierarchy (as illustrated in Figure 6.8 for machine vmw2k33763). The realm always appears in the left top corner of the basic authentication dialog box. Figure 6.10 shows how the custom realm /LM/W3SVC/1/Root/MyVirtualDir is displayed in the basic authentication dialog box. A Web resource’s realm property can be set from the bottom of the Authentication Methods dialog box or in the IIS metabase. How to specify custom realms is explained in the IIS documentation. Both digest and advanced digest authentication (explained below) also use the realm concept.

  Figure 6.10: Basic authentication credential prompt with custom realm.

Other interesting basic authentication options that cannot be set from the ISM GUI but only by editing the IIS metabase directly are the following:

• The logon type (LogonMethod metabase property) specifies the logon type that IIS performs when a basic authentication Web logon session occurs. As for anonymous access, by default, IIS performs a network logon (LogonMethod value 2). Other possible Logon- Method values are 1 (for batch logon) and 3 (for network clear-text logon).

• The token cache time (UserTokenTTL metabase property) specifies the amount of time a user’s access token is cached and remains valid on the Web server. The default is 15 minutes. If you do not want to cache tokens on the Web server, set the UserTokenTTL to 0.

6.3.3 Digest authentication

Digest authentication was originally specified as part of the HTTP 1.0 protocol specification—an enhanced version is defined in the HTTP 1.1 protocol specification. Both versions are defined in RFC 2617. Like the NTLM authentication protocol, it uses a challenge-response–based authentication method. One of the key advantages of digest authentication is that it does not transmit the user credentials in the clear over the network (like basic authentication does) and thus does not require the use of the SSL or TLS protocols.

HTTP 1.1 and digest authentication are not yet supported by all browser and Web server types and versions. On the Microsoft side it is supported by IE5.0 and IIS 5.0 and later versions.

A major disadvantage of digest authentication is that it requires Active Directory user accounts (IIS warns you for this when enabling digest authentication—see Figure 6.11) and the clear-text storage of the password in the AD. In AD clear-text password storage can be set using a property of the user object: “Store Password using Reversible Encryption.” You can also enforce clear-text password storage using the “Store Passwords using Reversible Encryption” Group Policy Object setting (located in the Security Settings\Account Policies\Password Policy container). After making this setting, the user or administrator must set a new password to activate the clear-text password storage.

Figure 6.11: Digest authentication warning.

Figure 6.12 shows how digest authentication works:

Figure 6.12: Digest authentication exchange.

1. The user’s browser requests access to the default.htm Web page.

2. The Web site replies with a 401 access denied message. The server’s reply also tells the browser that the Web page requires digest authentication (the WWW-authenticate contains the word “digest”) and lists the digest authentication realm to which the Web page belongs (in the example, realm “aaaa”). Most important, the reply also contains a digest challenge—which is usually referred to as the nonce (in the example, “XXXX”).

3. Before replying to the challenge, the browser prompts the user for its username and password. The browser hashes^[7] the challenge using the user’s password. The outcome of this hash (in the example, response “YYYY”) together with the nonce (in the example, “xxxx”) and the realm (in the example, “aaaa”) are then sent back to the Web server.

4. The Web server validates the response it gets from the browser by calculating the same hash and comparing it with what it got back from the browser. The Web server can calculate the hash because it also has access to the user’s password (which is stored in AD). If everything is okay, the Web server sends the requested resource back to the user. The latter message includes an HTTP 200 status code.

The use of digest authentication will generate a typical authentication dialog box on the browser side. This dialog box is illustrated in Figure 6.13. The dialog box explicitly refers to the name of the resource the user tries to access and the use of the digest authentication protocol.

Figure 6.13: Digest authentication dialog box.

Two big architectural changes related to digest authentication in Windows Server 2003 are the inclusion of a digest security support provider (SSP) and the support for advanced digest authentication.

• In Windows Server 2003, Microsoft has implemented digest authentication (and advanced digest authentication—explained next) in the operating system using an SSP—SSPs were explained in Chapter 4. This does not mean that you cannot use digest authentication on an IIS server that is running on top of Windows 2000. In the latter case you must enable a special digest subauthentication dll called iissuba.dll and set the UseDigestSSP IIS metabase property to 0 (false). For more information on how to do this, I refer to the IIS 6.0 documentation.

• Advanced digest authentication is an enhanced version of the digest authentication protocol. The key advantage of advanced digest authentication is that it does not require clear-text storage of users’ passwords (even though it requires the use of an AD account). Advanced digest authentication is only available for Web authentication if IIS 6.0 is running on a Windows Server 2003 box, if the browser used on the client side is at least IE 5.0 or later, if the user account used for authentication is defined in a Windows Server 2003 domain that is at functionality level 2 (meaning that it only contains Windows Server 2003 domain controllers), and if the UseDigestSSP metabase property is set to 1 (true). If one of these conditions is not met, simple digest authentication will be used.

As with basic authentication, you can configure the default domain and realm properties in the ISM when setting digest authentication for a Web resource. For digest authentication only, the metabase realm property is useful (even though the default domain box is also enabled when setting digest authentication).

Recognizing Advanced Digest Authentication Support The key element allowing you to recognize whether advanced digest authentication is available on the Web server is the quality of protection (qop) parameter (see Figure 6.14) in the WWW-authenticate header. In IIS 6.0 the qop parameter typically has the “auth” value

Figure 6.14: WFetch advanced digest authentication exchange.

In IIS 6.0 Microsoft did not implement the authentication message replay protection and mutual authentication features of improved digest authentication. They did implement the “frequent HTTP client” feature. This feature can be recognized by the presence of the algorithm=MD5-sess parameter in the WWW-authenticate header (see Figure 6.14). It protects against attacks that are based on an offline analysis of the HTTP messages. It forces the client to change the MD5 hash key that is used by the digest protocol periodically.

^[4]Or any other HTTP client: for example an HTTP proxy server.

^[5]You can shortcut the basic authentication exchange by including the user credentials in the URL that is passed to the Web server. To do so use the following URL format: http://username:password@yourwebsite.com.

^[6]By default, IIS gives a user three basic authentication attempts.

^[7]Digest authentication uses the MD5 hashing algorithm.