The wizard's next step prompts you to specify whether you want the policy to respond to requests to secure communications. Select the Activate the default response rule check box to configure the stations to respond to, but not initiate, such requests. Click Next.
The next screen, which Figure 3, page 10, shows, prompts you to specify the rule's initial authentication method: Kerberos, a certificate, or a preshared key. (For an explanation of IPSec's authentication process, see the Web-exclusive sidebar "Using IPSec to Secure Communications," InstantDoc ID 23446.) Kerberos is the default method and will work for most organizations. Kerberos won't work when your stations need to communicate with Win2K servers on domains with which no trust relationship has been established, or when you want your stations to communicate with servers running other OSs, such as FreeBSD or Sun Microsystems' Solaris. If your servers run a mix of Win2K and other OSs, select Kerberos—you can add alternative authentication methods later. Click Next to advance to the final screen, which confirms that you've created the policy. You need to edit your new policy to ensure secure communications, so confirm that the Edit properties check box is selected before you click Finish.
When you click Finish, the new station policy's Properties dialog box opens automatically. Go to the Security Methods tab, select the sole entry (for Default Response) in the IP Security Rules section, then click Edit to open the Edit Rule Properties dialog box. I suggest you remove the final four entries and keep only the two entries that list 3DES in the ESP Confidentiality column. (To remove an entry, select it and click Remove, then click Yes when prompted to confirm your action.) Next, go to the Connection Type tab and select Local Area Network (LAN). If you run a mix of OSs and need to add alternative authentication methods, go to the Authentication Methods tab and select the option to use certificates or the option to use preshared keys, enter the required information, then click OK. To save and close the policy, click OK, then click Close in the Edit Rule Properties dialog box.
The policy now appears in the right pane of the Group Policy console but doesn't go into force until you assign it. To do so, right-click the policy, then select Assign from the context menu. Win2K will apply the policy to the stations during the next Group Policy refresh.
Creating a Server Policy
Your next step is to create your server policy. Open the Active Directory Users and Computers snap-in and select the OU that contains the servers' Computer accounts. (If you created more than one OU for this purpose, repeat the following process for each OU.) Open the OU's Properties dialog box and go to the Group Policy tab. Create a new GPO to contain the server IPSec policy.
Follow the steps I described earlier to launch the IP Security Policy Wizard. Step through the wizard, naming this new policy to reflect that it applies to your servers. Because you're applying this rule to your Win2K servers, accept the wizard's default Kerberos authentication method. Complete the wizard (ensure that the Edit properties check box is selected on the final screen).
The new server policy's Properties dialog box opens automatically. This time, you'll use the dialog box to specify new rules for communicating with wireless stations. Click Add to launch the Security Rule Wizard, which guides you through the creation of a new rule. First, the wizard asks whether the rule is for a tunnel. Select the This rule does not specify a tunnel option and click Next. The wizard then asks which connections this rule will apply to. Select the Local Area Network (LAN) option and click Next. When the wizard prompts you to specify the type of authentication, accept the Kerberos default and click Next.
The wizard then prompts you to select or add an IP filter. The IP filter list, which Figure 4 shows, can contain several entries, depending on whether you've configured or used IPSec in the past. (For information about how IPSec uses IP filters, see the Web-exclusive sidebar "Using IPSec to Secure Communications.") Click Add to open the IP Filter List dialog box and create a new filter. Enter a name and a description for the new filter. (I recommend you clearly identify the filter as being for WLAN communications so that you can identify it easily if you need to edit it or create new filters in the future.) Click Add to launch the IP Filter Wizard, which you use to build a filter rule that will apply to traffic to or from your wireless stations.
The IP Filter Wizard first prompts you to select the source IP address. Select My IP Address from the drop-down list, then click Next. The next screen prompts you to select the destination IP address. Select A specific IP Subnet from the drop-down list; two edit controls appear. Enter the IP address of the subnet on which you placed your wireless stations, then enter the Subnet mask, then click Next. The wizard next prompts you to specify which IP protocols to secure. Accept the default of Any to secure all communications between your servers and stations. Click Next, then click Finish on the wizard's final screen.
Your new filter rule appears in the IP Filter List dialog box, which Figure 5 shows. Click Close to return to the Security Rule Wizard's IP Filter List screen, select the new IP filter list, then click Next. The wizard prompts you to specify which actions should occur when your rule fires. This screen displays at least three options (possibly more if you've configured IPSec previously). Select Require Security. Click Next to proceed to the Security Rule Wizard's final screen. Ensure that the Edit properties check box is selected, then click Finish.
The New Rule Properties dialog box opens automatically. Go to the Connection Type tab, select Local area network (LAN), then click OK. This action returns you to your server policy's Properties dialog box. Click Close to save the policy, then apply the policy as I described earlier. After Group Policy is refreshed and the new IPSec policy applied to your servers, your WLAN communications will be secured.
Troubleshooting IPSec
Troubleshooting IPSec can be difficult. If you can't establish communication between a wireless station and a server, first determine whether each end system can communicate with other systems to which your IPSec rules apply and with systems to which the rules don't apply. If only one system appears to have problems, check the obvious causes (e.g., network connection, router, switch, hub, NIC).
If you still can't pinpoint the problem, you can use Win2K's IPSec Monitor (ipsecmon.exe) utility to determine whether the systems have established a Phase II security association (SA—see the Web-exclusive sidebar "Using IPSec to Secure Communications" for information about Phase II SAs). If not, and if the affected systems can communicate with systems that don't require IPSec, the problem probably lies with a Group Policy or an IPSec policy on one of the end systems. You can use Win2K Server's Network Monitor to confirm IPSec negotiation between the end systems. If the end systems negotiate but the negotiation ultimately fails, examine your policies in detail and look for any mistakes (e.g., typing errors) you might have made during their creation. (When you use Network Monitor, you might be surprised to see some unencrypted traffic between your end systems. For information about this traffic, see the Web-exclusive sidebar "Communications That IPSec Doesn't Secure," InstantDoc ID 23447.)
Another common problem occurs when Win2K fails to distribute your station policy to a wireless system before that system attempts to communicate with a server. If you require your DCs to establish secure communications with wireless stations, and if Win2K applied that policy to the DCs before completely distributing the station policy to all your stations, then the stations can't obtain the station policy. In this case, you need to create the policy manually on the wireless station to bootstrap the process. If you didn't apply the server policy to your DCs, check Group Policy to make sure that IPSec policy processing hasn't been disabled, and explicitly enable such processing if necessary. (To enable processing, open the GPO you created to hold the server IPSec policy, then click Edit. In the Group Policy window, drill down to Computer Configuration, Administrative Templates, System, Group Policy. Select and right-click IP Security policy processing in the right pane. Select Properties from the context menu, then go to the Properties dialog box's Policy tab. Select the Enabled option.) You can also review each station's Application log to ensure that the GPO has been applied.
The Future of WLAN Security
The 802.1x standard, which is currently in development, eventually will replace WEP to secure LANs and WLANs. Microsoft has implemented the draft standard in Windows XP and will follow the standard in upcoming Windows .NET Server and other future OS releases. Until 802.1x is ratified and widely implemented, though, you can rely on IPSec to secure your WLANs.
End of Article
Prev. page
1
[2]
next page -->
