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.
The IPSEC certificate template's default ACL, however, limits enrollment to the Administrators group, a restriction you need to change. Win2K doesn't store certificate templates on each CA, but rather maintains one set of certificate templates in AD, at the domain level. All Enterprise CAs in the domain share this set of templates. To access the IPSEC certificate template's ACL, open the MMC Active Directory Sites and Services snap-in. Select View, Show Services from the menu bar. Select the Services\Public Key Services\Certificate Templates folder in the left-hand pane. Select the IPSECIntermediateOnline object in the details pane, and open the object's Properties dialog box. Go to the Security tab. Add the Authorized SQL Server Clients group, select the group, then select the Allow check box for the Enroll permission, as Figure 1 shows.
SqlIPSecCA is ready to issue IPSec certificates to any authorized SQL Server client and to the SQL Server system. Now you need to configure these authorized computers to request certificates.
Configuring Automatic Certificate Requests
First, you'll configure the authorized client computers to request certificates automatically. To do so, you need to edit the Authorized SQL Clients IPSEC Group Policy Object (GPO), which I explain how to create in "IPSec and Group Policy: A Stronger Defense." (In that article, I also explain how to link this GPO to the domain root and how to limit the Apply Group Policy permission to only the Authorized SQL Server Clients group so that Win2K will apply the GPO to only the computers in that group regardless of their location in the domain.) Open the MMC Active Directory Users and Computers snap-in. Select the domain root object and open its Properties dialog box. Go to the Group Policy tab, select the Authorized SQL Clients IPSEC GPO, then click Edit to open an MMC Group Policy console specific to the GPO. In the Group Policy console, select the Computer Configuration\Windows Settings\Security Settings\Public Key Policies\ Automatic Certificate Request Settings folder, then right-click any empty space in the details pane. Select New, Automatic Certificate Request from the context menu to start the Automatic Certificate Request Setup Wizard, then click Next. Select IPSEC for the certificate template, then click Next. Select SqlIPSecCA from the list of available CAs, click Next, then click Finish. Reboot the computers that are members of the Authorized SQL Server Clients group. (See the Web-exclusive sidebar "Group Policy Application," http://secadministrator.com, InstantDoc ID 26156, for an explanation of Win2K's method of applying these changes.)
To verify that a computer has successfully requested an IPSec certificate from SqlIPSecCA, log on to the computer as an Administrator and open a blank MMC console. Select Console, Add/Remove Snap-in from the menu bar. In the Add/Remove Snap-in dialog box, click Add to open the Add Standalone Snap-in dialog box. In that dialog box, select Certificates and click Add to open the Certificates snap-in dialog box. In that dialog box, select Computer account, then click Next. In the Select Computer dialog box, select the Local Computer: (the computer this console is running on) option, then click Finish. Click Close in the Standalone Snap-in dialog box, then click OK in the Add/Remove Snap-in dialog box. In the MMC console's left-hand pane, select Certificates (Local Computer) \Personal\Certificates. You should see a certificate, which SqlIPSecCA issued and with an intended purpose of 1.3.6.1.5.5.8.2.2, which corresponds to IPSec. (Save the new MMC console, which you'll need to use again in a few minutes.)
If the computer hasn't obtained a certificate, force a Group Policy refresh. At the computer, run the command
secedit /refreshpolicy machine_policy
Wait a minute, reopen the console, right-click the Certificates (Local Computer)\Personal\Certificates folder, and select Refresh. If you still don't see the certificate, check the Application log for events with a source of SceCli; analyze those events to determine why the automatic certificate request is failing.
Next, you need to manually request a certificate for the SQL Server system (which isn't part of the Authorized SQL Server Clients group and therefore hasn't requested a certificate automatically). Log in to the SQL Server machine as an Administrator, open a blank MMC console, and go through the process I just described to add the Certificates snap-in. In the MMC console's left-hand pane, right-click the Certificates (Local Computer)\Personal\Certificates object, then select All Tasks, Request New Certificate from the context menu to start the Certificate Request Wizard. Click Next, select IPSEC as the certificate template, then click Next again. Enter IPSEC Certificate as the friendly name, click Next, then click Finish. You'll see a message that tells you the Certificate request was successful, and a new certificate will appear in the console.
Editing the IPSec Policy
Now it's time to edit your IPSec policy. On the clients, you need to add an authentication method that permits authentication through a certificate that SqlIPSecCA issues. On the SQL Server system, you need to require authentication through a certificate that SqlIPSecCA issues. To prevent interrupted communications, you need to temporarily enable both the preshared key and certificate authentication methods on the clients and the server. (You can use multiple authentication methods in IPSec policies; Win2K tries each method in the specified order.)
First, configure the clients. Open the Active Directory Users and Computers snap-in, go to the Group Policy tab of the domain root's Properties dialog box, select the Authorized SQL Clients IPSEC GPO, then click Edit. In the Group Policy console, select the Computer Configuration\Windows Settings\Security Settings\IP Security Policies on Active Directory object. In the details pane, select the Authorized SQL Clients policy (I explain how to create and assign this policy in "IPSec and Group Policy: A Stronger Defense") and open the policy's Properties dialog box, which Figure 2 shows. Select the rule in the IP Security Rules window (you'll see only one rule), then click Edit to open the Edit Rule Properties dialog box. Go to the Authentication Methods tab. If you followed the instructions from the previous article, the preshared key authentication method will be listed on this tab. Click Add, select Use a certificate from this certificate authority (CA), then click Browse. Win2K warns you that The Active Directory does not contain a shared certificate store and asks Do you want to select a certificate authority from the local machine certificate store? Click Yes, select SqlIPSecCA's certificate in the Select Certificate dialog box, then click OK. Click OK to close the New Authentication Method Properties dialog box. Click OK to close the Edit Rule Properties dialog box, then click OK to close the Authorized SQL Clients Properties dialog box. In the Group Policy console's details pane, right-click the Authorized SQL Clients policy and select Un-assign. Right-click the policy again and select Assign. These final steps are important because Win2K won't reapply the edited policy to the GPO until you reassign the policy.
Next, configure your SQL Server machine's IPSec policy to require certificate authentication. Open the MMC Local Security Policy snap-in on your SQL Server machine, and select the IP Security Policies on Local Machine object. Open the Secure SQL Server policy's Properties dialog box, and add certificate-based authentication to the policy in the same way you added it to the Authorized SQL Clients policy. Close the policy's Properties dialog box, then unassign and reassign the policy. To force the SQL Server system to refresh Group Policy, run the command
secedit /refreshpolicy machine_policy
(Note that this command is valid on Win2K servers. If you're running Windows XP, simply run the Gpupdate command, with no parameters.) After all the SQL Server clients have applied Group Policy (which should be within 2 hours but could be delayed if some of the client computers aren't connected to the network or are down), you can reedit the GPO's and SQL Server system's policies to remove the preshared key authentication method.
Maintaining Security
Now that you've configured your SQL Server system to require certificate-based authentication, you've locked down access to the machine so that only the 100 authorized client computers can communicate with the server over TCP port 1433. No one at an unauthorized computer can send a packet to port 1433 on the SQL Server system, much less try to guess passwords, exploit SQL Serverspecific buffer overflows, or launch SQL Serverspecific Denial of Service (DoS) attacks. Additionally, traffic to and from the server over port 1433 is protected against sniffing. What are the keys to keeping this scheme secure?
In addition to implementing general domain security controls and monitoring, make sure that no one adds an inappropriate computer to the Authorized SQL Server Clients group. Such an addition would enable users of that computer to request a certificate from SqlIPSecCA.
Note also that you've protected access to the SQL Server system over only port 1433. What about other forms of communication, such as traffic that relates to administering the server remotely (i.e., through Windows terminal services, file sharing, FTP, or Telnet)? To close these doorways into the system, you need to add another rule to the SQL Server's IPSec policy. This rule will require IPSec for all traffic over ports other than TCP port 1433. Also, you need to limit that traffic to the relatively few administrators and computers that need to communicate with the SQL Server system on those ports.
To use certificates to secure such administrative traffic to the SQL Server system, you need to follow the instructions I've provided in this series to repeat the entire process for a SQL Server administrative group. (See the Web-exclusive sidebar "Secure Administrative Traffic," http://www.secadministrator.com, InstantDoc ID 26157, for details.) Creating multiple CAs just to protect one server is a significant inconvenience but is a limitation of IPSec Policies. (You can limit IPSec Policy authentication methods according to only CA name, not template name or custom field.) As an alternative, you can use preshared key authentication to restrict communications between the SQL Server system and the administrative computers. For details, see the Web-exclusive sidebar "Extend Security Through Preshared Keys" (http://www.secadministrator.com, InstantDoc ID 26120).
Choose Carefully
The key to using IPSec policies to limit network access lies in the use of authentication methods. Kerberos is useful for limiting network access to computers within a forest and requires little effort to set up because all computers within a forest automatically support Kerberos authentication. Preshared key authentication is simple to deploy and is the most flexible method because it lets you control exactly which computers within or outside of a forest can communicate with a server. However, preshared key authentication is vulnerable to key theft. Certificate-based authentication lets you limit communication to connections from certain computers within or outside of a forest but isn't very flexible because you need to maintain a different CA for each IPSec policy. The sample scenario I've presented is just one of the many ways you can use IPSec policies to increase protection within your network. Think about the important resources within your network, and consider which authentication method will work best for each.