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.)
After you provide the general certificate information, the wizard asks where you want to store the certificate service data. The default location is usually fine, but make sure the location is on an NTFS volume so that you can apply appropriate security settings to the contents. After you specify a storage location, click Next. If the server is running IIS, Windows will notify you that the server must be shut down and will offer to do so for you. Click OK, and the wizard will finish the installation and restart your system.
To test the installation, use Microsoft Internet Explorer (IE) 5.0 (or another late-version browser) to request a certificate. In the browser's URL box, enter
http://localhost/certsrv
where localhost is your server's name. In the window that appears, which Figure 3 shows, choose Request a certificate, then click Next. In the next window, choose Web Browser Certificate, then click Next. Enter the information the browser prompts you for, then click the Submit button to send your request to the server.
In the server's Administrative Tools menu, choose Certification Authority to see the CA server you've set up. To finish the certificate setup, open the Pending Requests folder, which Figure 4 shows, find the request you made in your Web browser, right-click it, then select Issue. Next, in your browser, return to the http://localhost/certsrv URL, choose Check on a pending certificate, and click Next. You'll see your certificate request in the next window. Click the request, then click Install Certificate to finish the certificate setup. To confirm that your CA service is operating properly, in IE, select Internet Options from the Tools Menu, click the Content tab, then click the Certificates button to see the certificate from the Web site that you generated to test your Certificate Services installation.
After you've installed Certificate Services, you can implement the PKI services you want. PKI-enabled applications available in Win2K include IIS, IE, Microsoft Outlook, and Outlook Express. PKI also supports EFS, IP Security (IPSec), and smart cards. If you manage a large network and enable PKI, you can directly manage certificates and external CAs (i.e., servers) that users and systems will trust without the users having to get involved—a time-saver if, for example, you have a multinational company that must interact with many separate PKI CAs. In this case, using an enterprise CA would be best because it can integrate with AD and thereby offer better certificate-management features.
EFS, When NTFS Just Won't Cut It
EFS is a great addition to Win2K because it provides seamless data encryption on the server or workstation level. The Win2K EFS implementation is based on public key encryption and takes advantage of Win2K's built-in CryptoAPI design. When users encrypt files, each file receives a randomly generated file encryption key (FEK), which is different from the user's PKI-generated public and private key pair. The FEK helps limit crypto attacks that try to use various keys on the system to break into other encrypted files or areas. Like most standard encryption software, the North American EFS release currently uses 128-bit encryption, and because of export restrictions, most international releases currently use 40-bit encryption.
EFS's default setup requires no administrative effort, which greatly helps less-experienced users take advantage of this technology. When a user encrypts a file, EFS automatically generates a public key pair and an encryption certificate for that file. Decrypting the file also requires no effort because EFS automatically detects the encrypted file and finds the user's FEK in the key store. To address concerns about key loss (e.g., when a user leaves the company), EFS automatically generates data recovery keys to aid in recovering files. Keep in mind that a workstation must be a domain member and have a valid certificate before a user can access encrypted files on the server. You can use EFS on a local system that doesn't have PKI—provided that the data you want to encrypt is on an NTFS partition—but security risks exist if someone compromises your keys.
To start using EFS, after you've established PKI, create a test folder on your server. Right-click the folder, select Properties, then click Advanced. Select Encrypt contents to secure data, then click OK. The folder and any files in it are now encrypted. For individual files, the encryption method is the same; however, if the file's parent folder isn't encrypted, Win2K will ask whether you want to encrypt the parent folder. To use an encrypted file, open it as usual, and Win2K then uses the keys generated when you encrypted the file to automatically decrypt the file. You can move and copy encrypted files within Win2K NTFS drives and retain the encryption. Be aware of a small caveat to an otherwise useful service: If you copy encrypted files to a floppy disk or to a FAT or Windows NT 4.0 NTFS partition, the files will lose their encryption settings and will no longer be encrypted.
Using EFS in a domain or to restore a broad range of data requires quite a bit of management. The tasks, however, are straightforward albeit time-consuming. Managing EFS on a smaller network is a breeze, and regardless of whether you use it on one system or many, EFS can be a great addition to your network.
Go Ahead, Try PKI
PKI is a great step forward for Windows security, allowing easy certificate management and facilitating services such as EFS. With a little planning and without additional third-party software, you can implement stronger security across your network. Watch for the next installment in this series, which will cover IPSec and the benefits it brings to Win2K.
