Over the past several weeks, I’ve discussed Windows 2000's Certificate Services and how you can use the feature to build a public key infrastructure (PKI). I've also described how to configure a Web server to use Secure Sockets Layer (SSL) and how to use certificates to perform client authentication. If you’ve been following this series, you know that implementing PKI requires a lot of planning and work. Much of the work involves configuring server and client applications, as I demonstrated in my discussion about enabling SSL on Microsoft IIS 5.0 and Internet Explorer (IE) 5.0. To wrap up this series, I'll highlight a few Win2K services and applications that PKI can benefit.
Using PKI to Secure Email
Companies often transmit some of their most sensitive information via email, a practice that can be especially risky if you use a Web-based email client. Fortunately, you can protect such email at two levels: at the Outlook Web Access (OWA) server and at the client Web browser. To protect your OWA server, use the Microsoft Management Console (MMC) Internet Services Manager (ISM) snap-in to enable SSL on the Exchange virtual directory, as I described in my April 16 column. If you configure the Web server to require a secure channel when it accesses the Exchange directory, you make it very difficult for anyone to sniff and read email messages when users check mail remotely because the Web server’s public key encrypts all traffic. To protect email at the client level, use the Exchange 2000 Key Management Server (KMS) to issue certificates to users so that they can encrypt and sign messages themselves. KMS uses Win2K’s Certificate Services to produce digital certificates. Within Outlook, users specify whether they will encrypt email, which protects the contents, or sign it, which authenticates your indentify
EFS and Certificate Services
Although Encrypting File System (EFS) can function without Certificate Services, having a PKI can improve EFS manageability and recoverability. Whenever a user encrypts a file, the system saves the key with the file in two ways—once with the user’s key and a second time with the designated recovery agent’s key (by default, the built-in Administrator account is the designated recovery agent). This encryption scheme ensures that you can recover a file even if a user leaves the company. If you install an enterprise, you can issue file recovery certificates to additional user accounts. You can then use Group Policy to specify these users as recovery agents for individual Organizational Units (OUs) or for the entire domain, depending on the Group Policy Object (GPO) you’re editing.
Smart Cards and Certificate Services
You can also use Certificate Services to support smart-card technology, which Microsoft built into Win2K. Smart cards store the certificate and key that your system presents to Active Directory (AD) so that you don't have to enter the usual username and password. When you log on, AD prompts you for a PIN, much like the ATM at your bank does. You need an enterprise Certificate Authority (CA) to issue smart-card certificates. By default, users don’t have access to the smart-card certificate template, which means that they can't simply request their own certificates and sign up for smart-card authentication. Enrollment for a smart-card certificate should be a controlled procedure, similar to the process many companies use to issue employee identification badges. To help you establish this controlled procedure, enterprise CAs support an "enroll-on-behalf-of" feature that lets you request a certificate for a new user and map the certificate automatically.
Certificates and IPSec
Win2K's IP Security (IPSec) is an excellent method for encrypting any network traffic, regardless of the client or server application you use. When establishing an IPSec network session, the machines involved in the transaction authenticate using Kerberos, certificates, or a shared secret (i.e., a password). Kerberos authentication is an option only if both machines are members of the same AD forest, and shared-secret authentication isn't scalable or secure. As long as both machines have a common root CA in their IPSec policy configuration, you can use certificate authentication to provide a secure solution—even for communication that occurs among AD forests.
As you can see, PKI has many uses on a Win2K network. If you'd like me to cover any of these uses in more detail, post a comment in response to this article or email me.
