Security Considerations for Migrating from NT to Win2K, Part 3

In "Security Considerations for Migrating from NT to Win2K, Part 2," June 2001, I discussed the basic concepts of implementing Active Directory (AD) and the great leap forward that Group Policy presents to Windows 2000 security administrators. In Part 3, let's look at public key infrastructure (PKI) and a supporting technology, Encrypting File System (EFS), and the considerations involved in implementing these great new Win2K security features.

PKI—A Key to Security
Win2K Server offers integrated support for PKI, a methodology for authenticating users and securing network communications. A detailed description of PKI is beyond the scope of this article. Let's look at the basics of implementing and configuring PKI in Win2K. For more information about PKI and Win2K's PKI features, see Randy Franklin Smith's Windows 2000 Magazine article, "Windows 2000 Security Gains," http://www.win2000mag.com, InstantDoc ID 7434 and Tao Zhou's Windows 2000 Magazine article, "Public Key Infrastructure in Windows 2000," http://www.win2000mag.com, InstantDoc ID 4691.

Getting Started with PKI
To get the ball rolling with PKI, simply install Win2K Certificate Services. On a Win2K Server machine, go to the Control Panel Add/Remove Programs applet, click the Add/Remove Windows Components button, select Certificate Services, then click Next. After copying files (your Win2K Server CD-ROM might be necessary during this step), Windows automatically launches the Windows Components Wizard, which presents you with a screen (which Figure 1 shows) offering four Certification Authority (CA) choices:

• Enterprise root CA—Use this option if you need to issue certificates to individual users and computers in your domain. This option requires AD and DNS.
• Enterprise subordinate CA—Use this option if this CA will be subordinate to another enterprise root CA elsewhere in the network. The option requires AD, DNS, and a parent CA, which can be an external commercial CA or a standalone CA.
• Stand-alone root CA—Use this option if all you need to do is issue certificates outside your network (e.g., for a Web site) or if you want to enable certificates for another service, such as e-mail encryption. This option is the quickest to set up, requiring only administrative access to the system.
• Stand-alone subordinate CA—Use this option as a backup CA or an additional CA server. This option's requirements are the same as the stand-alone root CA option's requirements, but the stand-alone subordinate CA option requires association with a CA that can process the requests sent by this server.

For this article, I use the stand-alone root CA option, which is handy because you gain some of the benefits of a certificate service (e.g., Web site certificates), but you don't need AD installed on your network. However, if you use an enterprise CA, you gain automated features that reduce administrative tasks. For example, features such as automatic data entry in the certificate fields and automatic authorization of certificate requests can help cut down on administrative tasks when you have a CA that handles a large number of requests.

On the wizard screen that Figure 1 shows, when you select the Advanced options check box and click Next, you'll see the screen that Figure 2 shows. Here, you can set the type of cryptography your PKI will support and the cipher length of the keys (1024 is the minimum recommended). Options for 2048 or 4096 cipher length are available, but I don't recommend going higher than 2048 because most Web browsers don't support anything higher than that and might therefore interfere with your users' access to secure areas.

Next, the wizard asks for general information for the server certificate, such as your company name and location. The certificate is intended to guarantee that the system is what it says it is. However, although self-signed certificates work fine, imposters can easily duplicate them. If you plan to use a self-signed certificate on a server running Microsoft IIS (e.g., for a Web site), you should obtain a certificate from a reputable service, such as VeriSign. However, even if you use a third-party service, be aware that such certificates aren't foolproof. As you probably saw in the news headlines earlier this year, someone obtained a Microsoft-labeled certificate from VeriSign under false pretenses. (If you use a third-party certificate, you'll need to perform an additional step after the wizard closes. Right-click the certificate file, then select Install Certificate. The system then installs the certificate into the CA.)