Microsoft Windows Security Resource Kit

Configuring IIS Security

Within the Internet Services Manager console, you can configure additional security for IIS by modifying the Web server s Master Properties and properties of individual Web sites, virtual directories, and Web content. The properties that affect the security include the following:

• Authentication

• Web site permissions

• Communication channels

Authentication

IIS provides different methods for authenticating users when they connect to a Web site hosted by the Web server. The method you choose depends on the type of data stored on the Web site, as well as your network environment. The network environment includes the domain membership of the Web server and the Web browser implemented by Web clients.

Configuring Authentication Methods

IIS authentication methods can be configured in two locations. The first location is in the properties of the Master Properties for the WWW Service. Master Properties affect default settings for all future Web sites installed at the Web server. The following steps explain how to configure IIS authentication methods via Master Properties:

1. From Administrative Tools, open the Internet Services Manager.

2. In the console tree, right-click ComputerName (which is the NetBIOS name of the Web server) and then click Properties.

3. In the Master Properties section of the ComputerName Properties dialog box, select WWW Service from the Master Properties drop-down list. Then click Edit.

4. In the Anonymous Access And Authentication Control section of the Directory Security tab in the WWW Service Master Properties For ComputerName dialog box, click Edit.

5. In the Authentication Methods dialog box (shown in Figure 21-2), enable all required authentication methods and click OK.

   Figure 21-2. Defining authentication methods allowed for a Web site

You can also configure authentication methods for each Web site. Individual Web site properties take precedence over those of the Master Properties. To modify authentication methods for a specific Web site or a virtual directory within a Web site, you must edit authentication methods within the Directory Security tab of the Web site s or the virtual directory s properties.

Choosing Authentication Methods

The following methods are available for authenticating users as they connect to a Web site or virtual directory:

• Anonymous authentication

• Basic authentication

• Digest authentication

• Integrated Windows authentication

• Certificate-based authentication

Anonymous Authentication

Anonymous authentication allows users to access a Web site without providing a user name and password for credentials. The Web site implements a predefined user account and password for the connection. By default, a local user account is created when IIS is installed. The name of this account is IUSR_ComputerName and is a member of the local Guests group account.

You can increase anonymous user account security by creating a custom user account and custom group for all security assignments. The user account s password must be controlled by IIS to ensure the password is changed when required. By using a custom group, you assign all anonymous permissions for the Web site directly to the custom group, while prohibiting the application of other permissions to the Web site s anonymous user account. If you implement a custom IIS anonymous user account, you must assign the user account the Log On Locally user right either in the local security policy of the Web server or at the OU where the computer account for the Web server exists.

Basic Authentication

Basic authentication is supported by most Web browsers. Basic authentication allows a user to provide credentials when requested by a Web site. The security issue with basic authentication is that the user s account and password are sent to the Web server in an unencrypted format that uses base64 encoding, meaning that the user s credentials are susceptible to inspection.

You can increase the security of basic authentication by implementing Secure Sockets Layer (SSL) to encrypt all data sent to the Web site. The user s credentials are then encrypted as they are transmitted from the Web client to the Web server.

Digest Authentication

Digest authentication increases the security of the user s credentials by not sending the user s password over the network. Instead, the user s password and other information about the account are used to create a hash that is sent to the Web server. The Web server compares this hash with Active Directory s version of the hash. If the two hash versions match, the user is considered authenticated.

Digest authentication requires that the Store Password Using Reversible Encryption option is enabled at the user account. This option stores the user s password hash in Active Directory, but the setting does not take effect until the next time the user changes her password. The password s reversibly encrypted format is stored when the user s password is set.

Although digest authentication increases the security of transmitted credentials, it lessens the security of Active Directory. Because of the weakened password storage required by digest authentication, you must ensure that the domain controller is physically secure.

Integrated Windows Authentication

Integrated Windows authentication uses NT LAN Manager (NTLM) or Kerberos v5 to authenticate a Web client with a Web server. The user name and password are not sent across the network, protecting against credential interception. Integrated Windows authentication requires that the Web client use the Microsoft Internet Explorer Web browser because other browsers do not support this form of authentication.

Certificate-Based Authentication

Windows 2000 allows User certificates to be used for user account authentication. If you want to enforce certificate-based authentication, User certificates must have the Client Authentication Extended Key Usage (EKU) attribute to allow certificate-based authentication and the Web server must have a Web Server certificate installed.

When a user connects to a Web server, he is prompted to select an authentication certificate. The user s certificate is sent to the Web server, which associates the presented certificate to a user account either in the local Security Accounts Manager (SAM) database of the Web server or in Active Directory. The certificate is mapped to a user account either in the IIS console or in Active Directory if the Enable The Windows Directory Service Mapper option is enabled in the Web site s Properties page. The public key associated with the certificate is retrieved from IIS or Active Directory, depending on the mapping, and is then used to encrypt authentication data. Only the holder of the certificate s private key can decrypt the authentication data.

You enforce certificate-based authentication by performing two steps:

1. Enforce client-based certificates in the Web site s Properties page. In the Secure Communications dialog box, you can require client certificates by enabling SSL for the Web site and clicking the Require Client Certificates option button, as shown in Figure 21-3.

2. Remove all other forms of authentication from the properties of the Web site. If you clear all the authentication method check boxes shown in Figure 21-2, you prevent all forms of authentication other than certificate-based authentication. This prevents IIS from presenting alternate authentication forms if the certificate-based authentication fails.

   Figure 21-3. Configuring the Web site to require client certificate-based authentication

Web Site Permissions

The Internet Services Manager console allows you to define permissions for a Web site or virtual directory. These permissions are separate from NTFS permissions applied to the actual Web content folder.

If NTFS permissions and Web site permissions are in conflict, the more restrictive permissions are applied. For example, if NTFS permissions allow a user to modify the contents of a folder but the Web permissions grant only Read permissions, the user is assigned Read permissions.

You define the permissions for a Web site in the Home Directory tab of a Web site s property pages, as shown in Figure 21-4. When defining a Web site s permissions, you can apply any combination of the following permissions:

• Script Source Access

  Allows users of the Web site or virtual directory to access the source code for a Web site, including Microsoft Active Server Pages (ASP) applications, if the Read or Write permissions are also defined for the Web site or virtual directory. This permission is available for Web sites, virtual directories, and individual files.

• Read

  Allows users of the Web site to read Web content posted at the Web site and to navigate between pages on the Web site. This permission is available for Web sites, virtual directories, and individual files.

• Write

  Allows users to upload files to the Web site or the Web site s specific upload folder. This permission also allows a user to modify the contents of a Write-enabled file at the Web server. This permission is available for Web sites, virtual directories, and individual files. Write permissions are available only to Web browsers that support the HTTP 1.1 protocol standard PUT feature.

• Directory Browsing

  Allows users to view hypertext listings of all files and subdirectories within a Web site folder or a virtual directory, if a default document is not located in the folder or virtual directory. Virtual directories will not appear in the hypertext listing. The user must know the virtual directory s alias or must click a link that refers her to the virtual directory. This permission is available only for Web sites and virtual directories.

  Figure 21-4. Defining permissions for a Web site

Communication Channels

Additional security can be provided for connections to the Web server by implementing SSL encryption between the Web server and Web clients. SSL is enabled by installing a Web Server certificate at the Web server. Specifically, the Web Server certificate must have the following attributes:

• The certificate must chain to a trusted root authority. The root Certification Authority (CA) in the certificate chain must be included in the trusted root store of all clients that connect to the SSL-protected Web server.

• The installed certificate must have a Server Authentication object ID (OID) in the EKU attribute of the certificate. The Server Authentication OID (1.3.6.1.5.5.7.3.1) indicates that the Web Server certificate can be used to authenticate the Web server s identity and can also be used to encrypt session data between the Web server and Web clients.

• The subject of the certificate must match the Domain Name System (DNS) name used to access the Web site. For example, if the Web site is accessed by connecting to http://www.example.com, the subject of the Web Server certificate must be www.example.com.

  A common mistake administrators make when requesting a Web Server certificate is to request the certificate with the Web server s NetBIOS name as the subject, rather than the Web site s DNS name as the subject. If you do not use the Web site s DNS name as the subject, a user connecting to the Web site will receive a warning that the Web site s certificate name does not match the name of the Web site.

Enabling SSL

To enable SSL, you must install a Web Server certificate at the Web server. You can install a Web Server certificate by running the Web Server Certificate Wizard:

1. From Administrative Tools, open the Internet Service Manager console.

2. In the console tree, expand the NetBIOS name of the Web server, right-click Default Web Site, and click Properties.

3. In the Default Web Site Properties dialog box, click Server Certificate on the Directory Security tab.

4. In the Welcome To The Web Server Certificate Wizard page, click Next.

5. On the Server Certificate page, click Create A New Certificate and then click Next.

6. On the Delayed Or Immediate Request page, perform one of the following and then click Next:

   • If submitting the request to an online enterprise CA on the local network, click Send The Request Immediately To An Online Certification Authority.

   • If submitting the request to a commercial CA such as VeriSign, click Prepare The Request Now, But Send It Later. This will create a PKCS#10 certificate request format file.

7. On the Name And Security Settings page, type a name for the Web site, define the bit length for the certificate encryption key, and click Next.

8. On the Organization Information page, type the organization and OU names and click Next.

9. On the Your Site s Common Name page, type the DNS fully qualified domain name (FQDN) of your Web server and click Next.

10. On the Geographical Information page, identify the Country/Region, State/Province, and City/Locality for your Web server, and click Next.

11. If you select Send The Request Immediately To An Online Certification Authority, the Choose A Certification Authority page appears. You must select an enterprise CA from the drop-down list and click Next. If you select Prepare The Request Now, But Send It Later, the Certificate Request File Name page appears. You must type the file name for the certificate request and click Next.

12. A summary page will appear that displays the naming information provided to the Web Server Certificate Request Wizard. Verify the information and click Next.

13. On the Completing The Web Server Certificate Request Wizard page, click Finish.

If you request the Web Server certificate from a commercial CA, you must submit the certificate request file to the commercial CA. Once you receive the certificate from the commercial CA, you must install it at the Web server. The Web Server certificate is installed by using the following process:

1. From Administrative Tools, open the Internet Service Manager console.

2. In the console tree, expand the NetBIOS name of the Web server, right-click Default Web Site, and click Properties.

3. In the Default Web Site Properties dialog box, click Server Certificate on the Directory Security tab.

4. In the Welcome To The Web Server Certificate Wizard page, click Next.

5. On the Pending Certificate Request page, click Process The Pending Request And Install The Certificate and then click Next.

6. On the Process A Pending Request page, provide the full path to the certificate file returned to you from the commercial CA and click Next.

7. On the Certificate Summary page, ensure that the information provided in the certificate is correct and click Next.

8. On the Completing The Web Server Certificate Request Wizard page, click Finish.

Configuring SSL

Once you have completed the installation of the Web Server certificate, you are ready to configure SSL options for the Web server. SSL configuration options are defined by clicking the Edit button in the Secure Communications section of a Web site or a virtual directory s Directory Security tab. The options that can be defined for SSL include the following:

• Choose where to implement SSL encryption.

  You can choose to enable SSL encryption for a Web site, virtual directory, or specific file at a Web site. You enable SSL by clicking the Require Secure Channel (SSL) check box. We recommend that you provide the encryption for either the entire Web site or a specific virtual directory to ensure the security of all data sent to and from a specific Web application.

• Enforce 128-bit encryption.

  This encryption level increases the encryption strength for data transmitted to and from an SSL-protected Web site. If you enable this option, all Web browsers must support 128-bit encryption. If a Web browser does not have the High Encryption Pack installed or a service pack that enables strong encryption, connection attempts to the SSL-protected Web site will fail.

• Define client certificate requirements.

  Once a Web Server certificate is installed at the Web server, you can enable certificate-based authentication. The user authenticates with the Web site by presenting a certificate from his certificate store. The Web server will associate (or map) the certificate to a user account. The possession of the private key associated with the certificate proves the user s identity. When enabled, you can choose to either accept or require client certificates for authentication.

• Enable client certificate mapping.

  If you enable the mapping of certificates to user accounts, you must enable client certificate mapping. This option allows mappings defined in Active Directory or IIS.

• Enable certificate trust lists.

  A certificate trust list defines trust for external CAs. You can limit which external certificates are trusted by determining the accepted enhanced key usages and validity periods for external certificates, as well as identifying trusted CAs.

In addition to these settings, you can define the SSL listening port for the Web site or virtual directory. By default, the Web SSL listening port is TCP port 443, but you can configure a custom SSL listening port. This is required when a Web server hosts multiple SSL-protected Web sites.