Certificate-based authentication can add security
In "IPSec and Group Policy: A Stronger Defense," August 2002, InstantDoc ID 25730, I discuss how to apply a VPN concept within your network by using IP Security (IPSec) and Windows 2000 Group Policy to protect sensitive network traffic and computers. That article introduces a sample scenario that shows how to lock down communications with a Microsoft SQL Server machine so that only 100 authorized computers can contact the server and so that confidential SQL Server data is encrypted while traveling the network. As I explain in the previous article, you can configure IPSec to use Kerberos, preshared keys, or certificates for initial authentication, depending on your environment and the level of security you want to achieve. For the sample scenario, certificates are probably the strongest—though most complicated—choice. To implement this type of authentication, you need to set up a Certificate Authority (CA), then configure IPSec on the clients and SQL Server system to use certificates to lock down communications. To complete our secure scenario, you need to consider the other doorways into the SQL Server (i.e., ports other than 1433).
Setting Up a Dedicated Enterprise CA
First, you need to install Win2K Certificate Services and create and configure an Enterprise CA. (An Enterprise CA integrates with Active Directory—AD—and has several advantages, the most important in our sample scenario being that you can automate certificate requests and approvals for member computers in the domain. With standalone CAs, you must manually request and approve a certificate for each computer in the domain.) When you use IPSec certificate-based authentication, you limit authentication to certificates from a specific CA. Therefore, you need to use a dedicated Enterprise CA for each IPSec policy you plan to configure. In our sample scenario, you'll create a special-purpose CA to issue IPSec certificates only to the 100 computers that need to communicate with the SQL Server machine; little CA activity will occur after the initial enrollment of the authorized clients. You can use an existing Enterprise CA, so long as you don't need to issue IPSec certificates from that CA for other reasons. If you don't have an existing CA that you can use for this purpose, install Certificate Services on any Win2K server—other than the SQL Server machine—that's a member of your AD domain.
Open the Control Panel Add/Remove Programs applet. Click Add/Remove Windows Components in the applet's left-hand taskbar, then select Certificate Services. This action displays a warning that you can't rename the computer or change domains after installing Certificate Services. Click Yes to launch the Windows Components Wizard. Click Next. The wizard asks you to select the type of CA; select Enterprise root CA and click Next. Enter the appropriate identification information for the CA (we'll use SqlIPSecCA as a sample name) and your organization, then click Next.
If you already have an Enterprise root CA, consider making SqlIPSecCA a subordinate CA. In larger public key infrastructure (PKI) implementations, best practice is to build one root CA, which issues certificates only to subordinate CAs rather than to users or computers. This root CA has strong physical security and stays powered down and disconnected from the network except when needed to issue a new CA certificate. The purpose of this root CA is to help you recover if a subordinate CA's private key is compromised. You can use the root CA to revoke the subordinate CA's certificate and publish the certificate in the certificate revocation list (CRL) in AD, thus preventing anyone from trusting certificates issued by the compromised subordinate CA. Without a root CA, you'd need to update all computers manually to stop them from trusting certificates that the compromised subordinate CA signed.
Accept the default paths for SqlIPSecCA's database, click Next, then click Finish. You now have a CA that all the domain computers trust automatically.
At this point, however, any authenticated user can request certificates from SqlIPSecCA. You need to limit this ability to the SQL Server system and the Authorized SQL Server Clients group, which contains the 100 authorized computers. (I explain how to create this group in "IPSec and Group Policy: A Stronger Defense.") Open the Microsoft Management Console (MMC) Certification Authority snap-in, and open SqlIPSecCA's Properties dialog box. Go to the Security tab. Select the Authenticated Users group, then clear the Allow check box for the Enroll permission. Add the Authorized SQL Server Clients group and the SQL Server system's computer account, then select the Enroll permission's Allow check box for both (this action automatically selects the Allow check box for the Read permission as well).
Next, you need to configure SqlIPSecCA to enable it to issue certificates according to the IPSEC certificate template and prevent it from issuing certificates according to other certificate templates. (To learn more about certificate templates and automatic certificate requests, see the Web-exclusive sidebar "Certificate Templates," http://www.secadministrator.com, InstantDoc ID 26119.) Open the Certification Authority snap-in on the CA system, and select the Policy Settings folder to view a list of the certificate templates that SqlIPSecCA can issue. Right-click any empty space in the right-hand (aka details) pane, then select New, Certificate to Issue from the context menu. In the Select Certificate Template dialog box, select IPSEC and click OK to add the IPSEC certificate template to the Policy Settings folder. SqlIPSecCA needs to issue only IPSEC certificates, so delete the other certificate types from the folder. The CA will now issue certificates based on only the IPSEC certificate template.