Click Next to advance to the wizard's IP Filter List screen. A filter list contains one or more filters that you configure to catch specific types of traffic and to handle that traffic according to actions that you specify. Click Add to open the IP Filter List dialog box. In the Name box, enter SQL Server Traffic (port 1433), then click Add to launch the IP Filter Wizard. Click Next, then select Any IP Address from the Source address drop-down list. Click Next, then select My IP Address from the Destination address drop-down list. Click Next, select TCP from the Select a protocol type drop-down list, then click Next again. Select the To this port option and enter 1433 in the text box. Click Next, clear the Edit properties check box, then click Finish to return to the IP Filter List dialog box, which will now look like the dialog box that Figure 1 shows. Click Close. On the Security Rule Wizard's IP Filter List screen, select SQL Server Traffic (port 1433), then click Next to advance to the Filter Action screen.
You're now ready to select an action. The prebuilt filter actions won't suffice because none of them make ESP mandatory; therefore, you need to create a custom action. On the Security Rules Wizard's Filter Action screen, click Add to launch the Filter Action Wizard. Click Next. Enter a name such as Require ESP Mode, then click Next. On the Filter Action General Options screen, select the Negotiate security option, then click next. Select Do not communicate with computers that do not support IPSec, then click Next. On the IP Traffic Security screen, select the High (Encapsulated Security Payload) option, click Next, then click Finish to return to the Security Rule Wizard's Filter Action screen. Select Require ESP Mode, click Next, then click Finish. On the Secure SQL Server Properties dialog box, clear the selected SQL Server Traffic (port 1433) check box, then click Close.
You've created the Secure SQL Server policy, but don't assign it yet. Doing so would immediately prevent clients from communicating with the server because you haven't yet configured the clients for IPSec.
Configuring the Clients
To configure the 100 client computers, you need to create a group, add the client computers to the group, create a Group Policy Object (GPO) in AD, and modify the GPO's ACL to give the Read and Apply Group Policy permissions only to members of the new group. After you configure the GPO and enable IPSec for the GPO, and after the client computers apply the GPO, they'll be able to communicate with the SQL Server system. (Other systems will be shut out after you activate the policy on the SQL Server machine.)
Open the MMC Active Directory Users and Computers snap-in, and select the domain root or organizational unit (OU) in which you want to create the group. Select Action, New, Group from the menu bar. Enter Authorized SQL Server Clients in the Group name text box, click Next, then click Finish. Open the new group's Properties dialog box, and go to the Members tab. Add the 100 client computers to the group as members, then click OK.
Now you're ready to create the GPO. Open the domain's Properties dialog box and go to the Group Policy tab. Click New to create a new GPO in the Group Policy Object Links list. Name the GPO Authorized SQL Clients IPSEC.
Typically, when you link a GPO to a domain root, Win2K applies that GPO to all the computers and users in the domain. However, you want the IPSec policy in this new GPO to apply only to the 100 or so computers that are authorized SQL Server clients. You could create a new OU to hold those computers, then link the GPO to the OU—thus limiting application of the GPO. But the SQL Server client computers are already scattered throughout existing OUs. Other GPOs link to these OUs and supply other important policies for the computers. Therefore, you need another way to limit the new GPO to the appropriate computers. The solution is to modify the GPO's ACL.
Open the GPO's Properties dialog box and go to the Security tab. This tab displays the GPO's ACL, which controls who can edit the GPO and provides a way to limit the computers or users to which the GPO applies. Notice that the default ACL grants the Read and Apply Group Policy permissions to the Authenticated Users group. Select that group, then click Remove. Click Add, select the Authorized SQL Server Clients group, click Add again, then click OK. Select the group, then select the Read and Apply Group Policy permissions, as Figure 2 shows. Click OK to close the Authorized SQL Clients IPSEC Properties dialog box. Now, the GPO will apply only to computers that are members of the Authorized SQL Server Clients group even though you've linked this GPO to the domain root.
You now need to configure an IPSec policy for the GPO. On the Group Policy tab of the domain's Properties dialog box, select Authorized SQL Clients IPSEC, then click Edit. Select Computer Configuration\Windows Settings\Security Settings\IP Security Policies on Active Directory. Right-click Client (Respond Only) in the details pane, then select Assign from the context menu. This prebuilt policy causes a Win2K computer to acquiesce when it tries to communicate with another computer that requests IPSec negotiation. Wait at least 2 hours for all the clients to update Group Policy. (By default, Win2K computers reapply Group Policy every 90 minutes, with a random offset of up to 30 minutes.)
You can now activate the Secure SQL Server policy on your SQL Server system. To do so, open the Local Security Policy snap-in on the SQL Server system, right-click the policy (under IPSec Policies on Local Machine), then select Assign from the context menu. Now, only authorized computers can connect to port 1433 on your SQL Server system, and IPSec will encrypt traffic on that port as it traverses the network.
Authentication Alternatives
As I mentioned earlier, for our sample scenario (in which we're limiting the computers within a forest that can communicate with one another) Kerberos authorization is often the simplest—but not the strongest—option. When you use Kerberos, anyone with Administrator access to a computer in the forest need only assign the Client (Respond Only) policy on that computer to attack the SQL Server system through port 1433. In such a scenario, preshared key authentication is a better alternative than Kerberos. To use preshared key authentication, you need to configure both the server and client IPSec policies with a secret key.
Prev. page
1
[2]
3
next page 
