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.