Secure IIS with Certificates

Protect your Web sites with certificates and SSL

Microsoft Internet Information Services (IIS) 5.0 is an extremely scalable, robust, and versatile platform for building both intranet and Internet Web sites. Like most Web servers, it can serve up both static and dynamic Web pages and provide secure communications by using the Secure Sockets Layer (SSL) protocol. Unlike many other Web servers, IIS can leverage the security features of Windows 2000 to authenticate users and authorize their access to content in a fashion that requires no work for the Web developer. One of those security features is the built-in support for certificates. You can issue certificates to both Web servers and end users to effectively enhance and maintain security.

Authenticating Users
Web developers commonly build a database, Web pages, and scripts for the purpose of authenticating users. These items work together to request that users enter their usernames and passwords. A script looks up the username in a database table that contains details about users, including their passwords. If the script finds a matching username, it compares the password the user entered with the password in the table. (If the table stores only hashed passwords for security reasons, a script must hash the password the user entered before comparing it with the one in the table). If the passwords match, the user is considered authenticated. Building your own system to authenticate users becomes more complex when the site must let users manage their accounts or must authorize users before letting them view content. A developer might spend many days or weeks writing complex pages and scripts. One very real danger is that bugs can slip through testing and an intruder can exploit those bugs to bypass the authentication or authorization mechanisms.

With Win2K and IIS, the developer doesn't need to worry about developing authentication and authorization code. In its default configuration, IIS accepts both Anonymous and Integrated Windows authenticated connections, as Figure 1 shows. For Anonymous connections, IIS reads pages and executes scripts within the security context of the IUSR_machinename account (by default) or another Windows user account that you specify, as Figure 2 shows. When the specified account has access to the content the user wants to browse, the server won't require the user to authenticate. When the user attempts to access pages for which the specified account isn't authorized, IIS will require authentication. IIS 5.0 can authenticate a user with Basic authentication, Digest authentication, Integrated Windows authentication, and client-certificate mapping. Each of these methods has benefits and drawbacks, which Table 1 summarizes.

In a homogeneous environment in which all clients and servers run Windows and Microsoft Internet Explorer (IE), you can safely rely on Integrated Windows authentication. In a heterogeneous environment (i.e., one in which the clients run OSs and browsers from multiple vendors), you'll have to choose authentication methods that the clients support. (IIS can support multiple authentication techniques simultaneously.) I concentrate on Basic authentication and client certificate mapping in the remainder of this article because these methods offer the best cross-platform support.

Regardless of the authentication type you choose, users must have a valid Windows account to be authenticated. This requirement causes many developers to implement custom authentication mechanism out of a fear that users with Windows accounts could somehow be a security threat or that Active Directory (AD) can't scale to support a large number of users. The reality is that a well-planned and well-managed environment that includes appropriate precautions has no appreciable security exposures, and AD can scale to accommodate the demands of even the busiest Web site. Using Windows authentication mechanisms makes enforcing security easier because the developer doesn't need to code usernames and passwords into scripts. This advantage applies even to multi-tier Web architectures with application and database servers because the Web server can delegate user security contexts to those systems.

Authorizing Access to Content
You can protect IIS content by setting entries in the ACLs that protect the pages, scripts, and executables stored in the file system. (Note that this feature is available only with NTFS.) When a user accesses a site anonymously and attempts to access content to which the Anonymous account doesn't have permission, IIS attempts to authenticate the user in an exchange with the user's browser. If you've configured IIS to request Basic or Digest authentication, the user will be prompted to supply credentials such as a username, domain, and password. Other authentication methods use the credentials that users supplied when they logged on to their workstation or a certificate in the users' profile. IIS receives the credentials and uses native mechanisms in Win2K to authenticate the user. When the user is authenticated, a token is created for the user, which contains (among other information) his or her SID and the SIDs for the groups of which the user is a member. IIS compares SIDs in the token against the entries in the ACL to determine whether the user is authorized to view the content or run the scripts or executables.

If a user repeatedly fails to provide credentials that have the necessary permissions to access the restricted content, IIS returns an Access Denied error page. You can also set permissions in databases such as Microsoft SQL Server and on objects accessed from dynamic Web pages to authorize users for specific data and actions. IIS delegates the user's security context to these resources.

Securing the Authentication Process
The first step in securing any authentication process is configuring the logon privileges granted to the user accounts that visitors to your Web site use. The logon privileges that you can grant to a user account are Access this computer from the network, Log on as a batch job, Log on as a service, and Log on locally. Win2K introduced the deny privileges Deny access to this computer from the network, Deny logon as a batch job, Deny logon as a service, and Deny logon locally.

Assuming that your Web server is a member of a domain and that all users have accounts in AD, users who access your Web site need only the Access this computer from the network privilege. Rather than grant the privilege to individual user accounts, you can create a group, grant the group this privilege, and make all Web site users members of the group. For Basic authentication to work correctly for user or group accounts with this privilege, you need to set the LogonMethod property in the IIS metabase. The default property setting directs IIS to attempt an interactive logon; the new setting directs IIS to attempt a network logon. Simply create a file called setauth.vbs that contains the code that Listing 1 shows (replacing webserver with the name of your Web server), then type

cscript setauth.vbs

at a command prompt.

If you use Basic authentication to authenticate your users, you should install a server certificate to enable SSL. Without SSL to encrypt communications between browsers and your Web site, users' credentials are vulnerable to packet sniffers and monitoring software. If you use client certificates to authenticate users, you must obtain a server certificate because it's used during the authentication process. You can obtain a server certificate from a Certification Authority (CA) such as VeriSign or Thawte or from your own CA, if you have one in your organization. For information about using Microsoft Certificate Services to set up a CA, see "Securing Win2K with Certificate Services," September 2001, InstantDoc ID 22113.

To obtain a server certificate, open the Microsoft Management Console (MMC) Internet Information Services snap-in. Right-click the Web site for which you want to request a certificate, and select Properties. In the Properties dialog box, click the Directory Security tab, click Server Certificate to start the IIS Certificate Wizard, and click Next on the opening page of the wizard. Ensure that the Create a new certificate option is selected, and click Next. Decide whether to prepare the certificate request now and send it later or send the request immediately to a CA on your network, then click Next. In the wizard's Name and Security Settings dialog box, which Figure 3 shows, enter a name for the certificate and the size of the key to use to encrypt communications. When you select a key size, remember that the longer the key, the more secure communications will be but the longer each encryption and decryption will take. Click Next.

At the next wizard screen, enter the name of the IIS server. If the server is on the Internet, you should enter the Fully Qualified Domain Name (FQDN). If the server is an intranet server, you can enter its NetBIOS name. When users use SSL to connect to your site, their browsers will check the name of the server in the URL that the user typed against the name of the server in the certificate. If the names don't match, the browsers will typically display a warning.

If you chose to send the certificate request immediately, you'll see a list of CAs on your network. Select the most appropriate one. If the request is successful, the wizard automatically installs the certificate. If you chose to create a certificate request to submit at a later date, the wizard prompts you for the name of the file to which it should save the request. After you submit your request and receive your certificate, you can use the IIS Certificate Wizard to install it.

Installing a certificate on a Web site doesn't automatically make the site secure or protect user credentials exchanged using Basic authentication. When you use Basic authentication, all communication between the user's browser and the Web site should take place over an SSL connection. Many Web developers use HTTP over Secure Sockets Layer (HTTPS) for connections over which the user will be authenticated or will access restricted content, but the developers make the mistake of reverting to plain HTTP for subsequent connections. This practice is dangerous because the browser continues to send the user's credentials with every page request the user makes until the session ends or until the Web site requires the user to authenticate with different credentials. A quick step that administrators can take to ensure that SSL is always employed on their Web sites is to select the Require secure channel (SSL) check box in the Secure Communications dialog box, as Figure 4 shows. However, if you select this option, users will be able to connect to your Web site only if they type the https:// prefix in the URL.

Using Client Certificate Mapping
Rather than requiring users to enter usernames and passwords to authenticate each time they access restricted content, you can use client certificates to supply authentication information. Many users might already have certificates for securing email, and you can often use these certificates to authenticate users to Web servers. A CA in your organization needn't have issued these certificates; you can map certificates that other CAs have issued to user accounts.

To enable IIS to accept client certificates, open a Web site's Properties dialog box and click the Directory Security tab. In the Secure communications section, click Edit. In the Secure Communications dialog box, select Require secure channel (SSL) as mentioned earlier, Require client certificates, Enable client certificate mapping, and Enable certificate trust list. You can also opt to require 128-bit SSL encryption. Use the New and Edit buttons under the Current CTL drop-down list (CTL stands for certificate trust list) to add a copy of the certificate for each CA that issues certificates to your Web site users. Because you must map certificates to user accounts before those certificates can be used for authentication, trusting a CA doesn't mean that every user with a certificate from that CA can log on to your system.

IIS supports two types of client-certificate mapping. The legacy mode introduced in Internet Information Server (IIS) 4.0 lets you map certificates to specific user accounts manually. The advantage of this mode is that you can use certificates from multiple CAs and map those certificates to any account you choose. You can also map multiple certificates to a single account. You create the mappings by using the Account Mappings dialog box, which appears when you click Edit in the Secure Communications dialog box's Enable client certificate mapping section. Unfortunately, this mode of operation becomes unwieldy when you work with many certificates and user accounts.

The second type of client-certificate mapping lets you instruct IIS to map the client certificates that an enterprise CA issues to user accounts in AD. To use this mode of operation, open the Internet Information Services snap-in, right-click the Web server (not a Web site), and select Properties. From the Master Properties menu, select WWW Service, click Edit, and select the Directory Security tab. Select Enable the Windows directory service mapper, as Figure 5 shows. The advantages of this mode include scalability and some automated management features: As the enterprise CA issues user certificates, they're stored automatically in AD. You don't need to manually load and manage the certificates, and when users renew their certificates, you don't need to update the mappings. Note that the two types of client-certificate mapping are mutually exclusive in IIS, so you must choose your scheme with care.

When a user connects to a Web site that requires client certificates, the user's browser displays a dialog box that contains a list of the user's valid certificates, as Figure 6 shows. The user can select which certificate to use to authenticate (the browser will remember which certificate to use for the remainder of the session). If the certificate is stored on a smart card, the user will be prompted to enter his or her smart card PIN. Note that Figure 6 shows multiple certificates with the same name. A user with multiple certificates must select a certificate and click View Certificate to determine which certificate to use.

Managing Certificates
When using certificates, you need to have a management process in place for them. As part of their security mechanism, certificates expire and need to be renewed, so you must remember to request and install a new server certificate before the old one expires. You also need to replace expired and revoked client certificates if your Web site uses the legacy-mapping mode.

When managing a Web site that has restricted content, routinely monitor the types of requests the server receives to ensure that communications take place over SSL when requests include authentication information and when sensitive information is being returned to the user. Note that you might need a packet sniffer or Network Monitor (which ships with Win2K) for this type of monitoring.

Of course, you should also install the latest service pack and hotfixes on your Web servers and lock down your servers. For information about locking down a Web site, see Andrey Kruchkov, "Secure Web Server Installation on Win2K," October 2001, InstantDoc ID 22365, and check out Microsoft's security Web site at http://www.microsoft.com/security for the latest bulletins, tools, checklists, and best practices.

Microsoft's Internet Information Services 5.0 Resource Guide, part of the Microsoft Windows 2000 Server Resource Kit, is required reading for Web site administrators. Another good book I recommend to both developers and administrators is Michael Howard's Designing Secure Web-Based Applications for Microsoft Windows 2000 (Microsoft Press, 2000). The Microsoft Developer Network (MSDN) Web site (http://msdn.microsoft.com) also contains a wealth of information about developing and securing Web sites.