Windows Server 2008 R2 Unleashed (86 page)

should be carefully reviewed, especially if it’s a custom-built application. If the application

is developed by a vendor, make sure that you have an application that is certified to run

on Windows Server 2008 R2 and that the latest service packs and patches have been

applied and tested.

NOTE

For more information on securing Windows Server 2008 R2, refer to Part IV, “Security.”

ptg

IIS Authentication

Authentication is a process that verifies that users are who they say they are. IIS supports a

multitude of authentication methods, including the following:

.
Anonymous Authentication—
Users can establish a connection to the website

without providing credentials.

.
Active Directory Client Certificate Authentication—
Users can establish a

connection by using their Active Directory client certificate for authentication.

.
ASP.NET Impersonation—
Users can utilize an impersonation context other than

the ASP.NET account.

.
Windows Authentication—
This authentication method can be integrated with

Active Directory. As users log on, the hash value of the password is sent across the

wire instead of the actual password.

.
Digest Authentication—
Similar to Integrated Windows authentication, a hash

value of the password is transmitted. Digest authentication requires a Windows

Server domain controller to validate the hash value.

.
Basic Authentication—
Basic authentication sends the username and password over

the wire in clear text format. This authentication method offers little security to

protect against unauthorized access.

.
Forms Authentication—
Users are redirected to a page where they enter their cre-

dentials. After they have been authenticated, they are redirected back to the page

they originally requested.

Securing Internet Information Services 7.5

409

These authentication methods can be enabled under the Authentication feature page, as

illustrated in Figure 12.16. You can view this window by clicking the Edit button located

on the Directory Security tab of a website properties page.

12

ptg

FIGURE 12.16

Authentication feature page.

Auditing Web Services

Windows Server 2008 R2 auditing can be applied to web and FTP sites to document

attempts to log on (successful and unsuccessful), to gain unauthorized access to service

accounts, to modify or delete files, and to execute restricted commands. These events can

be viewed through Event Viewer. It’s also important to monitor IIS logs in conjunction

with audited events to determine how, when, and if external users were trying to gain

unauthorized access.

Using SSL Certificates

Secure Sockets Layer (SSL) encryption preserves user and content integrity as well as confi-

dentiality so that communications from a client and the web server, containing sensitive

data such as passwords or credit card information, are protected. SSL is based on the

public key security protocol that protects communication by encrypting data before being

transmitted.

Previous versions of IIS could use SSL, and IIS 7.5 is no different. The exception to this,

though, is now it is possible to secure FTP sites by implementing SSL for FTP when using

the FTP Server included with version 7.5.

410

CHAPTER 12

Internet Information Services

SSL certificates serve three primary purposes, although they are typically used to encrypt

connections. These purposes include the following:

.
SSL server authentication—
This allows a client to validate a server’s identity. SSL-

enabled client software can use a Public Key Infrastructure (PKI) to check whether a

server’s certificate is valid. It can also check whether the certificate has been issued

by a trusted certificate authority (CA).

.
SSL client authentication—
This allows a server to validate a client’s identity. SSL

can validate that a client’s certificate is valid as well as check whether the certificate

is from a trusted CA.

.
Encrypting SSL connections—
The most common application of SSL is encrypting

all traffic on a given connection. This provides a high degree of confidentiality and

security.

From an IIS perspective, SSL can be applied to an entire website, directories, or specific

files within the website. SSL configuration can be done through Internet Information

Services (IIS) Manager.

The high-level steps for utilizing certificates and SSL consist of the following: The first step

is to obtain a certificate. The second step is to create an HTTPS binding for a specific site

that needs to be encrypted. The final step is to configure SSL settings for a site, applica-

ptg

tion, or physical directory.

To use SSL on a website, a certificate must first be requested and then installed. The

request can be created to obtain a certificate either from an external, trusted CA or from

an internal PKI. The types of server requests available in Internet Information Services

include the following:

.
Create Certificate Request—
This option is typically used for creating a certificate

request, which will be submitted to a third-party public CA. The certificate’s distin-

guished name properties, cryptographic service provider, and bit-length information

are entered into a file and then submitted to a public CA for approval.

TIP

When creating the certificate request to a public CA, it is recommended to use 1024

(the default) or higher as the bit length. Keep in mind that higher bit lengths enforce

stronger security; however, a greater length can decrease performance.

.
Create Domain Certificate Request—
A domain certificate request is used when

providing a request to an internal certificate authority. Typically, the internal certifi-

cate authority would be an enterprise certificate authority associated with the

company’s Active Directory domain. This approach reduces the cost of purchasing

third-party certificates and also simplifies the certificate deployment.

.
Create Self-Signed Certificate Request—
The final option available when creating

a certificate request is to use a self-signed certificate. Typically, this method is only

Securing Internet Information Services 7.5

411

used for maintaining certificates for a testing environment because the certificates

are not from a trusted CA.

This example illustrates the procedures to create a domain-based certificate request. To

complete this task, this example requires an internal certificate authority running within

your domain. For more information on creating an internal CA, refer to Chapter 15,

12

“Security Policies, Network Policy Server, and Network Access Protection.”

To create a domain-based certificate request, do the following:

1. Launch Internet Information Services (IIS) Manager.

2. In the Connections pane, highlight the IIS server that will request an Internet Server

Certificate.

3. In the Feature view, double-click the Server Certificates element.

4. In the Actions pane, select Create Domain Certificate Request.

5. On the Distinguished Name Properties page, specify the required information for the

certificate, as displayed in Figure 12.17. The common name is typically the fully

qualified domain name (FQDN) of the URL users will use to connect to the website

(for example, www.companyabc.com). Click Next to continue.

ptg

FIGURE 12.17

Creating a domain-based certificate request.

6. Because this is a domain-based certificate request, the next page presented is the

Online Certificate Authority. Specify the online certificate authority that will accept

the request by selecting the CA from a list. In addition, a friendly name is also

required. Click Finish to finalize the request.

After the create certificate process has been completed, either the administrator of the CA

must approve the request or it can be automatically approved based on the autoenroll-

ment feature of the domain-based CA. The CA in this example automatically fulfilled the

request; therefore, the certificate resides on the Server Certificates page and can be viewed

412

CHAPTER 12

Internet Information Services

by selecting it and clicking View Task in the Actions pane. Otherwise, an additional proce-

dure is required to install the certificate.

Because the certificate is already installed, the next step in the process is to bind the Internet

Server Certificate for the desired website and enable SSL. To do this, follow these steps:

1. Open the IIS Manager snap-in and select the website for which the binding will be

created.

2. In the Actions Pane, select Bindings to launch the Site Binding utility.

3. In the Web Site Bindings dialog box, click Add.

4. In the Add Site Binding dialog box, select the HTTPS option from the Type drop-down

menu, assign an IP address, and verify the port is 443, as shown in Figure 12.18.

ptg

FIGURE 12.18

Adding SSL site binding.

5. Select a certificate, such as the one that was created in the previous section. You can

view the certificate selected by clicking the View button. Click OK to return to the

Site Bindings dialog box.

6. Click Close in the Site Bindings dialog box to finalize the binding process.

The final process when configuring a site to utilize SSL is to configure the SSL settings for

the site application or the physical directory. To configure SSL settings on the new website

that was created in the previous steps, do the following:

1. In IIS Manager, navigate to the desired site for which you will configure SSL settings.

2. Double-Click the SSL Settings icon in Features view.

3. On the SSL Settings page, enable the Require SSL option. Alternatively, select the

Require 128-bit SSL option to force 128-bit encryption.

4. The final setting is to configure whether to accept, ignore, or require client certifi-

cates. Choose the appropriate Client Certificates option, and click Apply in the

Actions pane to save the changes, as shown in Figure 12.19.

Administering IIS 7.5 Administrator and User Security

Several built-in administrator roles exist for managing Internet Information Services (IIS)

7.5. This is a new approach to IIS administration as users can be assigned to these