In my last column, I explained how to use Windows 2000 Certificate Services and Microsoft IIS 5.0 to create a Secure Sockets Layer (SSL) -enabled Web site. SSL includes a client-authentication component, but SSL is most often implemented with the server-side component, which serves only to verify a Web site’s identity and enable secure communications between the client and the server. If your site’s data is critical, you might want to go beyond SSL’s server-authentication capabilities and limit access to specific clients. Let’s look at how Certificate Services and SSL let you limit access in a way that’s both secure and user-friendly.
Background: IIS Access Control
In Win2K and NT 4.0, the system grants file access to user accounts and to groups that contain user accounts. Because a Win2K Web server is essentially a file server that uses the HTTP protocol, the same access principle applies to IIS: Users can access HTML files on a Web server if their user account has the appropriate permissions. From an access-control perspective, this is a good model, but it can cause problems in the Internet world. To prevent problems, IIS supports anonymous access, which lets users access Web content without a username and password. When you enable anonymous access, users browsing your site can access any of the files that the Anonymous User Account has permission to access. When you install IIS, the system creates the Anonymous User Account and gives it the name IUSR_Computer_Name.
IIS also supports Basic, Digest, and Integrated Windows Authentication methods, which let you limit access to Web content to particular users. You configure NTFS permissions on the directories or files that you want to protect so that only certain users—not IUSR_Computer_Name account users—have access. Unlike anonymous access, all three of these authentication methods require that the user have a valid Win2K user account to present to the Web server on request. Although these methods can provide access control, the methods require that users remember and enter a username and password, and this sensitive information often travels over an insecure network (the Internet).
Client Certificate Authentication
Client certificates help eliminate the potential drawbacks of IIS authentication methods. Digital certificates become the credentials that identify a user to the Web server, which means that the user doesn’t have to remember multiple usernames and passwords and that information doesn’t travel over the Internet. To enable certificate authentication, you must configure the Web server to request the certificate from the client Web browser and then map certificates to user accounts. Certificate authentication requires that your Web site have a server certificate. (For more information about obtaining a certificate, see Securing Web Communications with SSL.)
To configure the Web server, open the Microsoft Management Console (MMC) IIS snap-in, and right-click the Web site or the directory that you want to protect. Open the properties for the site or directory, select the Directory Security page, and under Secure Communications, click Edit. On the dialog box that appears, check Require Secure Channel (SSL), and click either Accept Client Certificates or Require Client Certificates, depending on your needs. To ensure that not just anyone with a certificate can connect, you must enable Basic, Digest, or Integrated Windows Authentication. Go to the Directory Security page and, under Authentication Control, choose Edit to enable authentication.
Mapping Certificates to User Accounts
IIS requires mappings so that your Web server knows which user account corresponds to each certificate that it receives. In Win2K, you can enable mapping through Active Directory (AD), or you can use IIS 5.0's native mapping.
Directory Service mapping. Directory Service (DS) mapping checks AD to verify that the certificate belongs to a valid user and to verify that you have granted the user access to the Web site or directory. DS mapping is available only if your Web server is a member of a Win2K domain, and you must enable the feature at the master properties level. To access the Web master properties, right-click server name in the MMC IIS snap-in, choose Properties, and click Edit. On the master Directory Security page that appears, verify that DS mapping is enabled. To configure mappings in AD, open AD Users and Computers, click View, and check Advanced Features. Next, right-click the account that you want to establish a mapping for, and choose Name Mappings.
IIS mapping. If your Web server isn't a member of a domain, you can use IIS 5.0's native mapping. One advantage of IIS mapping is that it lets you use one-to-one mapping (as with DS mapping) or many-to-one mapping. Many-to-one mapping uses wildcards to specify that a certificate meets certain criteria (e.g., that a specific Certificate Authority—CA—issued the certificate). This feature can greatly reduce the amount of overhead required to configure client certificate authentication.
Of course, before you can use DS mapping or IIS mapping to associate certificates with user accounts, you must issue the user a certificate. If you use Win2K Certificate Services, users can request a certificate by pointing their browsers at http://certificate_servername/certsrv and following the instructions to request a user certificate. As you can see, configuring certificate authentication requires some effort, but the result can provide a very scalable and secure solution.
