Open the Local Security Policy snap-in on the SQL Server system. Right-click the Secure SQL Server policy (under the IP Security Policies on Local Machine object), then select Unassign so that you won't interrupt communications with clients.
Open the policy's Properties dialog box. On the Rules tab, select the SQL Server Traffic (port 1433) rule from the IP Security Rules list, then click Edit to open the Edit Rule Properties dialog box. Go to the Authentication Methods tab and remove the Kerberos entry. Click Add. On the New Authentication Method Properties dialog box, select the Use this string to protect the key exchange (preshared key) option and enter a string of numbers, symbols, and letters at least 20 characters long. Make a note of this string, then click OK three times to close all the dialog boxes.
Next, open the Active Directory Users and Computers snap-in and open the domain's Properties dialog box. Go to the Group Policy tab, select Authorized SQL Clients IPSEC, then click Edit. Select the Computer Configuration\Windows Settings\Security Settings\IP Security Policies on Active Directory object. The Client (Respond Only) policy is assigned. The simplest way to change this assignment is to edit the policy and add a new authentication method. However, I don't recommend this approach because GPOs share IPSec policies. If you use a given IPSec policy, such as Client (Respond Only), in more than one GPO and you change the policy, those changes will take effect in all the GPOs to which you've assigned the policy. Instead, right-click a blank area in the details pane and select Create IP Security Policy from the context menu to launch the IP Security Policy Wizard. Click Next, name the new policy Authorized SQL Clients, then click Next. Select the Activate the default response rule check box, then click Next. Select Use this string to protect the key exchange (preshared key), then enter the same key you entered for the Secure SQL Server policy, as Figure 3 shows. Click Next, then click Finish. Click OK to close the Properties dialog box. Right-click the new policy, then select Assign from the context menu; this action also unassigns the Client (Respond Only) policy.
Wait at least 2 hours for all the clients to reapply Group Policy. After 2 hours, you can reassign the policy on the SQL Server system. At that point, no computer will be able to connect to your SQL Server system unless that computer is a member of the Authorized SQL Server Clients group.
The Next Step
Preshared key authentication also has some weaknesses. Preshared keys are stored in clear text in the registry and are therefore subject to compromise. Also, you've protected only port 1433. What about other ports that an attacker could target, such as those associated with the Server service or Windows Terminal Services? For this sample scenario, the strongest authentication option—albeit the most complicated—is certificates. In a follow-up article, I'll show you how to set up a Certificate Authority (CA) and configure IPSec to use it to lock down access to our sample SQL Server system. I'll also shed more light on sequencing changes to IPSec to make sure you don't temporarily interrupt communications while Win2K applies Group Policy throughout your domain. Until then, examine your network and consider other ways in which you can use IPSec to erect defenses behind your firewall. After all, to secure an office building, you don't just lock the front door, you also lock the offices that contain crucial equipment to protect against malicious insiders as well as outsiders who make it past your front door. Likewise, don't give up your whole network just because someone makes it through your firewall—use IPSec to limit communication with your mission-critical servers.
End of Article
Prev. page
1
2
[3]
next page -->
