Securing Wireless LANs with PEAP and Passwords
Chapter 2: Planning a Wireless LAN Security Implementation
On This PageOverviewThis chapter describes the overall design of the secure wireless local area network (WLAN) solution. It aims to give you a thorough understanding of the design of the solution and the reasons for designing it that way. It should also give you enough information to help you adapt the design to the particular needs of your organization. The chapter begins with a description of how 802.1X and Protected Extensible Authentication Protocol (PEAP) work to secure access to the network. This is followed by a description of the target organization for the solution and explores some of their key requirements. The middle portion of the chapter describes the design of the WLAN solution including: the network design; Internet Authentication Service (IAS) server placement; selection of hardware and software; obtaining certificates; and client configuration. How to migrate from an unsecured WLAN to 802.1X and PEAP is also outlined. The sections towards the end of the chapter deal with variations on the basic solution design. The most important of these design variations is how to scale the solution for use in larger organizations, which is discussed at some length. Other design options covered are:
Chapter PrerequisitesAs part of planning for your secure WLAN implementation you need to ensure that you have the right skill sets available in your organization and that you involve the right people in the decisions affecting the deployment. To get the best out of this chapter, it would be helpful if you were familiar with the following topics:
How Wireless LAN Security WorksDifferent methods for securing WLANs were discussed at some length in the introductory document, “Choosing a Strategy for Wireless LAN Security”. The discussion focused on the use of strong authentication to the WLAN using 802.1X and encrypting the network traffic using dynamic Wired Equivalent Privacy (WEP) or WiFi Protected Access (WPA). The following are the key points from that discussion:
How 802.1X with PEAP and Passwords WorksFor password-based WLAN authentication, Microsoft supports the use of PEAP with MS-CHAP v2. Figure 2.2 illustrates how 802.1X with PEAP and MS-CHAP v2 works. The figure shows the following four main components:
The following steps describe how the client makes a request and is granted access to the WLAN and thus the internal network. These step numbers correspond to the numbers in figure 2.1.
Computer and User Authentication to the WLANThe process just described illustrates how a client (a user or a computer) successfully connects to the WLAN. Windows XP authenticates both the user and the computer independently. When computer first starts up, it uses its domain account and password to authenticate to the WLAN. The authorization of the computer to the WLAN follows all of the steps outlined in the previous section. Having the computer connect to the WLAN using its own credentials permits it to be managed even when no user is logged on. For example, group policy settings can be applied and software and patches distributed to the computer. When a user logs on to the computer, the same authentication and authorization process is repeated, but this time with the user's name and password. The user’s session replaces the computer WLAN session; this means that the two are not active simultaneously. It also means that an unauthorized user cannot use an authorized computer to access the WLAN. Note: Windows XP allows you to override this behavior and specify that either only the computer or user credentials are used. These are not recommended configurations. The former allows users to connect to the WLAN without authorization. The latter prevents the computer from connecting to the WLAN until a user logs on, which will interfere several computer management functions. Target Organization ProfileThis solution is designed for a small business of 100–200 people. Although the organization is fictitious, its characteristics and requirements are derived from extensive real–world research. These real–world requirements have helped shape the style and scope of the guidance as well as the choices made in the design. It is important to understand that this solution is not restricted to organizations of this size. The simplicity of the design and the scalability of the components used mean that the same PEAP–based WLAN solution can be easily scaled for much larger (with thousands of users) and much smaller organizations. By understanding the characteristics of the target organization, you will be better placed to understand the assumptions of the design and adapt them to your own organization. Using the solution in larger organizations is covered in the "Scaling for Larger Organizations" section of this chapter. For very smaller organizations, all of the required components can be installed on a single existing server. Organization LayoutThe physical and information technology (IT) layout of the organization is shown in the following figure. There is a single large head office, which houses most of the IT systems and the majority of the users. All Active Directory domain controllers are located here. The head office has a connection to the Internet through a firewall server. There are a number of WLAN clients and wireless APs connected to the internal network. There are also one or more outlying offices with very few local IT services beyond network connectivity to the head office. There are a small number of clients (possibly all wireless) at this office and it frequently receives visitors from head office who bring their WLAN clients to be able to connect back to their applications and data at the head office. The wide area network (WAN) connectivity between offices is provided either by private lines (for example a T1—1.5Mbps) or by DSL Internet connections and a virtual private network (VPN) router–to–router link across the Internet. The WAN connection is typically not resilient to failure. Note: If the WAN connection between offices is provided by a VPN connection across the Internet, each office will typically have a firewall protecting it from threats on the Internet. The presence of this firewall is not relevant to the WLAN discussion and has been omitted to aid clarity. IT EnvironmentThe Active Directory of this organization is a single domain forest with at least two domain controllers. It authenticates users to the domain and provides directory and authentication services to several applications such as Microsoft Exchange Server and Outlook for e–mail. The domain controllers have recently been upgraded from Windows 2000 Server to Windows Server 2003, Standard Edition. The domain controllers also run additional services such as Domain Name System (DNS), DHCP, and Windows Internet Name Service (WINS) for a few legacy applications. The IT systems are predominantly Microsoft technologies, with Windows XP on client computers and Windows Server 2003 on server systems. There are also a number of servers running Windows 2000, which the company plans to upgrade as application testing and support allow. The organization has begun to invest in mobile systems such as Windows XP, Tablet Edition, and Pocket PC 2003 particularly for its sales, distribution, and warehouse staff. Key server applications include Microsoft Exchange Server, SQL Server (running several Line–of–business applications), Internet Information Services (IIS), and Windows SharePoint™ Team Services. Applications are deployed to client computers using Active Directory group policy. Operating system patches are deployed using Windows Server Update Services (WSUS) and the Windows Automatic Updates service. System monitoring is done directly on the server systems by reviewing Windows event logs, performance logs, and application logs daily. Critical alerts for hardware and software are sent to the IT administrator through e–mails and alerts on the system consoles. The organization has two full–time IT personnel, who look after the IT planning, service delivery, and day–to–day support. Both the IT manager and the IT support engineer have latest MCSE certifications and a number of years of experience in IT. Design CriteriaThe organization described in the previous section will typically have the following types of criteria for a WLAN solution. These criteria have been extended to cover a broad category of organizations. The design presented in the rest of the chapter explicitly uses these criteria. Table 2.1: WLAN Solution Design Criteria
The following table gives an indication of the WLAN authentication requirements for different sizes of organization. The "New Authentications per second" is part of the steady load and assumes an average of four new full authentications per user per day as users rove between wireless APs. The "Peak New Authentications per second" column indicates the type of load expected when all users authenticate over a 30 minute period (for example at the start of the day). The "Re-authentications per second” column shows the number of periodic re-authentications to force the renewal of dynamic WEP keys. Table 2.2: WLAN Authentication Requirements
These figures are referred to later in the chapter when discussing IAS server sizing. WLAN ArchitectureThis section covers the architecture of the solution. Network DesignThe following figure illustrates the basic network layout for the head office. The figure shows wireless clients, two or more wireless APs, two IAS servers running on Active Directory domain controllers, a DHCP server, and other network connected servers, clients, and devices. With the exception of the WLAN clients, all items are connected on a single LAN using one or more layer 2 switches. A single subnet is used for the entire internal network at this site. There are routed connections (not shown in the figure) through the firewall to the Internet and other offices. Larger organizations are more likely to have a routed environment within a single site. Although this does not make any difference to the authentication infrastructure, it may have an impact on how the wireless APs are connected to the rest of the network. To make it easier for users to rove between multiple APs across a site, it is a normal practice to place all the wireless APs and WLAN clients on the same IP subnet. This allows users to rove between wireless APs but still keep the same IP address. A detailed discussion of this topic is beyond the scope of this guide. It is covered in more detail in the "Deploying a Wireless LAN" chapter of the Windows Server 2003 Deployment Kit. In your network design, you must ensure the following:
Selection of Wireless Network HardwareYou should ensure that your wireless APs and wireless network adapters support the following:
You should have sufficient wireless APs to provide coverage for WLAN clients across the physical locations that you need to support. You should also plan the wireless AP placement so that there is adequate backup coverage in all locations in case a wireless AP fails. Wireless AP placement is covered in more detail in the "Deploying a Wireless LAN" chapter of the Windows Server 2003 Deployment Kit, also listed in the “References” section at the end of this chapter. You should also read the article "Recommendations for IEEE 802.11 Access Points" referenced at the end of this chapter. IAS Server PlacementThe goal of IAS server placement is to achieve a resilient WLAN service while keeping implementation and management costs low. A WLAN service that is resilient to a single component failure has the following characteristics:
The second of these is the most significant for planning IAS server placement. In this solution, IAS is on existing domain controllers. This provides the highest performance configuration together with relatively low implementation and management costs. As a general recommendation for organizations of all sizes, you should deploy IAS to every site that has a domain controller (although you may not need to install IAS on every domain controller). The following figure illustrates the placement of IAS servers in the organization. IAS is deployed on two existing domain controllers in the head office. The network CA (refer to the section "Obtaining Certificates for IAS Servers" later in this chapter) is also installed on one of these domain controllers. All APs in the head office are configured to use these IAS servers. The organization has a small branch office with no local domain controller. The wireless APs in this site use the two IAS servers in the head office for all authentication requests. This means that users will be unable to authenticate to the WLAN if the WAN connection to head office fails. This may be an unacceptable risk for many organizations. To resolve this, you should either install redundant WAN connectivity or install a local IAS and domain controller. Although this might seem like an unreasonable cost for this type of office, WAN failure will also cause most other network services to fail (for example, local file servers) without access to a domain controller. Rectifying this will therefore benefit the reliability of these services as well as the local WLAN. Deploying domain controllers to branch offices is discussed in the section "Scaling for Larger Organizations", later in the chapter. For small offices where WAN connectivity is highly unreliable and deploying a local domain controller is not feasible, you may decide to deploy a standalone WLAN. For more information on this, you should read the section "SOHO Environments" later in the chapter. Assignment of APs to RADIUS ServersYou must assign all your wireless APs to IAS servers. Each wireless AP requires a primary and a secondary RADIUS server. This allows the wireless AP to use the secondary RADIUS server in the event that the primary server has failed or is not contactable. This arrangement is shown in the following figure.  Figure 2.5 Balancing AP between primary and secondary IAS servers The figure shows how each of the wireless APs is configured with different primary and secondary RADIUS servers. This allows load balancing between the servers. Wireless APs in sites with no local IAS server will follow the same pattern using the IAS servers in the head office as primary and secondary RADIUS servers. For wireless APs in sites with only one local IAS server, the local server should always be the primary server and the server in the head office (or other suitable location where there is reliable connectivity to an IAS server) should be the secondary server. This is illustrated in the following figure. If you have many APs, you should carefully document the assignment of APs to IAS servers. You can use this record to ensure that every AP has been assigned a primary and a secondary server and that the load from APs is evenly balanced across the available servers. Note: All wireless APs will failover to the secondary IAS server when the primary IAS server is not available. However, most APs do not automatically revert to using the primary when it becomes available again (they will only fall back if the secondary subsequently fails). This is not a major problem where both IAS servers are at the same location; it will simply make load across the servers uneven. However, where the secondary IAS is remote, a temporary failure of the primary may leave all APs authenticating to the secondary over a non–optimal WAN link. If your APs do not automatically revert to their designated primary server, you may need to manually reset the APs so that they start using the local IAS server when it recovers after a failure. Transient network conditions can also cause APs to failover to their secondary RADIUS servers, so you may need to occasionally check the authentication request events in the IAS server application logs to spot any APs using the wrong IAS. Co-location of IAS with Domain ControllersIn this solution, IAS is installed on existing domain controllers. This keeps the costs of implementation low and gives a performance improvement over using IAS on a separate member server. The performance gain occurs because IAS can communicate with the Active Directory on the same computer without incurring any network delay. You should be aware of some caveats of installing IAS on domain controllers. While these will not be of concern to many organizations, you may want to consider them before proceeding:
IAS Software and Hardware RequirementsFor a target organization of 100 to 200 users, it is unlikely that IAS load on servers will ever be an issue as long as you are using the recommended hardware specification for Windows Server 2003. However, for larger organizations, this may be a consideration, particularly if they are running IAS on existing domain controllers. The load on the IAS will be affected by:
You can use the figures given in table 2.2, in earlier "Design Criteria" section, to estimate the number of authentications per second that you can expect from a given user population. You should consider the steady state load when users are authenticating normally and the 'worst case' load during peak times. Extrapolating the figures from this table, 200 users generate a steady state load of less than one full authentication every 50 seconds and one fast re–authentication every ten seconds. These are such small numbers that the only really significant figure is how long it takes to authenticate all users following an outage — when all users need to connect back to the WLAN immediately. This is a much more extreme peak than the start-of-day logon, which will tend to spread over 30 minutes or more. Authentication options have a significant effect on IAS server load. Protocols such as PEAP perform a CPU–intensive public key operation upon initial log on; although for subsequent re-authentications, cached session information is used, allowing what is known as a "fast reconnect". If you are using dynamic WEP, the clients will re-authenticate every 15–60 minutes to generate new encryption keys. However, with WPA you need to enforce re-authentication much less frequently, typically every 8 hours. The following table shows the approximate number of authentications per second for IAS on an Intel Pentium 4 2 GHz server running Windows Server 2003 with Active Directory on a separate server. Note: The information in the following table was derived from tests done by Microsoft Solutions for Security. It is provided without warranty of any kind and should only be used as a guideline for capacity planning purposes and not for performance comparisons. Table 2.3: Authentications per Second
These figures were calculated with RADIUS logging enabled and with Active Directory running on a separate server; both of these factors reduce the performance of IAS, so these figures can be considered a pessimistic estimate. As these figures show, this type of server will allow 200 WLAN users to authenticate to the network in six seconds and 1000 users in 30 seconds. Using Windows Server Standard or Enterprise EditionThis solution uses Windows Server 2003, Standard Edition for all IAS servers; this keeps the cost of server licenses low and allows you to deploy on existing servers whether they be Standard or Enterprise Edition. IAS in Windows Server 2003, Standard Edition has the limitations that each server can support only 50 RADIUS clients and two RADIUS server routing groups. Note: RADIUS clients are not the same as WLAN clients. RADIUS client refers to wireless APs and also other network access servers, such as VPN servers and firewalls that make use of RADIUS authentication services. For the target organization of 1 to 200 users, a maximum of 50 APs per server is more than sufficient. For larger organizations this limit may be significant particularly for large offices, or where many satellite offices feed into one or two hub IAS servers. Assuming 15 users per wireless AP, this means that a single IAS server on Windows Server 2003, Standard Edition could support approximately 750 users. This calculation takes into account the total number of APs that will use a server as a primary or a secondary RADIUS server; therefore, two servers will support 50 APs and not 100. If any of your IAS servers need to support more than 50 APs, you need to use Windows Server 2003, Enterprise Edition. You can, of course, also mix and match the two editions by using Windows Server 2003, Enterprise Edition for large offices and hub offices, and Windows Server 2003, Standard Edition for smaller offices. IAS ConfigurationIAS settings can be broken down into four major categories:
These categories are described in detail in the following subsections. All these settings are common to all of the IAS servers used in this solution; this allows the settings to be configured on one IAS server and copied to the others. This technique is used in Chapter 5, “Building the WLAN Security Infrastructure” to ensure that the IAS settings are consistent between all servers in your organization. In addition, each IAS server will also have one or more wireless APs configured as RADIUS clients. RADIUS clients were described in the earlier section "Assignment of APs to RADIUS Servers". The set of RADIUS clients is usually different for each server and therefore they are not replicated between the servers in the same way as the other settings. IAS Server SettingsThis category includes:
RADIUS PoliciesIAS policies control the authentication and authorization of accounts to the network. There are two types of policies:
The RAP controls how or whether a connection is authorized to the network. A RAP contains a set of filter conditions that determine whether that policy applies to a given connection request. Some examples of filter conditions are: specifying the Windows security group of which a client must be a member, specifying the connection type (such as Wireless or VPN) of the requesting client, and specifying the time of day that the client is attempting to connect. Each RAP has a policy action, which is set either to allow or deny a connection request. Connection requests matching the RAP condition filter will be allowed or denied access to the network according to the policy action setting. A RAP also contains a set of parameters that apply to an allowed connection, known as the RAP profile. These parameters include the authentication methods that are acceptable for this connection, how an IP address will be assigned to the client, and the amount time for which the client can remain connected before re–authentication is required. There can be multiple RAPs on an IAS; each connection request is evaluated against them (in order of priority) until a matching RAP either allows or denies the request. The RAP in this solution is configured as shown in the following table. Table 2.4: Remote Access Policy Configuration
The condition filter matches all wireless clients and all members of the domain group Wireless LAN Access. Parameters that are not relevant to WLAN access, such as Multilink and Microsoft Point-to-Point Encryption (MPPE) encryption settings, are not included in the table. For more details on the use of security groups with the RAP, refer to the “WLAN User and Computer Administration Model” section later in this chapter. The Dial-in constraints — Client Timeout setting can have an impact on the security and the reliability of the solution. Reasons for using different values to those given in the table are discussed in the "Security Options for Dynamic WEP" section later in the chapter. The RADIUS attribute "Ignore-User-Dialin-Properties" is used to bypass per user control of network access permissions. See the "WLAN User and Computer Administration Model" section for an explanation of per user and per group access control. A connection request policy controls whether to process the request at a particular RADIUS server or send it to another RADIUS server (called RADIUS proxy). RADIUS proxies are typically used where the RADIUS server does not have the information to process the request itself and must forward it to an authoritative RADIUS server, for example, to a server in another Active Directory forest. RADIUS proxies are not used in this solution and are outside the scope of this guide. For more information about remote access and connection request policies, and the use of RADIUS proxies, see the "References" section at the end of the chapter. RADIUS LoggingYou can configure IAS servers to log two types of optional information:
Successful and rejected authentication events generated from WLAN devices and users can be recorded in the Windows Server 2003 System Event Log on the IAS server. Authentication Event Log information is most useful for troubleshooting authentication issues, although this information may also be used for security auditing and alerting purposes. Initially, you should keep success and reject event logging enabled but you may consider disabling success events once the system has stabilized. Successful WLAN access events will bloat the System Event Log but may be needed for audit purposes. If you use a monitoring and alerting tool such as Microsoft Operations Manager (MOM), you should consider adding a rule to alert on IAS authentication failure events in the System Event Log. Alternatively, you could use an event log query tool such as eventquery.vbs to check the event log for authentication failures (see the "Eventquery.vbs" entry in the online help). Single events are usually insignificant but a series of such events can indicate an attempted break-in. IAS also has the ability to record authentication and network access session information in the form of RADIUS request logs. You normally use RADIUS logging either when you need to charge for network usage (for example, as an Internet service provider (ISP), you need to charge based on connection time) or where you need specialized security audit information (although, for most purposes this is already covered by the authentication events logged to the event log). For more information on RADIUS logging, refer to the ”References” section at the end of the chapter. IAS SecurityYou should treat IAS with similar security precautions as you use with a domain controller. Secure control of your network is dependent on the security of your IAS infrastructure. There are several simple measures, which you can implement to improve the security of IAS:
For more information on IAS security measures, see the “References” section at the end of this chapter. WLAN User and Computer Administration ModelAccess to the WLAN in this solution is controlled using domain security groups. Although it is possible to use the dial–in properties of domain user objects to allow and deny access to individuals, this is tedious to administer for many users. This solution uses a very simple scheme of allowing all domain users and computers access to the WLAN. For many organizations, controlling access through domain membership is a strong enough control and minimizes additional management overhead associated with the WLAN. However, to give more control to organizations that require it, security groups can be used to define who is allowed to access the WLAN. As described in the section "RADIUS Policies," the IAS remote access policy uses a filter condition that grants WLAN access to all members of the Wireless LAN Access group. The following table shows the membership of the Wireless LAN Access group. Table 2.5: Wireless Access Groups to Allow All Users and Computers
The group in the first column, Wireless LAN Access, has two members listed in the second column namely, Wireless LAN Users and Wireless LAN Computers. These "First Level" groups themselves have members (shown in the third column — Second Level Members”) namely, the Domain Users and Domain Computers groups respectively. This arrangement of nested groups allows all users and computers in the domain to connect to the WLAN. If allowing all users and computers to access the WLAN is overly permissive for your organization, you can remove either or both Domain Users and Domain Computers from these groups. You will then need to add the specific user and computer accounts or groups to the Wireless LAN groups. The following table illustrates how to use the Wireless LAN Access group structure in this manner. Table 2.6: Wireless Access Groups to Allow Selected Users and Computers
For more information on the use of these security groups in a multidomain forest, refer to the "Scaling for Larger Organizations" section later in this chapter. Obtaining Certificates for IAS ServersThe IAS servers need to have certificates to authenticate the WLAN clients. Server certificates are required to create the TLS encrypted tunnel between IAS servers and clients. TLS helps protect the authentication exchange between the server and clients. Note: TLS is an RFC standard based on the similar Secure Sockets Layer version 3.0 (SSL 3.0). Both are commonly used to secure Web traffic as part of the Hypertext Transfer Protocol, Secure (HTTPS). Embedded CA vs. Commercial CATo provide these certificates, you have the choice to either install a CA yourself or buy the certificates from a commercial certificate provider. Both options are valid and choosing one over the other creates no real technical difference to the WLAN solution. The major pros and cons to using in–house CA compared to buying certificates from a commercial provider are summarized in the following table. Table 2.7: Pros and Cons of Using Your Own CA vs. Commercial Certificates
The balance of the argument depends on how complex and costly it is to manage your own CA. If the cost of setting up a local CA is low and the management is simple, it is often a more attractive proposition than purchasing external certificates. This solution uses a simple internal CA to provide the certificates. The terms "embedded CA" and "network CA" have been used in this guide to indicate that it is a special purpose CA, which is essentially invisible to users and administrators and which issues certificates of a single type. The limited functionality of the CA in this solution means that it can be installed and used with little or no user or management intervention. For example, in this solution, the CA can issue a certificate with a lifetime of 25 years; therefore, you will not have to renew it during the lifetime of the solution. Automatic enrollment and renewal of the IAS server certificates means that there is no manual certificate distribution to perform. Contrast this with using external certificates. You must remember to renew the certificates of all IAS servers every year or two years. Each time you have to manually create the certificate request on each IAS server, send the request to the commercial CA then retrieve and manually install the issued certificate. Failure to do this will prevent users from connecting the WLAN. For many organizations the management overhead of this is far more onerous than the simple internal CA described used in this solution. Limitations of the Solution CAThis solution uses a special CA configuration to issue certificates to the IAS servers. It was only designed to meet this specific need and is not suitable as a general purpose certification authority. Digital certificates are used in many applications, such as secure e-mail and Web browsing, IP Security (IPSec), Virtual Private Networks (VPN), Encrypting File System (EFS), and others. Each of these applications has its own security requirements. Your organization will have its own unique security requirements with respect to these applications. For these reasons, Microsoft strongly recommends not attempting to use the solution CA for any other purpose. If you plan to use these or other certificate applications, design your certificate infrastructure around their requirements. Things that you need to consider include:
For more information about the detailed planning required to design a more generic PKI architecture, see Chapter 4, "Designing the Public Key Infrastructure," in the companion solution, Securing Wireless LANs — A Certificate Services Solution. You should also keep in mind that there are a number of constraints due to the CA being installed on the Standard Edition of Windows Server 2003. Although adequate for this solution, the Standard Edition supports a limited set of functionality compared to Windows Server 2003, Enterprise Edition. The salient features that are not available in Windows Server 2003, Enterprise Edition include:
If you require any of these features, you need a CA based on the more advanced capabilities of Windows Server 2003, Enterprise Edition. For a detailed description of the differences between Enterprise and Standard Edition, see the paper titled "PKI Enhancements in Windows XP Professional and Windows Server 2003" listed in the “References” section at the end of the chapter. If you do not have clear requirements for other types of certificates at present, however, you can deploy the CA described in this solution without closing your options in the future. At a later stage, if you identify other requirements for certificates, you can deploy a more sophisticated PKI alongside this solution. You are then free to either run them side by side or migrate to issuing all certificates from the new PKI. WLAN ClientsThe WLAN solution supports several, different types of WLAN client either explicitly or implicitly. This solution supports Windows XP, Professional Edition, Windows XP, Tablet Edition, and Pocket PC 2003 clients. For specific guidance on how to configure and use these clients with the solution, refer to chapter 6, “Configuring the WLAN Clients”. The guide does not cover using other types of clients that support 802.1X with PEAP-MS-CHAP v2. Although some other types of clients will work (Windows 2000 Professional, for example), this guide has no instructions on how to configure them and the Microsoft Solutions for Security team has not tested them with this solution. Windows XPWindows XP, Professional Edition and Windows XP, Tablet Edition are fully supported in this solution. All Windows XP clients must be updated with Service Pack 1 or later. The computers must be members of the same domain as the IAS servers or members of another domain within the same forest. Domain membership is required so that the computers can authenticate themselves to the WLAN and can download the WLAN settings specified in Group Policy. Computer authentication to the WLAN is used when no user is logged on to the computer. This allows the computer to obtain Group Policy object (GPO) settings, run startup scripts, and have patches downloaded to it. It is also required during the initial stages of user log on. The user cannot start to authenticate to the WLAN until after the user profile is loaded; therefore log on scripts, other GPO settings, and roaming profiles will fail if the computer does not have an existing connection to the network before the user logs on. Windows XP computers that are not domain members may still be used with the solution, with the following caveats:
Microsoft also strongly recommends enabling the personal firewall on all client computers using wireless. Pocket PC 2003Pocket PC 2003 supports 802.1X and PEAP, however, you may have to obtain updates from the vendor of your device and Microsoft to get full WLAN functionality. It is also possible to use versions of Pocket PC earlier than 2003 but Microsoft did not provide built-in support for 802.1X for earlier versions. You may be able to obtain specific support from your Pocket PC device vendor or use WLAN client software from a third party. Pocket PC systems have no concept of a computer domain account and are always authenticated to the WLAN using user credentials. Normally a connection to the WLAN will require a user to type their domain user name and password each time. It is possible to save the credentials so that the device connects automatically but this is not recommended unless you have very strong security features on the Pocket PC device. In addition, Pocket PCs do not understand Group Policy so their WLAN settings cannot be set automatically using this. You have to set the WLAN configuration manually. Other 802.1X ClientsClients other than Windows XP and Pocket PC 2003 may work with this solution if they support 802.1X and PEAP-MS-CHAP v2. Windows 2000 clients are supported using the Windows 2000 Microsoft 802.1X Authentication Client. Details on how to obtain the Windows 2000 Microsoft 802.1X Authentication Client are included in the references at the end of this chapter. Windows clients other than Windows 2000 (such as Windows NT 4.0, Windows 9x and Windows Me) are supported with a client available through Microsoft Premier Support. You may also be able to obtain client for these and other platforms from non – Microsoft network software vendors. You should also consult Appendix C, "Supported Windows Versions." WPA SupportThe WLAN solution described here supports the use of WPA WLAN protection in place of dynamic WEP. WPA is always preferred over WEP because it provides better key management and implements a stronger network encryption algorithm. WPA also supports the use of AES encryption, if the hardware (wireless APs and network adapters) provide the necessary support. Although WPA provides a number of advantages over dynamically keyed, there are some caveats over its use. These include:
GPO and Pocket PC 2003 support for WPA will appear soon, making WPA the option of choice. Until then, dynamic WEP coupled with 802.1X authentication continues to provide a very high level of protection for WLANs and is the default choice for this solution. For more information on WPA, see the “References” section at the end of this chapter. Migration from an Existing WLANIf you have an existing wireless network in place, you should plan a migration strategy upfront to ensure minimal disruption to users and the environment. Many organizations have 802.11–based WLANs operating without network authentication or encryption. Other organizations have implemented static WEP using shared key encryption often combined with Media Access Control (MAC) address filtering. The process of migrating from either of these scenarios to an 802.1X secured WLAN involves the following steps:
This type of rollout minimizes the disruption to users and allows you to rollback a site easily, if anything goes wrong. There will inevitably be some problems experienced by users during the switch over, so you should keep the users informed about the migration and be prepared to handle more support calls than normal. As with all migration strategies, careful planning and testing is essential. The steps involved in configuring client computers and wireless APs can cause disruption to the environment if they are not tested thoroughly to iron out nascent problems. Detailed planning of migration from unsecured and static WEP WLANs or from proprietary WLAN security schemes are not included in this guidance. All these are similar in principle and follow the pattern above. However, if you require more assistance with your migration planning, see your Microsoft partner or contact your local Microsoft subsidiary who will put you in touch either with a Microsoft partner in your area or with Microsoft Consulting Services. Scaling for Larger OrganizationsThis section describes some of the key considerations for using this solution in a large organization (one with several thousand users, for example). The use of PEAP and password authentication in the enterprise is detailed in Appendix A, “Using PEAP in the Enterprise.” IAS Server PlacementAs you increase the number of locations where you support WLANs, you need to decide how these wireless APs will be serviced by IAS servers. There are essentially two approaches:
Although the investment in network resilience may seem an expensive option, you need to weigh this against the administration cost of managing many distributed IAS servers. Even if IAS is installed on the same physical server as an existing domain controller there will be some cost of managing each IAS instance. In practice, most large organizations will use a hybrid of the two in the following ways:
The centralized IAS strategy was illustrated in the "IAS Server Placement" section, earlier in this chapter. The use of a local domain controller and IAS in a branch office is shown in the following figure. This shows a larger outlying office that is linked by a WAN to the Head Office shown in the figure 2.4 earlier. In this site, the APs are configured to use their local IAS server as the primary RADIUS server and one of the IAS servers in head office as the secondary RADIUS server. This means that WLAN clients can be authenticated, even if the local IAS server or WAN connectivity fails. However, if you have resilient WAN connectivity (for example, multiple WAN links with different providers), there is little to be gained by deploying additional servers at branch offices; it only adds complexity and additional management overhead. Multiple DomainsThe basic solution design scales transparently to multi–domain forests. The key points to consider while using the solution with multiple domains are as follows:
The first three items are mostly self-explanatory and the steps for configuring these for multiple domains are covered in later chapters. The use of the security groups is slightly more complex and is covered in detail in the following section. Use of Security Groups in Multiple DomainsThe following table shows how you can organize the security groups described in the "WLAN User and Computer Administration Model" section in a multidomain forest. Table 2.8: Wireless Access Groups to Allow All Users and Computers
The table shows the same group nesting arrangement as the tables in the "WLAN User and Computer Administration Model" section. The members of the group listed in the first column are shown in the second column; the members of the groups listed in the second column are shown in the third column. The example in the table uses fictitious names. For example, RootDom is the name of the domain where IAS servers are installed and UserDom1 and UserDom2 are other domains containing users and computers to be granted WLAN access. In the example shown, all users and computers from UserDom1 and UserDom2 are implicitly granted access to the WLAN because the Domain Users and Domain Computers groups from those domains are members of the Wireless LAN Users and Wireless LAN Computers groups for the same domain. However, the users from UserDom3 are individually added to the Wireless LAN Users group of UserDom3. The computers are granted access by using business unit security groups (for example, all computers in the HR department). The global groups for each domain, namely, Wireless LAN Users and Wireless LAN Computers, are then added as members of the universal group Wireless LAN Access. All members of this latter group are granted access to the WLAN in the IAS remote access policy. PKI ArchitectureAs mentioned in the earlier section "Obtaining Certificates for IAS Servers," many applications can utilize certificates. It is important to note that while appropriate for this solution, a standalone CA is unlikely to meet the more varied needs of larger organizations. Before implementing the CA described in this guidance, ensure to carefully consider other uses for certificates that you might have in the future, as well as alternate PKI architectures more appropriate for these scenarios. To read about PKI planning in more detail, refer to Chapter 4, "Designing the Public Key Infrastructure" in the companion solution, Securing Wireless LANs — A Certificate Services Solution. Although more sophisticated than the CA in this guide, the PKI discussed in that solution is still relatively simple: it uses only two CAs, for example. However, it is designed to be a foundation for a much broader range of certificate needs. If you decide against implementing a more sophisticated PKI such as this, you can still use the guidance given in Chapter 4 of this guide, “Building a Certification Authority.” However, you should consider making the following changes to the instructions provided in that chapter:
Guidance for how to do these is given in the “Public Key Infrastructure” section of the Windows Server 2003 product documentation and in Chapter 4, "Designing the Public Key Infrastructure," Chapter 7, "Building the Public Key Infrastructure," and Chapter 9 "Implementing Wireless LAN Security" in the companion solution, Securing Wireless LANs — A Certificate Services Solution. Variations on the Solution ArchitectureThis section discusses variations to the core design. The following subsections look at alternatives to the default security settings of the solution, using the IAS servers for wired and remote access authentication, creating guest WLANs for visitors and deploying WLANs to very small environments such as home offices. Security Options for Dynamic WEPThe "How 802.1X with PEAP and Passwords Works" section earlier in this chapter discussed the use of dynamic WEP encryption in the solution. The security of dynamic WEP relies on its ability to renew the encryption keys at regular intervals to thwart known attacks on the WEP protocol. IAS ensures that the keys for each wireless client are renewed at a set interval by using a client session time-out, which forces the client to re-authenticate to the WLAN. Reducing the session time-out value increases security but may reduce reliability and performance. A 60 minute time-out gives adequate security for most circumstances and certainly for 11 Mbps 802.11b networks. Normally, wireless clients will never transmit enough data in 60 minutes to allow a WEP key to be recovered by an attacker. The latest research indicates that static WEP keys can be recovered by capturing between 1 and 5 million network packets encrypted with the same key. This is documented in the technical paper “Using the Fluhrer, Mantin, and Shamir Attack to Break WEP” by Adam Stubblefield, John Ioannidis and Aviel D. Rubin of AT&T Labs — see the reference at the end of this chapter). Note: The figure of 1 million packets was obtained from testing static WEP WLANs using relatively weak keys (a "user–memorable passphrase") and is not directly applicable to dynamic WEP WLANs. Unlike typical static WEP WLANs, dynamic WEP uses strong random encryption keys and renders one of the key optimizations used by the authors much less effective. Nevertheless, it is good security habit to err on the side of caution and use the pessimistic figure of 1 million packets to assess the security threat to dynamic WEP WLANs. One million packets typically equates to around 500 MB of data (assuming an average packet size of 500 bytes). For the encrypted data to be secure, the session time-out needs to be set so that it forces each client's key to be renewed before the client sends more than this amount of data. For typical client network usage, such as e-mail, Web browsing, and file sharing, average data transfer rates are 160 Kbps or less. At this transfer rate, assuming 500 bytes packet size, it would take approximately 7 hours for an attacker to accumulate enough data to recover the client’s current encryption key. Note: In laboratory conditions, 500 Mb could be transmitted in much less than 7 hours; around 10 minutes on a11 Mbps WLAN or less than 3 minutes on a 54 Mbps WLAN. However, this assumes a single client having exclusive use of the WLAN and streaming unacknowledged UDP packets in one direction. This scenario, or anything near it, is extremely unlikely for a real world WLAN. A 60 minute session time-out is more than adequate for most organizations. This means that an average client would transmit around 150,000 packets before each key refresh; nearly an order of magnitude less than the 1 million packet threshold required for WEP key cracking. However, you may want to use a shorter time-out value for one or more of the following reasons:
There are two main disadvantages to reducing session time-out:
Other Network Access ServicesThe RADIUS design used in this solution can provide authentication, authorization, and accounting services for other network access servers such as 802.1X wired network authentication and VPN and remote access authentication. 802.1X Wired Network Authentication802.1X wired network authentication is the simplest such application requiring no modification of the basic RADIUS design. Organizations that have a widely-distributed wired network infrastructure may find it difficult to control unauthorized use of the corporate network. For example, it is often difficult to prevent visitors plugging in laptops or employees adding unauthorized computers to the network. Some parts of the network, such as data centers, may be designated high security zones and only authorized devices should be allowed on these networks; this could even mean the exclusion of employees with corporate computers. How a wired network access solution would integrate with the design is illustrated in the following figure. The bold–edged box represents the 802.1X wired components and the other boxes contain the relevant services. Compare this figure to figure 2.4. Only the head office is shown in this figure. 802.1X – capable network switches play an identical role to the wireless APs in the core solution and can take advantage of the same RADIUS infrastructure to authenticate clients and selectively authorize access to the appropriate network segment. This has the obvious advantages of centralizing account management in the corporate directory while still retaining network access policies under the control of the network security administrator. VPN and Remote Dial–Up AuthenticationAnother network access service that could use the RADIUS components is VPN and remote dial-up. Particularly in larger organizations, it is likely that some additions would need to be made to the design as it stands, such as the addition of RADIUS proxies. The extended solution is shown in the following figure. The VPN servers, in this variant, play the same functional role as the wireless APs in the core design. They pass the clients' authentication requests to the RADIUS infrastructure. It is possible to have the RADIUS requests passed directly to the internal IAS servers. However, many organizations like to add an additional layer of RADIUS proxies providing an extra security layer and routing the requests to the internal IAS servers. As with wired network security, this solution brings the same advantages of reusing existing infrastructure and centralizing account management. Further enhancements are possible, such as using smart card-based user authentication. The internal remote access VPN solution from Microsoft for the company's own staff uses virtually the same VPN and RADIUS architecture with smart cards for user authentication. Dial-up remote access works in a similar way by using the dial-up server capability instead of the VPN functions of Windows Server Routing and Remote Access. A major advantage that using IAS brings to both VPN and Remote Dial-up is the ability to use Windows Server 2003 Network Access Quarantine Control. Quarantine Control uses capabilities of the Routing, Remote Access Server (RAS) and Windows enhanced remote access client (Connection Manager) to allow and deny access based on the security state of the client computer. It works by performing checks on the client at connect-time; for example, ensuring that the client has up-to-date antivirus software, or that it is running a corporate-approved operating system build. If the client fails these checks, the RADIUS server denies it access to the network. Therefore, even a properly authenticated user and computer may be denied access if they present a possible security threat to the company network. To learn more about the quarantine feature of Windows Server 2003, see the references at the end of the chapter. Bootstrapping Client ComputersMost wireless capable computers also have a wired network interface. This makes it relatively easy for the clients to join the domain and download WLAN settings prior to connecting to the WLAN. However, this may not always be the case. Already, handheld devices have only wireless, and do not have wired network adapters. This presents the problem of bootstrapping a client prior to connecting to the WLAN because it does not have the settings and credentials that it needs to connect to the WLAN. This problem becomes even more difficult if an organization decides to use both wired and wireless 802.1X security, because a client cannot connect to a wired LAN without first having the correct credentials and settings. There are two main approaches to bootstrapping a client computer if you cannot use a wired LAN to retrieve settings and credentials; these are:
Microsoft currently supports only the second option. Microsoft will be releasing a wireless provisioning service that will be suitable for using a "guest" WLAN to bootstrap the client computer WLAN configuration. Until then, manual configuration is a simple way to achieve this. To configure the client computer settings and join it to the domain, the person configuring the computer needs to be a member of the local Administrators group on the computer. To bootstrap a computer using manual configuration:
SOHO EnvironmentsYou may need to deploy WLANs to locations where it is not possible or practical to authenticate users using your IAS infrastructure. For example, home offices for users who regularly work from home or small offices with very unreliable or low bandwidth connectivity to the main corporate network. Previously the only solution to this was to configure static WEP security and hope that no one was determined enough to bother to attack your WLAN. A far better solution is to use WPA in PSK mode. All Wi-Fi certified wireless APs now ship with WPA security although older APs may not support this. You should ensure that your APs support WPA PSK because of the additional security value that it brings. Unlike static WEP, the WPA authentication key is not recoverable from the encrypted traffic; therefore, it is much more difficult for an attacker to break on to the network. You should also ensure that your users are trained to use strong WPA keys and to change them regularly and that understand the security implications of not doing so. To implement WPA PSK, you need a wireless AP, wireless network adapters, and a client operating system (such as Windows XP) that supports WPA. You do not need a RADIUS server or other server infrastructure. SummaryThis chapter began with a description of how 802.1X wireless LAN security works. To provide focus for the design, a picture of the target organization for solution was given along with the organization's key design criteria for the WLAN solution. Following this, the main aspects of the chosen WLAN design were discussed. The design covered the network, IAS server placement and IAS configuration, the use of certificates, and the different types of wireless clients. The key points on migration from an existing WLAN were also outlined. The two sections at the end of the chapter discussed important variations to the basic design. Firstly, how to scale the solution for larger organizations was described, along with instructions on how to deal with the main points of divergence from the core solution. This was followed by illustrations of how to use the same basic authentication infrastructure to support other network services such as remote access, VPN, and wired network security; and how to deal with the sticky problems of bootstrapping clients and deploying WLANs to SOHO environments. The next chapter begins the implementation of the solution by helping you prepare your network, Active Directory, and server security for deployment of WLAN components. ReferencesThis section provides references to important supplementary information or other background material relevant to the content of this chapter.
|
|
