On This PageIntroductionThe primary objective of this chapter is to provide the reader with guidance on testing their own deployment of the Securing Wireless LANs with PEAP and Passwords solution. The recommendations given in this chapter are based on the experience gained by Microsoft in testing this solution. The first part of this chapter describes the testing process used by Microsoft. The second part covers the test scenarios that you can use to verify your solution before implementing it in the production environment. The test scenarios given in this chapter supplement the verification testing procedures included in chapters 3 through 6. Knowledge PrerequisitesOperational knowledge of the following areas will be helpful in testing this solution: | • | Public Key Infrastructure (PKI) concepts and Microsoft Certificate Services. | | • | Internet Authentication Service (IAS) server (RADIUS server). | | • | Installation of wireless network adapter drivers and configuration of wireless network settings in Microsoft Windows XP. | | • | Use and configuration of Pocket PC 2003. | | • | The Microsoft Active Directory directory service (including Active Directory structure and management tools; working with users, groups, and other Active Directory objects; and Group Policy). | | • | Microsoft Windows Scripting Host and Microsoft Visual Basic Scripting Edition (VBScript) language (these will be helpful in customizing or using the scripts and tools provided with this guidance). |
How Microsoft Tested the SolutionThe Microsoft test team focused on verifying the solution profile described in Chapter 2, "Planning a Wireless LAN Security Implementation". Following are the main characteristics of the profile: | • | A single-domain Active Directory forest containing two domain controllers with the domain functional level of Windows 2000 native mode. | | • | Domain controller servers were installed on Windows Server™ 2003, Standard Edition. | | • | Windows XP Service Pack 1 Professional and Tablet Editions and Pocket PC 2003 (Hewlett Packard IPAQ 5550) were used as wireless clients. | | • | IAS was installed on the domain controllers. | | • | The Certification Authority (CA) server was installed on one of the domain controllers. | | • | The network at the head office site was on a single local area network (LAN); the branch office site was on a separate LAN. | | • | Dynamic Wired Equivalent Privacy (WEP) was used for WLAN data protection rather than WPA. | | • | The remote branch office had only wireless access points (APs) as infrastructure and latency was introduced in the connection to the head office to simulate a DSL or cable modem type of connection. |
This profile does not cover all possible configurations of the solution (such as scaling to larger organization sizes); however, it ensures that all components of the configurations have been tested. The architectural changes required to scale this profile to that of an organization with 5000 users are relatively minor. Note: The testing described here only includes the verification of the solution performed by Microsoft. It does include the extensive product testing carried out by the Microsoft product groups; the solution testing is additional to this. Test Network LayoutThe test lab environment was based on the network design described in Chapter 2, “Planning a Wireless LAN Security Implementation”. The following figure shows the physical layout of the lab instance, which has the simplest network configuration described in Chapter 2. The head office network was on a single network with the wireless clients and domain servers on single subnet. The branch office site had a separate network and was on a different subnet. The router linking the head office and branch office included simulated WAN latency and bandwidth restriction. The wireless APs were sufficiently spaced out so that users could rove between them. Although a single, unsegmented LAN was used for testing, you may want to segregate your internal network using different subnets, virtual LANs (VLANs), and switches to better manage network performance and security. Once the base network consisting of domain controllers, Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), file, print, and Web services with static wireless WEP was developed, the implementation guidance given in chapters 3 through 6 was used to install and configure each component. These chapters include verification procedures, which were all performed as described. A larger suite of tests was performed before, during, and after the build. The most important test scenarios used are included in the next section; you can use them to test your implementation of the solution. The built solution, the build and operating scripts, and the documentation were subjected to three rounds of testing and the issues were raised as bugs. Testing was considered complete and successful when all the bugs were resolved. Verifying Your ImplementationThis section describes the principal test scenarios used by Microsoft to test the solution. These test scenarios are not exhaustive; you may develop your own scenarios based on the requirements of your organization. Some verification scenarios described in previous chapters have been repeated in this chapter for completeness. You should have read the previous chapters before you use these scenarios for testing. In case the test fails in any of the scenarios, see the "Troubleshooting" section in Chapter 8, "Maintaining the Secure Wireless LAN Solution" to diagnose and resolve the test failures. Scenario 1: Verifying IAS Server Certificate DeploymentThis scenario verifies that once the IAS servers are built and configured, they will receive the server authentication certificate auto–enrolled from the network CA. Execution Details 1. | Open a command shell using the MSS WLAN Tools shortcut. | 2. | Run the following command to open the Certificates MMC: ComputerCerts.msc | 3. | In the console tree, double-click Certificates (Local Computer) and then double-click Personal. Next, click Certificates. | 4. | You should see at least one certificate with the name of the IAS server in the Issued To column and the name of your CA in the Issued By column. Scroll the list (to the right) and verify that the value in the Certificate Template column is Computer for this certificate. | 5. | If the required certificate does not appear in the Certificates MMC, select Certificates (Local Computer) from the console tree in the left pane, click All Tasks from the Action menu, and then click Automatically Enroll Certificates. Then refresh the view of the Certificates MMC. |
Scenario 2: Verifying the Root CA Certificate on the Windows XP Wireless ClientThis scenario verifies that a valid wireless Windows XP client receives the network CA’s Root Certificate in its Trusted Root Certification Authorities store. This certificate is downloaded and added to the store when the Group Policy is updated. Execution Details 1. | Log on to the client computer as an Administrator. | 2. | Select Start, Run... type MMC.exe and press Enter. | 3. | From the File menu of the MMC, select Add/Remove Snap-in... | 4. | In the Add/Remove Snap-in... window, click the Add... button. Select the Certificates item from the list of available snap-ins. | 5. | Select Computer Account and then click Next. | 6. | Click Finish. | 7. | Close the Add Standalone Snap-in and the Add/Remove Snap-in... windows. | 8. | In the left pane, navigate to Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates. | 9. | Locate the certificate for your CA. (It should be listed under the name you gave your CA during installation.) | 10. | If the certificate does not appear in the list, run the following command at a command prompt: Gpupdate /force | 11. | Return to the Certificates MMC. Right-click the Certificates (Local Computer) node, select Refresh, and then check for the CA certificate again. |
Scenario 3: Verifying User Authentication to the Wireless NetworkThis scenario is the most important test scenario. It verifies that a WLAN user is able to successfully authenticate and connect to the network after the solution is installed and configured. Execution Details 1. | Ensure that a particular domain user is a member of the Wireless LAN Users group or the Domain Users group (which is a member of the first group). | 2. | Have the user log on to a client computer that has a WLAN card installed and is not connected to the wired network. The user should give the domain credentials during logon. | 3. | Open Network Connections panel from the Control Panel, and check the status of Wireless Network Connections. It should show the Authentication Succeeded status for the wireless connection. | 4. | From the command prompt, use the ping command to verify network connectivity to another computer on the network. | 5. | On the IAS server, open Event Viewer.The System event log should contain an Information type IAS log of Event ID 1. Browse through the description of the log; it should have user’s authentication details. |
Scenario 4: Verifying Computer Authentication to the Wireless NetworkThis scenario verifies that a computer is authenticated to the network when the user is not logged in. Execution Details 1. | Ensure that the computer account is a member of the Wireless LAN Computers group or the Domain Computers group (which is a member of the first group). | 2. | Restart the computer after ensuring that it has a WLAN card installed and is not connected to the wired network. | 3. | At the logon prompt, do not login and keep the machine idle for a few minutes. | 4. | On the IAS server, open Event Viewer. The System event log should contain an Information type IAS log of Event ID 1 for the computer hostname. Browse through the description of the log; it should have the computer authentication details. |
Scenario 5: Verifying Pocket PC Authentication to the Wireless NetworkThis test scenario verifies that a user can successfully log on to the WLAN network from a Pocket PC device. Execution Details 1. | Ensure that a particular domain user is a member of the Wireless LAN Users group or the Domain Users group (which is a member of the first group). | 2. | Enable the wireless connection on the Pocket PC and configure the 802.1X settings on the Pocket PC following the guidance provided in Chapter 6, “Configuring the Wireless LAN Clients.” | 3. | Select and hold your network name in the list of wireless networks till it displays an option to connect. Choose Connect to connect. | 4. | When prompted to enter domain credentials at the Network Log On screen, type the name, password, and domain of the user. | 5. | If authentication is successful, the network status icon will not have a cross sign. Verify the status by opening Internet Explorer from Start menu and browsing any intranet Web site. | 6. | On the IAS server, open Event Viewer.The System event log should contain an Information type IAS log of Event ID 1. Check the description of the log; it should have user’s authentication details. |
Scenario 6: Blocking a WLAN Client Using IAS Remote Access PolicyThis scenario is based on the guidance provided in Chapter 8, “Maintaining the Secure Wireless LAN Solution.” An administrator, if required, can block a user’s wireless access to the network using the Deny Remote Access policy (this procedure is detailed in the ”Denying WLAN Access to a User or Computer” section of Chapter 8). You should configure the Deny Remote Access policy on the IAS servers before you execute this test scenario. Execution Details 1. | Ensure that a particular computer account is a member of the Deny Wireless LAN Users group. | 2. | Have the user log on to a client computer that has a WLAN card installed and is not connected to the wired network. User should enter the domain credentials at logon. | 3. | The user should not be able to log on to the domain; they should see an “access denied” message. | 4. | On the IAS server, open Event Viewer. The System event log should contain a Warning type IAS log of Event ID 2. Browse through the description of the log; it should have the user’s authentication failure details. |
Scenario 7: WLAN Access Denied if the User is not a Member of WLAN Access GroupsThis test case verifies that a user is denied wireless access to the network if he/she is not a member of the Wireless LAN Users group. This is an alternate method of blocking user’s wireless access to the network. Execution Details 1. | Open the Active Directory Users and Computers console from Administrative Tools panel. | 2. | Remove the Domain Users group from the Wireless LAN Users group, or remove a particular user if you are adding users directly to the Wireless LAN Users group. | 3. | Have the user log on to a client computer that has a WLAN card installed and is not connected to the wired network. User should enter the domain credentials at logon. | 4. | The user should be unable to log on to the network and should see an “access denied” message. | 5. | On the IAS server, open Event Viewer. The System event log should contain a Warning type IAS log of Event ID 2. Browse through the description of the log; it should have the user’s authentication failure details. |
Scenario 8: Verifying IAS Service FailoverThis test scenario verifies availability of IAS service to the wireless clients when one of the IAS servers becomes unavailable. Such failures should not result in disruption of network connectivity for the wireless clients. This important test scenario verifies that the APs switch over to secondary IAS servers when the primary IAS server becomes unavailable. Execution Details 1. | Open the IAS MMCon the primary IAS server of your network and click the server name. Then stop the IAS service by clicking the Stop button on the menu bar. | 2. | Using a domain user account with authorized access to the WLAN, log on to the network using a wireless connection. | 3. | The user should be able to successfully authenticate and connect to the network. Verify this by opening the Network Connections panel from the Control Panel, and check status for Wireless Network Connections. The status should show Authentication Succeeded for the wireless connection. | 4. | From the command prompt, use the ping command to verify network connectivity to another computer on the network. | 5. | On the secondary IAS server, open Event Viewer.The System event log should contain an Information type IAS log of Event ID 1. Browse through the description of the log; it should have user’s authentication details. |
Scenario 9: Wireless Client Roving Between Access Points and Re-Authenticating to WLANThis scenario verifies that the wireless clients can roam between APs, which results in re-authentication (or Fast Reconnect, if enabled). It is important that this scenario is tested before deploying the solution in the production environment. This test verifies that the wireless network connectivity is seamless for users. Execution Details 1. | Using a domain user account with authorized access to the WLAN, log on to the network using a wireless connection. Ensure that the network connection was successful. | 2. | On the IAS server, open Event Viewer.The System event log should contain an Information type IAS log of Event ID 1. Browse through the description of the log; it should have the user’s authentication details. | 3. | From the user’s authentication details, note the IP Address of the AP to which the user is connected. The value is shown in the Client-IP-Address field. | 4. | Perform roaming with your machine to another location so that the client is in close proximity with a neighboring AP and far from the AP to which it was connected. | 5. | This should cause your Windows XP client to perform a re-authentication and get connected to the new AP. | 6. | On the IAS server, open Event Viewer.The System event log should contain an Information type IAS log of Event ID 1. Browse through the description of the log; it should have the user re-authentication details and the Client-IP-Address field should have the IP of the new AP. |
Scenario 10: Re-authentication of Wireless Client Due to IAS Session Time-outThis scenario verifies the dynamic WEP key rotation configured in the IAS Connection Request Policy. The test verifies that the client(s) are re-authenticated periodically (after the configured time duration) so that their WEP keys keep changing. Execution Details 1. | Using a domain user account with authorized access to the WLAN, log on to the network using a wireless connection. Ensure that the network connection was successful. | 2. | On the IAS server, open Event Viewer.The System event log should contain an Information type IAS log of Event ID 1. Browse through the description of the log; it should have the user’s authentication details. | 3. | Leave the client connected to the network for a time period more than one hour. You can start a continuous ICMP request to another computer on the network to confirm that the connection is active. | 4. | After about an hour’s time period, open the Event Viewer and check the System event log. It should contain an Information type IAS log of Event ID 1. Browse through the description of the log; it should have the user re-authentication details. |
Scenario 11: E-mail Alert for IAS Backup FailureThis test case verifies that e-mail alerts are properly configured for the IAS servers as documented in this solution. When properly implemented, these alerts significantly improve the manageability of the IAS service, which is critical for wireless network connectivity. Ideally, this test should be performed after implementation to confirm that the notification services are running properly. To test this scenario, an IAS backup failure is simulated to generate the required e-mail alerts. The steps for configuring IAS backup as required in this scenario are given in Chapter 8, “Maintaining the Secure Wireless LAN Solution.” You should have read Chapter 8 and configured the necessary scripts before executing this test case. Execution Details 1. | Open a command shell using the MSS WLAN Tools shortcut. | 2. | Edit the Constants.vbs file and set the ALERT_EMAIL_ENABLED parameter to True. | 3. | Configure the ALERT_EMAIL_RECIPIENTS parameter with the e-mail addresses of the persons who need to be alerted. | 4. | Configure the ALERT_EMAIL_SMTP parameter with the SMTP server’s IP address or DNS name. | 5. | Run the following IAS backup command to some non-existent folder: MSSTools BackupIAS /path:C:\IncorrectIASpath. | 6. | On the IAS server, open Event Viewer.The Application event log should contain an Error type IAS Operations log of Event ID 211. | 7. | The persons identified for alerts should receive an e-mail alert. |
Scenario 12: E-mail Alert for CA Service FailureThis test case is similar to the IAS backup failure alert test case. It verifies that the e-mail alerts are sent to the concerned administrative people if the CA service fails. The steps for configuring CA backup as required in this scenario are given in Chapter 8, “Maintaining the Secure Wireless LAN Solution.” You should have read through Chapter 8 and configured the necessary scripts before executing this test case. Execution Details 1. | Open a command shell using the MSS WLAN Tools shortcut. | 2. | Edit the Constants.vbs file and set the ALERT_EMAIL_ENABLED parameter to True. | 3. | Configure the ALERT_EMAIL_RECIPIENTS parameter with the e-mail addresses of the persons who need to be alerted. | 4. | Configure the ALERT_EMAIL_SMTP parameter with the SMTP server’s IP address or DNS name. | 5. | Open Certification Authority from Administrative Tools panel. Click the CA name, and select Action, All Tasks, and then Stop service. | 6. | Open the Services MMC from the Administrative Tools panel. | 7. | Right-click Certificate Services and select Properties. Change Startup type to Disable and click OK to close. | 8. | Run the following CA command: MSSTools CheckCA | 9. | On the CA server, open Event Viewer.The Application event log should contain an Error type CA Operations log of Event ID 1. | 10. | The persons identified for alerts should receive an e-mail alert when the CA service fails. | 11. | Revert the Certificate ServicesStartup type to Automatic in the Services MMC. | 12. | Start the service on the Certification Authority MMC by clicking the Start button on the menu bar. |
Test ToolsThe following tools were used during the testing of this solution. Some of these tools are also used during the building and maintaining phases: 1. | Certutil: This is a multipurpose tool used to configure CA; dump and display CA configuration information; back up and restore CA components; and verify certificates, key pairs, and certificate chains. | 2. | Dcdiag: This tool analyzes the state of domain controllers in a forest or enterprise. | 3. | Event Log Viewer: This tool monitors and captures logs related to applications, security, and the system. | 4. | Group Policy Management Console: This tool is used to view and edit Group Policy objects in Active Directory. | 5. | NetMon: This utility captures and filters frames from network traffic to and from the computer on which it is installed. This tool is not directly required but it is useful for debugging authentication issues. This tool can be installed from Control Panel by selecting Add/Remove Components, Windows Components, Management and Monitoring Tools, and then Network Monitor Tools. | 6. | Netsh: This is a command-line scripting utility that allows you to display or modify, either locally or remotely, the network configuration of a computer that is currently running. This is a multipurpose tool used for IAS-related operations. | 7. | Windows Backup: This is the backup and restore tool supplied with Windows that performs backup and restore operations on files, folders, and system state. This tool can be run either through a wizard or a command line. | 8. | PerfMon: This tool allows you to view system performance logs, alerts, and counters. You can use this tool to monitor the performance of your IAS. | 9. | Ping: This tool verifies IP-level connectivity to another TCP/IP computer by sending ICMP Echo Request messages. Corresponding Echo Reply messages that are received are displayed along with round-trip times. | 10. | Schtasks: This tool schedules commands and programs to run periodically or at a specified time. It adds and removes tasks from the schedule, starts and stops tasks on demand, and displays and changes scheduled tasks. |
Most of these tools are installed automatically when the Windows operating system is installed. Installation of the other tools is covered in Chapter 3, "Preparing Your Environment." SummaryThis chapter covered the testing of the secure WLAN solution. The first part briefly described the parameters used by Microsoft when testing this solution during development. The second part provided instructions on how to perform some of the most important test scenarios used for testing this solution. These test scenarios allow you to verify the correct operation of your own WLAN security infrastructure prior to its deployment in a production environment.
| |
