Secure Wireless Access Point Configuration

Midsize Business Security Guidance

Secure Wireless Access Point Configuration Published: August 2006 For the latest information, please see www.microsoft.com/technet/security/midsizebusiness/default.mspx

© 2006 Microsoft Corporation. This work is licensed under the Creative Commons Attribution-NonCommercial License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/2.5/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

Contents Introduction ............................................................................................. 1 Executive Summary .............................................................................. 1 Overview ............................................................................................ 1 Who Should Read This Paper .................................................................. 2 Definition ................................................................................................. 2 Challenges ............................................................................................... 3 Solutions .................................................................................................. 3 Assessing WLAN Security ....................................................................... 4 Benefits of Wireless Networking......................................................... 4 Wireless Networking Vulnerabilities .................................................... 5 Selecting the Right WLAN Security Solution ......................................... 6 WPA or WPA2 ............................................................................... 11 Developing a Secure WLAN Solution ...................................................... 12 The Microsoft Secure WLAN Decision Process ..................................... 12 Certificates .................................................................................. 15 Internet Authentication .................................................................. 17 WPA 802.11 Authentication ............................................................ 24 Deployment and Management .............................................................. 25 Certificates .................................................................................. 25 Internet Authentication .................................................................. 43 WLAN 802.1X Authentication .......................................................... 46 Wireless Access Points and Clients ................................................... 53 Summary ............................................................................................... 56

Introduction Welcome to this document from the Midsize Business Security Guidance collection. Microsoft hopes that the following information will help you create a more secure and productive computing environment.

Executive Summary Wireless local area networks (WLANs) are a controversial topic in the business world; most businesses have either already deployed a WLAN of some sort or have at least debated the pros and cons of wireless technology. Either way, businesses that have deployed wireless networks usually have many concerns about the security of their solution whereas businesses that have shied away from wireless technology worry about the obvious productivity and infrastructure savings they may have missed. Most technology decision makers have been rightfully nervous about the security of wireless technology in the past and even today wireless technology suffers from the stigma of not being secure ever because well publicized flaws were discovered in the first generation of IEEE 802.11 WLAN security protocols. Even though many workarounds have been developed through the years, the typical solutions offered to address wireless security issues have either been too costly or have had their own inherent flaws. Many developments have occurred because those early days of wireless networks and just as the technology have matured to allow for higher speeds and more reliability, so too have the standards used to secure wireless transmissions. The latest wireless security protocols, WPA and WPA2, based on the IEEE 802.11i standard, help provide strong protection for wireless traffic even in the most rigorous security environments. These current standards, when configured properly, are much more secure and can be used with a high level of confidence in a midsized business environment.

Overview This paper consists of four main sections that focus on details that are necessary to design and implement an effective solution for securing a midsize business wireless network. These sections include: •

Introduction. This section provides an executive summary of this paper along with an overview of the document’s framework and information about the recommended audience for this document.

•

Definition. This section provides some details and definitions that are useful for understanding the terminology used in this paper.

•

Challenges. This section describes some of the common issues that midsized businesses deal with when considering wireless networks and provides a backdrop for the solution that this paper was designed to address.

•

Solutions. This section goes into great detail about specific step-by-step guidance that will be used to plan, develop, deploy, and support a secure wireless infrastructure. Hence the solution section is further divided into three main subsections: •

Assessing WLAN Security. This section discusses prerequisite information and potential options to provide a foundation on which to develop a solution plan.

2

Midsize Business Security Guidance

•

Developing a Secure WLAN Solution. This section uses the information learned in the Assessing phase to decide upon and create a plan, and to develop the foundation of the solution.

•

Deployment and Management. This section presents the actual step-by-step solution in detail along with information to assist with the management and validation of the secure wireless network solution outlined by this paper.

Who Should Read This Paper This paper is targeted to midsized business technical staff, technology implementers, and technical managers who are considering using Wi-Fi Protected Access (WPA) or Wi-Fi Protected Access 2 (WPA2) to secure their wireless infrastructure. This document assumes the reader has general technical knowledge regarding wireless devices, basic networking concepts, Microsoft® Windows Server™ 2003, Internet Authentication Service (IAS), Certificate Services, the Active Directory® directory service, and the configuration and application of Group Policy.

Definition The reader should understand and be familiar with the following terms and concepts that are used in this document. AES. Advanced Encryption Standard (AES) uses a symmetric block data encryption technique and is part of WPA2. EAP. Extensible Authentication Protocol (EAP) is an 802.1X standard that allows developers to pass authentication data between RADIUS servers and wireless access points. EAP has a number of variants, including: EAP MD5, EAP-TLS, EAP-TTLS, LEAP, and PEAP. EAP-TLS. EAP Transport Layer Security (EAP-TLS) was developed under the 802.1X standard by Microsoft to use digital certificates for authentication and is currently the industry standard for 802.11i authentication. IEEE 802.1X. The IEEE 802.1X governs the EAP encapsulation process that occurs between supplicants (clients), authenticators (wireless access points), and authentication servers (RADIUS). IEEE 802.11. The IEEE 802.11 standard governs over-the-air network communications and includes several specifications that range from the 802.11g, which provides 20+ Mbps traffic in the 2.4 GHz band, to the 802.11i standard, which governs WPA2 encryption and authentication. IEEE 802.11i. The IEEE 802.11i amendment to the 802.11 standard specifies security methods (WPA2) that make use of AES block cipher to secure origin authentication processes (EAP) to address previous inadequacies in the wireless security standards and specifications. MS-CHAP v2. Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) is a password-based, challenge-response, mutual authentication protocol that uses MD4 and DES encryption. Used with PEAP (PEAP-MS-CHAP v2) to secure wireless communication. PEAP. Protected Extensible Authentication Protocol (PEAP) is a type of EAP communication that addresses security issues associated with clear text EAP transmissions by creating a secure channel encrypted and protected by TLS.

Secure Wireless Access Point Configuration

3

SSID. Service set identifier (SSID) is the name given to a WLAN and used by the client to identify the correct settings and credentials necessary for access to a WLAN. TKIP. Temporal Key Integrity Protocol (TKIP) is part of the WPA encryption standard for wireless networks. TKIP is the next generation of WEP, which provides per-packet key mixing to address flaws discovered in the WEP standard. WEP. The Wired Equivalent Privacy (WEP) is part of the IEEE 802.11 standard and uses 64 or 128 bit RC4 encryption. Serious flaws were found in the WEP standard in 2001, mostly due to the length of the initialization vector of the RC4 stream cipher, which allowed for passive decoding of the RC4 key. WLAN. Wireless local area network. WPA. In response to weaknesses found in the WEP standard the Wi-Fi Protected Access (WPA) was introduced in 2003 as an interoperable wireless security specification subset of the IEEE 802.11 standard. This standard provides authentication capabilities and uses TKIP for data encryption. WPA2. WPA2 was established in September 2004 by the Wi-Fi Alliance and is the certified interoperable version of the full IEEE 802.11i specification ratified in June 2004. Like its predecessor, WPA2 supports IEEE 802.1X/EAP authentication or PSK technology but includes a new advanced encryption mechanism using CounterMode/CBC-MAC Protocol (CCMP) called the Advanced Encryption Standard (AES).

Challenges Many organizations see the benefits of using wireless technology to improve productivity and collaboration but hesitate to implement this technology due to understandable concerns about the vulnerabilities that wireless networks apparently present to an organization’s environment. Even more confounding are the wide variety of suggested methods that can be used to help secure wireless communications and mixed reports as to the effectiveness of these measures. Wireless technology poses many challenges to a midsized business, not only as a matter of securing a deployment, but also a question of whether to deploy it at all. The following are some of the more common issues regarding wireless networking that this paper will address. •

Deciding whether to implement a WLAN

•

Understanding wireless risks and mitigation

•

Determining how to secure a WLAN environment

•

Selecting the right WLAN security options

•

Validating the security level of a wireless network implementation

•

Incorporating existing assets into a wireless security solution

•

Detecting and preventing rogue wireless device connections

Solutions This section describes the design, development, implementation, and support of secure wireless solutions that can be deployed in midsized business environments. As mentioned in previously, there are many concerns about the use of wireless technology. Each of those will be addressed so that the benefits of wireless networking can be taken advantage of as efficiently and safely as possible.

4

Midsize Business Security Guidance

Assessing WLAN Security Although wireless technology has now matured to the point that it is now fast and secure enough to be deployed in a midsized business environment, there are still many different factors to consider and a variety of methods available to secure a wireless network. This section discusses many common methods used to help secure wireless networks, offers guidance to determine the best solution for a particular environment, and provides arguments for and against each approach.

Benefits of Wireless Networking The benefits that can be gained by implementing WLAN technology can be placed within two distinct categories: business benefits and operational benefits. Operational benefits include a lower management cost and reduced capital expenditures whereas business benefits include improved productivity, more efficient business processes, and an increased potential for the creation of new business functions.

Business Benefits Most core business benefits derived from the use of WLAN technology stem from an increase in employee flexibility and mobility. When using wireless networks the workforce is no longer tethered to a desk and can move around the office with relative ease. This kind of freedom can generate the following benefits: •

Members of a business’s mobile workforce, such as sales personnel, can effortlessly move between offices or come in from the field and transparently connect to the business network. Connectivity is nearly instantaneous and occurs without a need to look for a network port or untangle cables, thus saving a great deal of time and reducing the headaches associated with cabled networks.

•

Technical staff can remain in constant contact with the systems they manage no matter where they might be inside the building, even while in meetings or away from their desks. Using portable technology such as laptops, Tablet PCs, or handheld computers, a business’s IT staff can respond instantly to any need.

•

Information is always at everyone’s fingertips. Meetings are no longer delayed when someone has to make copies or retrieve reports from their desk. Presentations are shared at the computer instead of on a fuzzy overhead display and meetings can use interactive technologies to collaborate with remote offices and telecommuters.

•

Organizational flexibility is greatly enhanced because structural changes can be implemented quickly and easily, even entire offices can be restructured because network cabling is no longer an issue.

•

Wireless technology introduces a whole new range of technology applications and solutions to a business environment. Devices such as personal digital assistants (PDAs) and Tablet PCs can be seamlessly integrated into a network environment. Employees and business functions previously off limits to IT can now benefit from network connectivity; lunch rooms, assembly areas, hospital rooms, retail areas, restaurants, and even factory floors can achieve new levels of productivity gains from easily accessible technology solutions.

Secure Wireless Access Point Configuration

5

Operational Benefits The operational benefits of wireless technology are also varied and depend on the specific type of business and the facilities used. Some of these benefits include: •

Network provisioning costs are substantially reduced because the dependency on cabled network infrastructures is diminished. Areas where network connectivity was impractical are now inexpensively accessible through WLAN technology, including outdoor areas or distributed office areas.

•

Network scalability is more responsive and efficient to variable levels of demand because it is far easier to deploy or move wireless access points to different locations to address congestion than it is to increase the number of network ports.

•

The amount of capital tied into facilities infrastructure is reduced because wireless network equipment is not as permanent a fixture as network cable infrastructure. This fact allows for more flexibility in regards to expansions or the need to change office locations for any reason. High-speed wireless (802.11a/g/n) is also a cost-effective alternative to replacing old low-speed Ethernet or Token Ring cabling.

Wireless Networking Vulnerabilities To understand the level of security offered by the various security solutions available to wireless networks it is important to understand the common threats that wireless networks can face. The vulnerabilities and attack profiles that traditional networks must address are widely known, but wireless networks suffer from vulnerabilities that go beyond these traditional risks. Table 1. Typical WLAN Security Threats Threat

Description

Disclosure of data through eavesdropping

Eavesdropping attacks on wireless traffic that is not secure can result in the disclosure of confidential data, discovery of user credentials, and can even lead to identity theft. Sophisticated attackers can use information collected by eavesdropping to mount attacks on systems that would not otherwise be vulnerable.

Interception and modification of transmitted data

An attacker who can gain access to network resources is also capable of inserting rogue systems into a network that can intercept and modify data en-route between two legitimate systems.

Spoofing

Access to an internal network provides an attacker with the opportunity to forge data so that it appears to be legitimate traffic. Such attacks can include spoofed e-mail messages that would be trusted by internal users more readily than communications from outside sources, thus providing a platform for social engineering attacks and Trojan insertions.

Denial of Service (DoS)

No matter what security solution is implemented, a WLAN is uniquely susceptible to DoS attacks whether purposeful or accidental. Such disruptions can be the result of something as simple as a microwave oven or a device set to flood a network with indiscriminate traffic.

6

Midsize Business Security Guidance

Threat

Description

Free-loading (resource theft)

Some intruders might be after nothing more than free access to the Internet. Though not directly malicious or damaging, such activities can result in slower network connectivity for legitimate users or an unmanaged vector for malware threats.

Accidental threats and unmanaged connections

In unsecured WLAN environments any visitor can gain access to the internal network simply by starting up a device that is capable of accessing wireless networks. Such unmanaged devices could already be compromised or supply an attacker with a vulnerable point of attack against a network.

Rogue WLAN access points

Even if a business has no wireless network it can still be vulnerable to security threats from unmanaged wireless networks. Wireless hardware is relatively inexpensive so any employee could possibly set up an unmanaged and unprotected network within an environment.

Although many of these security risks associated with transmitting data over the air are fairly apparent in today’s security-conscious environment, such concerns were not as obvious when the first generation of wireless security technology was established. When WEP was created to secure wireless data broadcasts there seemed to be little need to compensate for the inherent lack of security in comparison with the inherent security that comes with transmitting data over the wire because the technology was so new that few people had considered the possible threats such networks could face. As the methods that attackers use evolved it became clear that data transmission over the air traversed potentially hostile environments and must be secured as such and made as secure as cabled LAN communications. When the WEP security flaws started to become widely publicized, the network security environment was changing rapidly. Stories of War-Drivers were prominent in mainstream media while governments implemented legislation to regulate industries in regard to data and identity security. In response to these developments, many businesses either dismissed wireless technology as unfeasible and unsafe or developed complex workarounds to address the flaws inherent in the WEP standard. Some of these complex workaround solutions are still used and even marketed to this day. However, as the following sections make clear, such complex solutions are no longer required to secure wireless networks against such threats and may need to be reevaluated because wireless technology has matured in response to the changing security landscape.

Selecting the Right WLAN Security Solution Ever since the first generation WLAN technological weaknesses were revealed there has been a great deal of effort to address wireless vulnerabilities. While the wireless industry, Microsoft, and other vendors focused on improving the wireless standard, many other analysts, network security vendors, and others were finding ways to work around the weaknesses in the older wireless standard. This has led to a variety of approaches available to deal with wireless security issues. Aside from the most common approach, which is deciding not to implement WLAN technology, the principle alternatives are compared in the following table.

Secure Wireless Access Point Configuration

7

Table 2. Comparison of WLAN Security Approaches Feature

WPA & WPA2

Static WEP

VPN

IPsec

Strong authentication

Yes

No

Yes, only when not using shared key authentication

Yes, if using certificate or Kerberos authentication

Strong data encryption

Yes

No

Yes

Yes

Transparent connection and reconnection

Yes

Yes

No

Yes

User authentication

Yes

No

Yes

No

Yes

Yes

No

Yes

Protects broadcast and multicast traffic

Yes

Yes

Yes

No

Additional network devices required

Yes, RADIUS servers

No

Yes, VPN and RADIUS servers

No

Yes

No

No

(see Note)

(see Note) Computer authentication (see Note)

Secures access Yes to the WLAN instead of just to the packets

Note Regarding strong authentication, many VPN implementations that employ IPsec tunnel mode use a weak shared key authentication scheme called XAuth. Current versions of the Windows operating system do not support user authentication of IPsec associations but this functionality will be available with Windows Vista and Longhorn. Computer authentication means that the computer will stay connected to the WLAN and LAN even when no user is logged on to the computer. This capability is needed for some domainbased functionality, such as roaming profiles, to work properly.

As this table demonstrates, there are a number of factors to consider when examining the varied possibilities available for securing wireless networks. Such an evaluation involves everything from costs associated with implementation and management to the general security of the solution in question. Each approach has benefits and detractors and so each solution requires a more detailed examination to ensure that an informed decision can be made.

8

Midsize Business Security Guidance

To facilitate a better understanding of the options available for securing WLAN implementations, the following topics are discussed in detail, arranged by the degree of security they provide. •

Not deploying WLAN technology

•

Using WPA with EAP-TLS

•

Using WPA with PEAP-MS-CHAP v2

•

Using WPA with PEAP-MS-CHAP v2, and Certificate Services

•

Using a VPN

•

Using IPsec

•

Using WEP

•

No WLAN Security

Not Deploying WLAN Technology There is a common maxim among security professions that states, “The most secure system is the one that is never turned on.” So the most secure method of deploying any technology, including wireless networking, is never to deploy it. Of course, the problem with this approach is that a business that never uses any technology may find itself uncompetitive in today’s business world in which every advantage, especially in regards to technology, counts. As mentioned previously it is important for every company to assess their own needs, their tolerance for risk, and the amount or risk involved with any technology that is under consideration for adoption, and wireless technology is no different. There are many advantages that wireless networks can offer, but those advantages might be undervalued or not even applicable to a specific organization. When assessing the appropriate wireless security solution for a business, take all options into consideration, including the option not to deploy a wireless solution at all. However, should an organization determine that it is not ready to deploy a WLAN, this decisions should be part of an actively enforced company policy to prevent rogue WLANs from being deployed by end users and thus compromising network security.

Using WPA with EAP-TLS WPA or WPA2 with Extensible Authentication Protocol Transport Layer Security (EAPTLS) with both user and computer certificates is the strongest method of 802.1X authentication supported by current versions of Windows–based wireless clients. EAP-TLS uses digital certificates to provide mutual authentication, in which the wireless client authenticates to the authentication server and vice-versa. EAP-TLS authentication requires a public key infrastructure (PKI) to issue certificates and keep them current. For the highest level of security the PKI should be configured to issue both user and computer certificates for wireless access. Because of the implementation costs and administrative overhead associated with PKIs, this very secure solution used to be limited to midsized or large businesses but can now be used in small business environments due to the introduction of Microsoft Small Business Server, which provides the underlying certificate services that implementing EAP-TLS requires. Note Currently there is no supporting Group Policy objects (GPOs) for the WPA2 standard that can affect the ability to efficiently implement this standard in larger environments. However, updates are being developed for Windows Server 2003 and Windows XP to add GPO support for WPA2. The next generation of Windows, Vista and Longhorn, will have native support for the WPA2 standard.

Secure Wireless Access Point Configuration

9

Using WPA with PEAP-MS-CHAP v2 WPA or WPA2 with Protected EAP (PEAP) and Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) with strong password requirements is the second most effective secure implementation supported by current versions of Windows–based clients. If a PKI deployment is not feasible, PEAP-MS-CHAP v2 is a viable and secure option for deploying a reliable wireless network. PEAP is a one-way authentication scheme that uses TLS to create an encrypted channel from the authentication server, over which the client uses another protocol to authenticate itself. Originally designed for dial-up and VPN remote access, MS-CHAP v2 can support strong password-based authentication of wireless clients but only when used in conjunction with the use of strong user password policies on the network.

Using WPA with PEAP-MS-CHAP v2, and Certificate Services It is possible to combine the use of certificate services with a password-based PEAP-MSCHAP v2 solution for businesses that need elements of both approaches in their solution. However, the addition of PEAP-MS-CHAP v2 does not add any recognized additional security benefit of note to the reasonably secure EAP-TLS solution, as of the writing of this document. In fact, using PEAP-MS-CHAP v2 with EAP-TLS actually slows down the authentication process because it creates two TLS channels, one inside the other. This double encryption provides no added value.

Using a VPN When WEP security flaws were first discovered, one of the first responses proposed by many security experts and industry leaders was to use VPNs to secure wireless networks. VPN technology is certainly a secure and time-tested method of protecting network communications that traverse over hostile networks, like the Internet, and this solution to the problem of WEP flaws is still used in many environments. Although this seems like an advantageous solution from a security standpoint, it suffers from some obvious flaws that make it an unattractive option when compared to the flexibility offered by solutions using WPA, which was designed specifically to address wireless threats. Even though it is quite possible to implement WPA solutions in combination with VPN technology to help secure a wireless network, such a solution provides no advantage over a pure WPA-based solution, especially when factoring in the additional layer of complexity added to a wireless network when a VPN solution is introduced into the mix. Usability is another issue to consider when debating whether to add a VPN as part of a WLAN security solution. Although the additional authentication requirements and time-out limits associated with VPN usage are expected by users when connecting to a business network over the Internet, such extra steps may seem onerous to a user who is used to connecting easily to resources from inside a local area network. Some businesses may want to use this solution simply because they already have a VPN solution in place for remote users and feel it necessary to press more utilization through that system to further justify costs. If this is the case, additional issues should be considered before choosing this route, including the following: •

Because a VPN connection must be established before communication through the tunnel is permitted, computer Group Policy will not apply if the user connects to the VPN after logging on to the local computer. (If the user selects Logon with dialup networking when they log on the computer, the VPN connection completes first, and Group Policy will apply.)

10

Midsize Business Security Guidance

•

Most VPN servers are designed to secure slower connections, such as dial-up or broadband traffic, and may become a network bottleneck when many high-speed connections are established.

•

Depending on the VPN configuration, users may encounter problems when roaming between wireless access points because VPNs will often drop connections after even the briefest of disconnections, which would then require the user to authenticate again manually every time that user passed from one access point to another. The same behavior would occur when a user’s computer went into standby mode.

Using IPsec The use of IPsec to secure wireless networks originated out of the same need as the use of VPNs to secure WLANs, as a workaround for the flaws found in WEP. Of course, IPsec is reliable way to secure many specific kinds of network traffic and has some points for its use on WLANs, among these are its transparency, its independence from WLAN hardware constraints, and its low overhead because it does not require additional servers or software to function. However, there are some problems associated with using IPsec to secure wireless networks, some of which include: •

IPsec is not capable of protecting broadcast or multicast traffic because it only governs the communication between two parties that have mutually authenticated and exchanged keys.

•

IPsec does not protect the wireless network itself, only the network packets.

•

Although IPsec is transparent to users, it is not fully transparent to network devices because it operates at the network layer instead of the MAC layer. This adds additional requirements for firewall rules.

•

Any devices that cannot use IPsec will be vulnerable to probing or attack from anyone who is able to monitor WLAN traffic.

•

IPsec policy management in larger environments can be complicated if IPsec is used to provide end-to-end protection for other applications in addition to wireless network traffic.

Using WEP The most basic form of 802.11-based security is static WEP, which uses a shared key to control access and uses that same key as a base for encrypting wireless traffic. The main attraction of this method is its simplicity and although it does provide a slight increase of security over an unprotected wireless setup, it suffers from some serious management and security problems, namely that it can take anywhere from a couple minutes to a few hours of effort to discover the shared key and SSID (if it isn’t broadcasted) on a WEP WLAN and thus gain access to a network using an ordinary laptop and simple tools readily available on the Internet. One way of improving upon static WEP is to configure access points to allow only a predefined group of clients to access the network by using MAC filtering. However, this approach is also easily attacked by using tools to discover and spoof the MAC addresses of computers attached to a WLAN.

Secure Wireless Access Point Configuration

11

It is possible to use some combinations of security technologies with WEP to increase security somewhat in environments that do not have WPA or WPA2 support, but even these configurations are discouraged except for use during a transition phase between an unsecured WLAN implementation and a secure WPA-based configuration. These methods, in order of most to least secure, are as follows: •

WEP with 802.1X authentication using EAP-TLS with both user and computer certificates and forced periodic reauthentication.

•

WEP with 802.1X authentication using PEAP-MS-CHAP v2 with strong user password policies and forced periodic reauthentication.

No WLAN Security Although implementing an unsecured wireless network should never be recommended for just about any midsized business environment, there are still some select few situations in which an unsecured wireless network configuration may be a preferred solution. For example, many cities and municipalities have considered or even implemented free wireless access zones and in such a situation it may be preferred to use a network of unsecured wireless access points that only provide direct connections to the Internet. However, for all intents and purposes, it should be understood that unsecured wireless networks are incredibly vulnerable to a wide variety of attacks.

WPA or WPA2 The Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access 2 (WPA2) protocols are both designed specifically to address the threats against IEEE 802.11–based wireless networks. However, there are some differences between the two protocols. WPA was developed in 2003 as a response to the security flaws discovered in the WEP standard and addressed those flaws quite well by implementing support for mutual authentication, using TKIP for data encryption, and incorporating a signed message integrity check to thwart spoofing and replay attacks. WPA2 improves upon that security by using AES instead of TKIP to secure network traffic, thus it should always be a preferred over the WPA standard. Both WPA and WPA2 are vastly more secure than WEP and, when properly secured, there are no currently known security flaws for either protocol. However, WPA2 is still widely considered to be more secure than WPA and when possible WPA2 should be used so long as the infrastructure supports it and the additional management overhead can be mitigated. Most wireless access devices made today support are WPA2 certified as are the most recent versions of Windows, specifically Windows XP with Service Pack 2 (SP2) and Windows Server 2003 with SP1. Wireless devices and clients that support WPA2 are also able to use the older WPA standard in case some wireless access points or clients currently deployed in an environment do not support WPA2. Note Windows XP SP2–based clients require an additional update package, the Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) Update, to enable support for WPA2 certification. For more information about this update, see http://support.microsoft.com/default.aspx?scid=kb;en-us;893357. Also, current versions of Windows do not have GPO support for WPA2, which is a considerable management disadvantage that makes WPA2 implementation much more complex than WPA. This may be a determining factor in choosing between WPA or WPA2 because both standards are relatively secure.

12

Midsize Business Security Guidance

Developing a Secure WLAN Solution The previous section helped explain some of the background history surrounding the different WLAN security options available for consideration along with an explanation of the common threats wireless networks face and how each approach either deals with or is vulnerable to those threats. With that information it is possible to make informed decisions in regards to how each options may be applied to specific business environments. The latest security enhancements made to the wireless network standards with the implementation of WPA and WPA2 have addressed the serious flaws in WEP and thus have marginalized the need for workarounds such as using IPsec or a VPN to secure wireless connections. The options of using static or dynamic WEP are not recommended in any form and the use of no security functionality is only useful in few situations. Given these assumptions, there are only a couple options still open to consideration when formulating a comprehensive and efficient security solution for WLAN implementations. This section serves to guide decision makers through the remaining recommended approaches to securing wireless networks. These Microsoft-recommended solutions are widely accepted by industry analysts, security experts, and leading vendors as the most secure methods of implementing a secure and efficient wireless network. Even though this paper will focus on the method that applies best to a midsized business environment, it is still important to consider all the options and step through a decision making process because there are always valid exceptions to the rule.

The Microsoft Secure WLAN Decision Process There are two recommended WLAN security processes to choose from along with a third mixed approach. The two main solutions, arranged by level of security, are: •

WPA2 with EAP-TLS using Certificate Services

•

WPA2 with PEAP-MS-CHAPv2

Aside from the level of security that each provides, the basic deciding factor between these two approaches boils down to resources required to implement and support each solution. WPA or WPA2 with PEAP-MS-CHAPv2 has fewer requirements in terms of technical expertise and equipment because it does not require an underlying certificate infrastructure. Because all devices currently on the market are WPA2 certified and not very cost prohibitive it makes some sense to use devices that support WPA2 even if WPA is selected for use due to the current administrative advantage it has over WPA2. The WPA2 AES encryption method is widely considered to be more secure than WPA’s TKIP and with GPO support for WPA2 planned for future release it makes sense to have the foundation in place for WPA2 implementation in the future. Using WPA or WPA2 with EAP-TLS is the most secure option available for securing a WLAN but has higher implementation and management costs associated due to its reliance on the underlying certificate infrastructure. However, many midsized business environments already have the systems in place that meet the necessary requirements for WPA2 with EAP-TLS so this may actually be a more attractive option for many businesses. Even without the requisite technology in place, many businesses have other needs for the same technology that this solution relies on, certificates and RADIUS, so even then there are some very good business and technical reasons to implement this solution.

Secure Wireless Access Point Configuration

13

Figure 1. The Microsoft WLAN Decision Tree The flowchart in figure 1 has been used in previous guidance from Microsoft to assist organizations in determining which secure WLAN approach was best suited to their environment and makes certain assumptions as to the definition of a large business. When using this flowchart keep in mind that large business should equate to 500 or more employees and an IT staff of at least five technology professionals.

14

Midsize Business Security Guidance

As explained earlier, the decision tree is a bit misleading in this case because many midsized businesses, for which this paper is designed, have the resources and capability to implement WPA2 EAP-TLS with Certificate Services quite easily given the assumption that most midsized businesses have at least five IT professionals on staff and can support the additional infrastructure requirements for a basic EAP-TLS implementation, (four additional servers, one of which will remain disconnected from the network). Given these facts, it becomes clear that the best solution for most midsized businesses is a WPA2 using EAP-TLS with Certificate Services and thus this will be the focus of this paper. However, there are always valid exceptions to the rule and if an organization requires a different approach there are numerous guides to accommodate those needs. Namely, if WPA with PEAP-MS-CHAP v2 is preferred, additional information can be found in Securing Wireless LANs with PEAP and Passwords at http://go.microsoft.com/fwlink/?linkid=23459

EAP-TLS Server Requirements As mentioned briefly earlier, EAP-TLS requires at least four servers, (more if a distributed environment or larger environment demands it), of which two will be used as redundant Internet Authentication Service (IAS) servers (the Microsoft implementation of a Remote Authentication Dial-in User Service) and two will be part of a basic certificate infrastructure (PKI). Of the two certificate servers, the root certification authority (CA) will be stand alone and remain off the network to protect the root certificate. Table 3. Suggested Hardware Requirements for Root CA Server Component

Requirement

CPU

Single 733 MHz or higher CPU

Memory

256 MB RAM

Network Interface

None (or Disabled)

Disk Storage

IDE or SCSI RAID controller. 2 x 18 GB HDD configured as RAID 1 single volume (drive C) Local removable storage for data transfer (root certificate).

As the table shows, the requirements, based on the generic requirements for Windows Server 2003 Standard Edition, for the root CA are quite minimal and can even be built on an older platform that is slated for retirement or created as a virtual machine if need be. Many customers find it effective to use a laptop because it can easily be physically secured in a safe in the computer room. No matter what approach is taken to create the root CA, it is important to make certain that, if needed, the computer in question can be started or restored reliably. The issuing certificate authority hardware requirements are similar but have additional storage requirements and the server does need to be attached to the network. Because this server must store all certificates issued, it is recommended that this server is provisioned with at least 2 GB of hard drive capacity for every 1,000 users. Radius server requirements are more involved because these servers are critical to maintain WLAN functionality and must be able to handle many authentication attempts in brief periods of time. Thus a more robust hardware platform may be required for environments that will have thousands of wireless clients. Also, although the certificate authorities need only use Windows Server 2003 Standard Edition, the IAS servers may need to use Enterprise Edition because Standard Edition is only capable of supporting 50 RADIUS clients.

Secure Wireless Access Point Configuration

15

Due to these reasons, it is a common recommendation for IAS to be installed on domain controllers because this reduces the need for additional server hardware by taking advantage of existing robust server platforms that domain controllers require and using IAS on domain controllers actually increases the performance of IAS by reducing the network traffic that occurs between domain controllers and IAS for user authentication. Failover and redundancy, as well as remote location considerations, also come into play when determining the requirements for RADIUS servers. Although the minimum recommended requirement is for two IAS servers, some businesses may have many remote offices and require IAS servers at some of those locations. Some businesses may also have higher requirements for server redundancy or load balancing. Although there are no recommendations against using multifunction servers as RADIUS servers, it is important to consider the additional load that could be put on such a server and the nature of those demands. A RADIUS server should be capable of scaling to handle a situation in which all wireless clients attempt to connect within a brief period of time.

Certificates No matter which WPA approach is taken to secure a WLAN, certificates are required, in some form, as part of that solution. PEAP only requires certificates on the authentication server thus it would be possible to simply use a third party certificate service to supply the needed certificates, which would mean a PKI implementation would not be needed. This is the main reason that the PEAP approach is recommended for smaller organizations that may lack the expertise or resources to implement and support a certificate infrastructure. The Windows-supported implementation of EAP-TLS using Certificate Services does not necessarily require that there be an underlying PKI to support the issuance of certificates, but because every client must have a certificate to establish authentication with the RADIUS server, the use of third party certificates can be cost-prohibitive to all but the smallest businesses. The same considerations are required for using the combined PEAP with Certificate Services approach as well. If an organization already has a PKI, the decision process is likely somewhat simpler, after all, if the components are already in place they might as well use them and implement the most secure option for WLAN security. Even if there is not an established PKI implementation, a midsized business may still find that investing in a certificate infrastructure might be wise given the other applications such implementations can be used for, which include: •

Code signing

•

Secure e-mail messaging

•

Secure Web content delivery

•

VPN security

•

Encrypted file services

All things considered, the approach of using Certificate Services either with EAP-TLS or PEAP is the best suited approach for midsized businesses and thus is the focus of this paper.

Creating a Certificate Practices Statement Initial planning for a PKI should include the documentation of how certificates will be used in the business environment. Although such decisions can be amended as needs progress, it is important to lay out these decisions in a formal certificate policy statement.

16

Midsize Business Security Guidance

In formal terms, a certificate policy is a set of rules under which the PKI operates. It records information regarding the applicability of certificates to specific organizational groups or applications with common security requirements. A certificate practices statement outlines the practices that a business uses to manage the certificates it issues. It describes how the certificate policy is interpreted in the context of the business systems infrastructure and operating procedure policies. Although a certificate policy is an organization-wide document the certificate practices statement is specific to a CA, although CAs can have a common certificate practices statement if they perform the same duties. For some businesses, these statements are legal documents that must be crafted due to regulatory requirements that govern the industries in which they operate and that require legal assistance to create. However, even if a business is not governed by such requirements it is still a good idea to create such documents.

Certification Authority Hierarchy The design specified in this guide uses a hierarchical trust model with a single internal root. There are a number of advantages and disadvantages to this approach, so further discussion may be necessary to determine if this specific approach is suitable in the business where it will be implemented. For more information about this topic, see the “Designing a Public Key Infrastructure” chapter of the Windows Server 2003 Deployment Kit at http://technet2.microsoft.com/WindowsServer/en/library/b1ee9920-d7ef-4ce5-b63c3661c72e0f0b1033.mspx.

Figure 2. Certification Authority Hierarchy

Securing the Root Certification Authority The Microsoft implementation of EAP-TLS will not function unless the root CA is secured “off the wire”, (unattached to the network). There are some sound security reasons for the use of a stand-alone root CA design such as this instead of a enterprise root CA design and thus it is usually the recommended approach for any PKI implementation.

Secure Wireless Access Point Configuration

17

Because such an approach may seem like a waste of resources, there are some methods a business can use to redeploy at least a portion of the hardware used to create a root CA that will never be attached to the network. Some of these suggestions include: •

After creating and distributing the root certificate to an issuing CA, the hard drives from the root CA can be removed and securely stored until needed again. The drawback to this approach is that if the root CA were to be needed, the corresponding hardware for those drives would need to be reclaimed.

•

After creating and distributing the root certificate to an issuing CA, an image can be taken of the server through backup and saved to tapes or other offline media, allowing the server hardware to be reused. Again, the same problem exists in that if needed again, that hardware would need to be reclaimed.

•

Use a virtual server, virtual PC, or some other sort of virtual machine software to create the root CA, after the root certificate is created and distributed the virtual machine image can be saved to offline storage and archived if ever needed again. If a standard generic platform, (such as the standard desktop system for your organization if it meets the hardware requirements), is used for this approach, it is easier to reclaim needed hardware in case the root CA is needed again.

•

Build the offline root CA on last year’s laptop and store it in a safe in the computer room. This puts to use a hardware resource that would otherwise probably get discarded.

Internet Authentication Internet Authentication Service (IAS) is the Microsoft implementation of a RADIUS and proxy server. IAS can perform centralized authentication, authorization, and accounting for a variety of network connections. IAS can be used with other RADIUS servers as an authentication, authorization, and accounting forwarder, with other VPN servers such as routing and remote access servers, or with other network infrastructure, such as a wireless access points. When developing a deployment plan for an IAS infrastructure, it is important that the value of an IAS-based RADIUS infrastructure is taken advantage of because it is not intended to provide access to a single isolated network. Thus planning and deploying an IAS infrastructure should include a decision about whether to use a centralized service for network access management, including the use of a centralized account database such as Active Directory, and should ensure that present and future organizational needs will be met. In other words, the deployment of an IAS infrastructure should be strategic, not just tactical. This guide will only deal with IAS planning and deployment as it relates to a secure wireless infrastructure. For other IAS planning and deployment possibilities and issues, see the "Deployment Resources" section of the Internet Authentication Service home page at www.microsoft.com/technet/itsolutions/network/ias/default.mspx.

Pre-Existing RADIUS Implementations Even though this solution can be integrated with pre-existing RADIUS implementations, this guide does not provide for such a process. In most cases it would be advantageous to use IAS for the features described in this guide. To achieve this end, it is possible to either upgrade older platforms to Windows 2003 Server to serve as the core RADIUS servers or modify existing RADIUS servers to proxy RADIUS traffic to new Windows Server 2003–based RADIUS servers.

18

Midsize Business Security Guidance

For detailed planning guidance concerning the migration of existing RADIUS infrastructure to Windows Server 2003–based RADIUS servers, see the IAS Technical Reference page at http://technet2.microsoft.com/WindowsServer/en/Library/8f5c89d5fdaf-430c-9ef4-318f8c15baf11033.mspx or contact a Microsoft Account Representative or appropriate Microsoft Consulting Services professional.

RADIUS Server Failover and Load Balancing Because RADIUS is a critical component of any 802.1X wireless security solution, so the availability of a wireless network is dependent on the availability of RADIUS servers. Therefore a RADIUS solution that supports wireless networks must be reliable, responsive, and redundant to ensure availability and performance is equivalent to a wired network and this is why it is a common recommendation for IAS to be installed on existing domain controllers. Before deciding on a load balancing strategy, it is important to understand that 802.1X implements EAP within RADIUS (EAP-RADIUS) between the wireless access point and the RADIUS server. Even though RADIUS uses UDP, EAP is a session-oriented protocol that is tunneled within RADIUS. Which means that the multiple EAP-RADIUS packets comprising a single authentication operation must return to the same RADIUS server or else that particular authentication attempt will fail. There are two approaches available for load balancing and failover on IAS servers in regards to wireless networking. The first is to use IAS proxy servers with RADIUS server groups and the other is to configure primary and secondary RADIUS servers through wireless access point hardware settings. The following table lists the advantages and disadvantages of each approach. Table 4. RADIUS Failover and Load Balancing for EAP Method

Advantages

IAS proxies with RADIUS server groups

•

RADIUS service failure detection • with failover and failback

•

Distribution of traffic load based on traffic properties

•

Maintains EAP session state while load balancing

•

Configurable request distribution to servers based on priority and weight settings

•

Simpler configuration for smaller environments

•

Wireless access point detects traffic failure and performs failover

Primary and secondary RADIUS server settings on wireless access points

•

Uses native wireless access point functionality

Disadvantages Additional IAS servers required

•

Still requires configuration of primary and secondary proxy RADIUS server addresses

•

Requires more planning and monitoring overhead for primary and secondary RADIUS traffic distribution

•

Some wireless access points still do not support failback functionality which can lead to unbalanced traffic loads

Larger business should consider the use of RADIUS proxies configured into RADIUS server groups to distribute loads on RADIUS servers. This provides a degree of flexibility by allowing the distribution of traffic based on a number of configurable items including RADIUS traffic type and RADIUS attributes in addition to weighted and prioritized values. This type of architecture also provides the most flexibility and scalability for servicing authentication requests while being less demanding from an administrative perspective.

Secure Wireless Access Point Configuration

19

The simpler RADIUS server failover functionality built into wireless access points is capable of providing a sufficient level of resilience for most organizations but is not as sophisticated a solution as the use of proxy server groups. However, the migration path from this architecture to a RADIUS proxy server–based failover and load balancing solution is relatively straight forward so this solution also provides for some room to grow. For companies that are only considering small or limited wireless coverage, this solution is easy to implement and effective, however the management and implementation effort grows as does the size and complexity of a wireless network because each device needs careful monitoring and planning to maintain effective load balancing across all servers.

Figure 3. RADIUS WLAN Failover and Load Balancing Methods Load balancing with the built-in functionality of wireless access points involves the configuration of about half the wireless access points in each location to use on primary RADIUS server with another set as secondary whereas the other half of wireless access points use reverse assignments in the primary and secondary fields, as demonstrated in figure 3. The high overhead becomes apparent because there may be more load on some access points than on others so there is a lot of monitoring involved in achieving and maintaining an effective level of load balancing.

RADIUS Logging Requirements IAS servers are capable of logging two types of optional events: •

Successful and failed authentication attempts.

•

RADIUS authentication and account information

20

Midsize Business Security Guidance

Authentication events are generated by devices and users when attempting to access the WLAN and are recorded by IAS in the Windows Server 2003 System Event Log. These events are useful both for troubleshooting and as part of a security auditing and intrusion detection system. These events should be enabled for both success and failure events initially but should be filtered eventually to prevent System Event Log overflow. The use of RADIUS authentication request logging can make the use of these events unnecessary for security purposes if enabled.

Centralized or Distributed IAS Servers A centralized IAS server architecture should be considered as a starting point design for most midsized businesses given that most companies of this size have resilient high speed WAN connections to remote facilities and that RADIUS traffic does not consume much bandwidth because it’s designed to work over WAN links and dial-up connections. A centralized design is also more cost effective so long as an underlying redundant and high-speed WAN infrastructure is already in place. Even still, care must be taken to analyze the current capacity of existing WAN links to determine whether this is the best option because other communication, such as DHCP traffic, could time out while waiting for 802.1X authentication attempts to complete over congested connections. Client connectivity is not the only concern when considering whether to use a centralized IAS architecture because the communication between IAS servers and domain controllers require robust network connections to avoid time-outs while determining network access rights and group memberships. Some businesses may not be in a position to take advantage of a centralized architecture due to the costs associated with redundant high bandwidth WAN connections and the sophisticated network equipment. Such companies will opt to use a distributed IAS design, especially if a decentralized server infrastructure is already in place. Yet another approach is a hybrid of the two which allows for the strategic placement of IAS servers at sites that can support the infrastructure and allowing those servers to supply authentication for branch offices that may not have an underlying server base, as shown in the following figure.

Secure Wireless Access Point Configuration

21

Figure 4. Mixed IAS WLAN Infrastructure Approach This guide accommodates all three models by providing guidance for configuring large hub offices with two RADIUS servers that can service both local and remote requests and guidance for configuring large home offices with optional single server branch offices. Note Again, WLAN access at remote offices without a server infrastructure is dependent on WAN availability.

22

Midsize Business Security Guidance

IAS Server Placement and Co-Location Considerations To maintain accessibility to WLAN services there needs to be at least two RADIUS servers for each independent Active Directory forest. Beyond this basic requirement there are a number of factors that determine how many servers are needed and whether they can be candidates for collocation with other server functions. In general the placement of IAS servers should follow the placement of domain controllers, that is, if an office already depends on a high speed WAN link to another office for domain services, it’s likely that it should use a remote RADIUS server as well. Larger offices that already have their own domain controllers will likely need to have at least one RADIUS server with a possible failover located elsewhere depending on the WAN link available. Care must be taken to assess the WAN link capacity when planning placement of RADIUS servers both for local user authentication reliability and for placement of domain controllers used for authentication due to the extra traffic generated. Also, for improved performance, RADIUS servers should be located in the root domain of a forest to optimize Kerberos operations. Another consideration may involve whether it is even feasible to place additional servers at remote locations when there appears to be a need to do so because some smaller offices may not have the space or infrastructure to support additional server hardware. To address such issues it is possible to co-locate an IAS server with an Active Directory domain controller. The following table describes some advantages and disadvantages to this approach. Table 5. IAS and Domain Controller Co-location Considerations IAS Location

Advantages

Disadvantages

Co-located on domain controller

•

User and computer authentication and authorization performance increases.

•

No separation of IAS administration groups from domain administrators.

•

Reduces the need for additional server hardware.

•

No inherent separation of fault or performance issues associated with colocated services.

•

Separation of IAS administration from domain administrators.

•

Additional server hardware required.

•

IAS load and behavior does not affect the domain controller.

Independent IAS servers

As this table shows, there is a reason why many organizations have existing policies that isolate domain controller functionality to their own servers because they are critical to the network environment. There may also be security concerns associated with placing IAS services on a domain controller when there is a separation of duties involved between both administrative groups because there is no inherent separation of IAS administration from local Windows administrator group functions. Such issues must be considered before deciding on the possibility of co-locating IAS services, but otherwise there are some performance benefits to doing so, let alone the obvious cost benefit, especially at remote locations. To offset the cost considerations involved with adding server hardware to remote offices, it is possible to use existing domain controllers, which may already exist at remote

Secure Wireless Access Point Configuration

23

locations, as IAS servers either directly or with the addition of a virtual machine to the existing domain controller.

Estimating Server Load and Hardware Requirements Assessing and planning for potential server loads should be approached by using worst case scenarios. Specifically, what if all potential WLAN users needed to perform authentication in a short period of time during a failover event? Of course, the optimal design is one that deploys the minimum number of servers required for resilience while still leaving room for future growth as needed. The following information should be considered when planning for IAS server loads and requirements: •

The number of users and devices that require authentication and accounting.

•

The authentication options, such as EAP type, and reauthentication frequency.

•

RADIUS options, such as logging detail and IAS software tracing.

For this solution, using WPA or WPA2 with EAP-TLS certificate services it is important to note that, unlike WEP, WPA and WPA2 alleviate the need for forced reauthentication to refresh session keys thus require less overhead in that regard. It is also important to note that EAP-TLS requires a CPU-intensive public key operation upon each initial authentication but then uses cached credentials for fast reconnect during each subsequent logon until the cached credential expires, which is every 8 hours by default. Also noteworthy is that reauthentication will occur when a client roams from a wireless access point that authenticates to one RADIUS server to a wireless access point that authenticates to another authentication server; this only happens once per each authentication server and is transparent to the user. When estimating IAS server capacity it is helpful to use the number of authentications per second as an estimate of potential loads. The following table shows the estimated authentication per second capacity of an IAS server with Active Directory on an Intel Pentium 4 2-GHz CPU platform. Table 6. Authentications Per Second Authentication Type

Authentications Per Second

New EAP-TLS Authentications

36

New EAP-TLS Authentications with offload card support 50 Authentications with Fast Reconnect

166

Note The information in this table should only be considered an estimate that can be used as a possible guideline for capacity planning purposes.

This table suggests that such a server would be able to process 36 new authentications per second in case of a failover or peak demand event, thus it would take about 3 seconds to authenticate 100 users. Another factor to consider is the effect of disk-based logging on authentication times. A slow disk subsystem can have a negative impact on authentication times when detailed logging is used to track authentication activity. Be sure to use a fast disk subsystem to maintain a reasonable response time on each IAS server.

24

Midsize Business Security Guidance

WPA 802.11 Authentication The use of a certificate infrastructure and RADIUS to secure wireless communications by providing user and device authentication has been covered and now it’s time to discuss how data transmitted between wireless devices is secured from probing and other risks. The use of radio transmissions has always been considered less secure than wired communications because it takes much less effort to intercept data transmitted over the air than it is to tap into a cable or patch panel, especially when port security is used. To counter the inherently insecure nature of wireless communication it is necessary to encrypt the data so that any interception does not yield easily readable information to potential eavesdroppers. The initial WEP specifications for wireless encryption were found to be inadequate for this task and so WPA was created as a stopgap and subset of the 802.11i specification, which was pending at that time. Finally, WPA2 was drafted as the full implementation of the now official 802.11i standard. The primary difference between WPA and WPA2 is in the method of encryption, with WPA using TKIP and WPA2 using the more secure AESCCMP standard. Although the solution provided in this guide can be used to secure WEP or WPA, it is recommended that WPA2 be used to ensure the highest and most reliable form of security available for wireless communication when it is feasible from a management perspective to do so. Otherwise, the use of WPA along with the solution provided in this guide delivers an adequate level of security as well.

Client Requirements The solution outlined in this guide was designed for wireless capable client computers using Windows XP Professional with SP2 or Windows XP Tablet Edition. These versions of Windows operating system offer the built-in 802.1X and WLAN support. Additionally, Windows XP–based clients supply automatic certificate enrolment and renewal functionality, which makes a certificate-based solution such as this particularly cost effective when tied to a certificate infrastructure. Although Windows XP SP2 offers built-in support for WPA, it is necessary to install an additional update to enable IEEE 802.11i WPA2 support on Windows XP SP2–based clients. For more information about this additional update along with download instructions, see Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Service Information Element (WPS IE) update for Windows XP with Service Pack 2 is available at http://support.microsoft.com/default.aspx?scid=kb;en-us;893357.

Server Infrastructure Requirements As discussed previously, this solution requires use of the Certificate Services and IAS components of Windows Server 2003. There are some built-in features supported by the Windows Server 2003 implementation of Certificate Services and IAS that are specific to 802.1X WLANs. Although IAS and Certificate Services can be deployed on older versions of Windows, this guide was written specifically for a Windows Server 2003 Active Directory environment.

Wireless Access Point Requirements This guide focuses on the security element of a WLAN solution, thus there is no guidance for the deployment, positioning, or channel selection for wireless access point hardware. For more information about specific wireless access point hardware issues, configurations, or placement guidance, see the vendor’s instructional material or Web site.

Secure Wireless Access Point Configuration

25

This solution is most secure when using wireless access point hardware that is IEEE 802.11i WPA2–certified and that offer built-in failover/failback functionality. It is possible to implement this solution using WPA-certified equipment without much modification to this guidance and still maintain a very high level of security. However, although it is also possible to implement this solution with the WEP standard, doing so is not recommended and is not supported by this guide.

Deployment and Management Although this section includes step-by-step guidance regarding the installation and configuration of servers and services required for the solution, it does not include the actual installation and configuration steps required for operating systems such as Windows Server 2003 and Windows XP Professional. It is assumed that most businesses have established build processes and hardening guidelines.

Certificates Although this section offers detailed guidance on the installation of a PKI, it does not include any details for a server build and hardening process because it is assumed that there is already an established standardized process in place for these procedures. It is also assumed that the CA servers have already been configured with a base image and hardened per a standard organizational process prior to this phase of the solution. Note Remember that the root CA will never be attached to the network and thus any steps in an organizational server build and hardening process that involve a network connection should be modified to accommodate this exception.

Prerequisite User-Defined Configuration Information The following table lists organization-specific parameters that should be collected or decided upon before beginning a deployment of the solution provided later in this guide. Throughout guide there will be placeholders used to describe settings using a format similar to the setting name. For example, the DNS name of an Active Directory forest root domain might be shown as DomainName.com. The values listed in italic text should be substituted with the specific organizational information gathered during this process. Table 7. User-Defined Configuration Information Configuration Item

Reference

DNS Name of Active Directory Forest Distinguished Name (DN) of Forest Root

Pkiparams.vbs

NetBIOS Name of Domain NetBIOS Name of Root CA Workgroup Server Name of Root CA Server Name of Issuing CA X.500 CN of Root CA X.500 CN of Issuing CA Fully Qualified Host Name of Web Server Used to Publish CA Certificates

Pkiparams.vbs

Setting

26

Midsize Business Security Guidance

Prerequisite Solution Prescribed Configuration Items The settings identified in the following table do not need to be changed unless a different setting is warranted. Make certain that any implications that can occur and any dependencies that may be altered by changing these parameters are fully understood before altering the settings listed here. Table 8. Solution Prescribed Configuration Items Configuration Item

Reference

Setting

Administration Role Security Groups Administrators of Public Key Services ca_setup.wsf configuration container.

Enterprise PKI Admins

Administrative group permitted to publish CRLs and CA Certificates to Enterprise configuration container.

Enterprise PKI Publishers

ca_setup.wsf

Administrative group that configures ca_setup.wsf and maintains CAs and controls the ability to assign all other CA roles and renew the CA certificate.

CA Admins

Administrative group that approves certificate enrollment and revocation requests (CA Officer Role).

ca_setup.wsf

Certificate Managers

Administrative group that manages CA audit and security logs.

ca_setup.wsf

CA Auditors

Administrative group that manages CA backups

ca_setup.wsf

CA Backup Operators

Name of IIS virtual directory used to publish CA certificate and CRL information.

Pkiparams.vbs

pki

Physical path on issuing CA that maps to IIS virtual directory.

C:\CAWWWPub

Pkiparams.vbs

C:\CAConfig

Pkiparams.vbs

IIS Configuration

Common CA Parameters Drive and path for Certificate Services request files Drive and path for Certificate Services database logs.

%windir%\System32\CertLog

Root CA Configuration Root CA key length (see Note)

4096

Root CA certificate validity period (years)

Pkiparams.vbs

16

Maximum validity period for certificates issued by root CA (years)

Pkiparams.vbs

8

Secure Wireless Access Point Configuration

27

Configuration Item

Reference

Setting

Root CA CRL publishing interval (months)

Pkiparams.vbs

6

CRL Overlap Period (days)

Pkiparams.vbs

10

Delta-CRL publishing period for root CA (hours, 0=disable)

Pkiparams.vbs

0

Issuing CA Configuration Drive and path for Certificate Services database.

D:\CertLog

Length of Issuing CA key

2048

Issuing CA certificate validity period (years)

Pkiparams.vbs

8

Maximum validity period for issuing CA certificates (years)

Pkiparams.vbs

4

Issuing CA CRL publishing interval (days)

Pkiparams.vbs

7

CRL overlap period. (days)

Pkiparams.vbs

4

Delta-CRL publishing period for Issuing CA (days, 0=disable)

Pkiparams.vbs

1

Delta-CRL overlap period. (days)

Pkiparams.vbs

1

Miscellaneous Installation scripts path

C:\MSSScripts

Note Using 4096 bit length keys may cause some compatibility issues if they are used by some devices or older software from other vendors. All applications that might use certificates issued by the root CA should be tested with certificate keys of this size to ensure proper functionality. The root CA key length can be reduced to 2048 bits if there are any concerns about key length compatibility.

Installing Configuration Scripts on CA Servers The support scripts supplied with this guidance are to assist with the setup of the solution supplied in the following sections. These scripts must be installed in each CA server and should not be deleted after use to assist with the operation of these servers. To install these scripts first create a folder called C:\MSSScripts and then copy the scripts to that directory.

Installing and Configuring IIS on the Issuing CA Server Internet Information Services (IIS) is used as a download point for non-Windows clients to retrieve CA certificates and CRLs. The root CA does not need to provide this service, especially because it is not supposed to be attached to a network, but the issuing CA should have access to this service IIS can also be used to host the Certificate Services Web enrollment pages, although these are not used in this solution. If the Web enrollment pages are installed on a system other than the issuing CA that server must be marked as “Trusted for Delegation” by setting that property on the server’s computer object in Active Directory.

28

Midsize Business Security Guidance

IIS can be installed using the Windows Optional Components Manager, which is accessed through Add/Remove Components item in Control Panel. The following list shows the components that need to be installed: •

Application Server

•

Enable network COM+ access

•

Internet Information Services

•

Common Files

•

Internet Information Services Manager

•

World Wide Web Service

To install IIS 1. Run the following at a command prompt Sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIIS.txt This command instructs the Optional Components Manager to use the component configurations specified in the C:\MSSScripts\OC_AddIIS.txt unattended installation file, as follows: [Components] complusnetwork = On iis_common = On iis_asp = On iis_inetmgr = On iis_www = On Note Active Server Pages (ASP) are enabled in this configuration file, however, if Certificate Service Web enrollment pages are not needed, ASP should be disabled by deleting the line iis_asp = on prior to running the sysocmgr.exe. This setting can be enabled later if needed.

2. Run the Optional Components Manager again as follows and verify that the installed components match the ones listed previously. sysocmgr /i:sysoc.inf No other subcomponents of Application Server are required and thus do not need to be selected. Configuring IIS for AIA and CRL CDP Publishing on the Issuing CA A virtual directory must be created on IIS to use as the HTTP location for CA certificate and CRL publishing points (referred to as the Authority Information Access (AIA) and CRL Distribution Point (CDP) respectively). To create a virtual directory on IIS 1. Log on to the IIS server with local administrator privileges. 2. Create a folder called C:\CAWWWPub that will contain CA certificates and CRLs. 3. Set security on the folder according to the following table:

Secure Wireless Access Point Configuration

29

Table 9. Virtual Directory Permissions User/Group

Permission

Allow/Deny

Administrators

Full Control

Allow

System

Full Control

Allow

Creator Owners

Full Control (subfolders and files only)

Allow

Users

Read and List folder contents

Allow

IIS_WPG

Read and List folder contents

Allow

Internet Guest Account

Write

Deny

4. Use the IIS management console to create a new virtual directory under the default Web site: •

Name the virtual directory pki

•

Specify C:\CAWWWPub as the path

5. Clear the Run Scripts option at the virtual directory access permissions. 6. Ensure that anonymous authentication is enabled for the virtual directory. Choosing a DNS Alias for the HTTP Publishing Point A generic DNS alias (CNAME) should be created to resolve the IIS server hosting the CDP and AIA. This DNS alias should be used when configuring the CDP and AIA paths for the CAs in subsequent sections. By using aliases, the CA publishing points can be easily moved to other servers or network locations without the need to reissue CA certificates.

Other Configuration and Operating System Component Items In addition to the configuration steps outlined so far there are some other recommended items that may require attention, these include: •

Update Root Certificates Service. The Update Root Certificates Service should be disabled because it is not advantageous to have the root trust of the CAs automatically updated. To remove this service simply run the following at a command prompt: sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_RemoveRootUpdate.txt The OC_RemoveRootUpdate.txt file contains the following lines: [Components] rootautoupdate = off

•

Ensure that the root CA has no network connectivity and that the issuing CA has no inbound or outbound Internet connectivity.

•

Check for additional service packs and updates that may be required because IIS has been installed.

•

Install Windows Server 2003 Support Tools, although not necessary it is helpful to have these tools available for certain CA operations and general troubleshooting.

•

Install CAPICOM. CAPICOM 2.1 is required on the root CA and the issuing CA for some of the setup and management scripts supplied with this guide. For more information about CAPICOM and a link to the download location, see www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5ff88ea5896f6&DisplayLang=en.

30

Midsize Business Security Guidance

Preparing Active Directory for the PKI The fundamental requirements for an Active Directory domain infrastructure that are outlined in this section are based on a Microsoft Windows Server 2003 Active Directory architecture. If the implementation of Active Directory in use is Windows 2000–based, other requirements may be necessary. For more information about additional requirements for a Windows 2000–based domain structure, see How to raise domain and forest functional levels in Windows Server 2003 at http://support.microsoft.com/kb/322692. This solution also requires a minimum domain functional level of Windows 2000 Native Mode, at least for the domain where the CA servers will be installed. The requirement exists because this solution uses Active Directory Universal groups, which are available in Windows 2000 Native Mode and up. Creating PKI and CA Administration Groups This solution defines several security groups that correspond to separate administrative roles. This approach provides a lot of control over delegation for CA administration in conjunction with least privileges security principles. However, there is no other reason that these must be used if they do not correspond with any specific organizational administrative model. To create CA administration groups in a domain 1. Log on to a domain member computer with an account capable of creating user and group objects in the Users container. 2. Run the following command to create the domain CA management groups: Cscript //job:CertDomainGroups C:\MSSScripts\ca_setup.wsf This script will create the security groups listed in the following table. These groups are created as Universal groups in the domain Users container and can be moved to a more appropriate OU as may be required by any organizational policies that may be in place. Table 10. Group Names and Purposes Group Name

Purpose

Enterprise PKI Admins

Administrators of the Public Key Services configuration container.

Enterprise PKI Publishers

Allowed to publish CRLs and CA certificates to the Enterprise configuration container.

CA Admins

Have full administrative capability over the CA, including the ability to determine the membership of other roles.

Certificate Managers

Manage certificate issuance and revocation.

CA Auditors

Manage audit data for the CA

CA Backup Operators

Have permissions to back up and restore CA keys and data.

The setup procedures in the remainder of this document require the use of accounts that are members of the Enterprise PKI Admins, Enterprise PKI Publishers, and CA Admins so these groups should be populated with the appropriate accounts before continuing. If there is only one person responsible for all CA-related roles, a single account could be assigned to all groups, however, most businesses do have some degree of separation of roles and duties among staff, though not as complex as those listed in the previous table.

Secure Wireless Access Point Configuration

31

For those businesses that have a simplified separation of duties, the following chart lists common responsibility divisions. Table 11. Simplified Administration Model Administrative Role

Group Membership

CA Administrator

Enterprise PKI Admins, CA Admins, Certificate Managers, Administrators

CA Auditor

CA Auditors, Administrators

CA Backup Operator

CA Backup Operators

Suggested Domain OU Structure There are a number of groups and user accounts that will be associated with the management and operation of a PKI. Depending on the established policies in place it may be necessary to organize these groups and users into a specific OU structure. Because this structure may be dictated by already existing company guidance, the following is a suggested structure which can be modified as needed. To create a Certificate Services OU hierarchy 1. Log on with an account that has permissions to create OUs and delegate permissions within those OUs. 2. Create an OU structure based on the following table: Table 12. Example OU Structure Organizational Unit

Purpose

Certificate Services

Parent OU

\-Certificate Services Administration

Contains administrative groups for managing CAs and Enterprise PKI configuration.

\-Certificate Template Management

Contains groups for managing individual certificate templates.

\-Certificate Template Enrollment

Contains groups that have Enroll or Autoenroll permissions on templates of the same name. Control of these groups can be delegated to the appropriate personnel without modification of the templates themselves.

\-Certificate Services Test Users

Contains temporary test accounts.

3. Grant permissions to the Enterprise PKI Admins group to create and delete groups within the Certificate Services OU and its child containers. Granting Permissions to the Public Key Services Container The security for the Public Key Services container needs to be altered to enable Enterprise PKI Admins to install Enterprise CAs and to configure certificate templates without requiring that group’s accounts be members of the Enterprise Admins group. This is also necessary to allow Enterprise PKI Publishers to publish certificate revocation lists and CA certificates without needing Enterprise Admin rights. To make the following changes, an Active Directory Enterprise Admin equivalent account will need to be used.

32

Midsize Business Security Guidance

To grant permissions to Enterprise PKI Admins 1. Log on as a member of the Enterprise Admins security group. 2. In the Active Directory Sites and Services MMC snap-in, display the Services node from the View menu, then browse to the Public Key Services subcontainer and open its properties. 3. On the Security tab add the Enterprise PKI Admins security group and grant Full Control to this group. 4. In Advanced view, edit the permissions of this group to ensure that Full Control applies to this object and all child objects. 5. Select the Services container and open its properties. 6. On the Security tab, add the Enterprise PKI Admins security group and grant Full Control to this group. 7. In Advanced view, edit the permissions of this group to ensure that Full Control applies to this object only. To grant permissions to Enterprise PKI Publishers 1. Log on as a member of the Enterprise Admins security group. 2. In the Active Directory Sites and Services MMC snap-in, display the Services node and open the properties for the Public Key Services\AIA container. 3. On the Security tab, add the Enterprise PKI Publishers security group and grant the following permissions to this group: •

Read

•

Write

•

Create All Child Objects

•

Delete All Child Objects

4. In Advanced view, edit the permissions of this group to ensure that the permissions are applied to this object and all child objects. 5. Repeat steps 2-4 for the following containers: •

Public Key Services\CDP

•

Public Key Services\Certification Authorities

Granting Permissions to the Cert Publishers Group All Enterprise CA computer accounts in the domain will reside within the Cert Publishers security group. This group will be used to apply permissions to user and computer objects and to the objects in the CDP container mentioned in the previous procedure. Whenever a CA is installed, its computer account will need to be added to this group. To allow members of the Enterprise PKI Admins group to install enterprise CAs, the permissions on this group must be changed. To grant the modify membership permissions on Cert Publishers 1. Log on as a member of Domain Admins for the domain in which issuing CAs will be installed. 2. Open the Active Directory Users and Computers MMC snap-in. 3. From the View menu of the MMC, ensure that Advanced Features is selected. 4. Locate the Cert Publishers group (in the Users container by default) and view the properties of the group.

Secure Wireless Access Point Configuration

33

5. From the Security tab, Add the group Enterprise PKI Admins and click the Advanced button. 6. Select the group Enterprise PKI Admins from the list and click the Edit button. 7. Select the Properties tab and ensure that This Object Only is selected in the Apply onto box. 8. Scroll down and click the Write Members box in the Allow column. 9. Save changes and close each dialog box by clicking OK for each one. 10. Restart the issuing CA server before installing the Certificate Services component. A restart will allow the server to pick up the new group membership in its access token. Granting Restore Permissions to Enterprise PKI Admins The Certificate Services installation process requires the user right to Restore Files and Directories for the domain in which the Enterprise CA will be placed. Specifically, this right is required to allow security descriptors on the templates and other directory objects to be merged, thus granting the correct permissions to the domain PKI objects. The builtin Administrators, Server Operators, and Backup Operators domain groups have this right by default. Because the Enterprise PKI Admins group will be used to install the CA the Restore Files and Directories user right will need to be granted to this group. To grant the Restore rights to Enterprise PKI Admins 1. Log on as a member of Domain Admins within the domain in which the issuing CA will be installed. 2. Open the Active Directory Users and Computers MMC snap-in. 3. Select the Domain Controllers OU and open the properties of that OU. 4. On the Group Policy tab, select the Default Domain Controllers Policy GPO and then click Edit. 5. Browse to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment and double-click Restore Files and Directories. 6. Add the group Enterprise PKI Admins to the list shown. 7. Close the dialog box and the GPO editing MMC. Note If there are any other GPOs that set the Restore Files and Directories user right on the domain controllers this procedure must be performed on the GPO with the highest priority rather than on the Default Domain Controllers Policy. User rights settings are not cumulative and only the last applied GPO that has this right set will be effective.

Deploying a Root Certificate Authority Server As mentioned previously, this guide does not offer step-by-step instructions for installing Windows Server 2003 because most businesses already have a documented server build process. However, root CA servers are somewhat different than other servers in that they should never attach to a network to ensure that they are never compromised. Thus it is important to ensure the root CA server is not attached to the network during the build process and that at some point the network adapters are disabled to ensure that there is never an accidental attachment. It is also important to note that because the server will not be attached to the network, it will reside in a workgroup and that workgroup name should be chosen and documented before installation. Note Even though the root CA is built and kept offline, it is important that its name be unique within the network environment.

34

Midsize Business Security Guidance

CAPolicy.inf File After appropriating the requisite server hardware for a root CA server and installing the operating system, the next step should be the creation of a capolicy.inf file. The capolicy.inf file is necessary to create a root CA because it specifies the characteristics of the self-signed root CA certificate, such as the key length and certificate validity period. CRL and AIA information are not required for a root CA certificate so the CRLDistributionPoint and AuthorityInformationAccess parameters are set to Empty in the capolicy.inf file. To create a CAPolicy.inf file 1. Using a text editor, such as Notepad, create a plaintext file with the following text: [version] Signature=”$Windows NT$” [Certsrv_server] RednewalKeyLength=4096 RenewalValidityPeriod=Years RenewalValidityPeriodUnits=16 [CRLDistributionPoint] Empty=true [AuthorityInformationAccess] Empty=true 2. If there is a certificate practices statement (CPS) defined for this CA, include the following in the capolicy.inf file, substituting the italicized values for ones specific for this implementation: [CAPolicy] Policies=company CPS name [company CPS name] OID=the.company.OID URL=”http://www.companyurl.com/cpspagename.htm” 3. Save this text file as %windir%\Capolicy.inf (replace %windir% with the absolute path of the folder where Windows is installed, such as C:\Windows). An administrator or account with equivalent permissions must be used to save the file in the Windows folder to complete this step. Installing Certificate Services Software Components Use the Windows Components Wizard to install the CA software components. Please note that the Windows Server 2003 installation media will need to be accessible to complete this installation.

Secure Wireless Access Point Configuration

35

To install Certificate Services 1. Log on as a member of the local Administrators group and run the Optional Components Manager or via the Control Panel use Add/Remove Programs/Windows Components. sysocmgr /i:sysoc.inf 2. Select the Certificate Services component (click Yes to dismiss the rename warning.) 3. Select the CA type as Stand-Alone Root CA and ensure that the Use Custom Settings box is selected. 4. Leave the settings at the default values in the Public and Private Key Pair dialog box except for the key length field, which should be set to 4096 and the CSP Type which should be set as Microsoft Strong Cryptographic Provider. 5. Enter the Certificate Authority identifying information as gathered in the prerequisite phase for the following fields: •

CA Common Name:

•

Distinguished Name Suffix:

•

Validity Period: 8 Years

At this point the CSP generates the key pair and it is written to the local computer key store. Note If a CA was previously installed on this system, a dialog box will warn about overwriting the private key of the previous installation. Ensure that this key will never be needed again before proceeding.

6. Leave the locations of the certificate database, database logs, and the configuration folder at their default values. At this point the Optional Component Manager will install Certificate Services components and the Windows Server 2003 installation media will be needed. 7. Click OK to dismiss warnings about IIS and continue the installation to completion. Configuring the Root CA Properties A number of environment-specific parameters will be used when configuring the root CA as outlined in this section. These parameters should have been collected as described earlier in the prerequisite information section of this guide prior to continuing. To configure the root CA properties 1. Log on to the CA Server as a local Administrator group member. 2. Customize the C:\MSSScripts\pkiparams.vbs script to include the following: •

Change the value of the AD_ROOT_DN setting to match the Active Directory forest root domain DN.

•

Change the HTTP_PKI_VROOT setting to match the HTTP path to the IIS virtual directory which was set up earlier.

3. Run the following script: Cscript //job:RootCAConfig C:\MSSScripts\ca_setup.wsf

36

Midsize Business Security Guidance

Configuring Administrative Roles The security groups created earlier will need to be mapped to administrative roles, such as auditor and certificate manager, to be used. Note Although most midsized businesses will likely use the simplified delegation model mentioned earlier in this guide, the more flexible model is shown here in case more separation is required.

To configure root CA administrative roles 1. Click Properties on the Certificate Authority Management Console. 2. Click the Security tab and add the local security groups listed in the following table and add the permission shown for each. Table 13. CA Permission Entries Group

Permission

Allow/Deny

CA Admins

Manage CA

Allow

Certificate Managers

Issue and Manage Certificates

Allow

3. Other CA security roles for this server have already been defined through the security policy applied earlier. Transferring the Root CA Certificate and CRL to Disk The root CA Certificate and CRL must be copied from the CA so that they can be published to Active Directory and the IIS Certificate and CRL publishing server. Although this example cites the use of a disk, any portable media can be used, including USB drives. To copy the root CA certificate and CRL to disk 1. Log on to the root CA as a member of the local CA Admins group and insert the portable media into the server. 2. Run the following script to copy the CA certificate to disk: Cscript //job:GetCACerts C:\MSSScripts\CA_Operations.wsf 3. Run the following script to copy the CA CRL to disk: Cscript //job:GetCRLs C:\MSSScripts\CA_Operations.wsf 4. Label, date, and retain this disk for later use.

Publishing the Root CA Information Prior to installation of the issuing CA, the root CA’s certificate must be published to the Active Directory trusted root store and the root CRL must be published to the Active Directory CDP container. This process will cause all domain members to import the root CA’s certificate into their own trusted root stores which will enable them to verify the revocation status of any certificate issued by the root CA. It is best to use the issuing CA to perform this procedure because it has the requisite Certutil.exe, certadm.dll, certcli.dll libraries installed, but any member server could be used so long as the certutil.exe and supporting DLL files are installed on that Windows Server 2003–based system.

Secure Wireless Access Point Configuration

37

To publish the root CA certificate and CRL to Active Directory 1. Log on to a domain member computer that meets the previously stated requirements as a member of the Enterprise PKI Admins group and insert the disk that was created to store the root CA certificate and CRL. 2. Run the following script to publish the CA certificate to Active Directory Cscript //job:PublishCertstoAD C:\MSSScripts\CA_Operations.wsf 3. Run the following script to publish the CRL to Active Directory Cscript //job:PublishCRLstoAD C:\MSSScript\CA_Operations.wsf Publishing the Root CA Certificate and CRL to the Web Server This task is required because HTTP versions of the CDP and AIA URLs are specified in the extensions of certificates issued by this CA. If these extensions are present they must be honored by the publishing CRLs and certificates to the URLs configured within. Note This procedure is not dependent on whether the CDP and AIA publishing Web server is on the issuing CA, however it does assume that the Virtual directory matches the one set up previously to configure IIS (C:\CAWWWPub). If a different path was chosen then the WWW_LOCAL_PUB_PATH value in the PKIParams.vbs script will need to be modified.

To publish the root CA certificate and CRL to the Web URL 1. Log on to the Web server as a local administrator or equivalent account. 2. Ensure that the root CA certificate and CRL disk is inserted. 3. Run the following script to publish the CA certificate to the Web server folder: Cscript //job:PublishRootCerttoIIS C:\MSSScripts\CA_Operations.wsf 4. Run the following script to publish the CA CRLs to the Web server folder: Cscript //job:PublishRootCRLstoIIS C:\MSSScripts\CA_Operations.wsf

Deploying an Issuing Certification Authority Server Now that the root CA has been installed and its certificates have been published the issuing CA server can be deployed. Installing Certificate Services involves a complex set of interactions between the issuing CA, the root CA, Active Directory, and the Web server. These interactions can be easier to follow by using the following diagram as a reference.

38

Midsize Business Security Guidance

Figure 5. Certificate Installation Process The numbered interactions shown in this diagram are: 1. Publish the root CA certificate and CRL to Active Directory using removable media. 2. Publish the root CA certificate and CRL to the Web server using removable media. 3. Install the Certificate Services software, which generates a certificate request that will need to be delivered to the root CA using removable media where a certificate will be issued based on that request. 4. Install the corresponding issuing CA certificate using removable media. 5. Publish the issuing CA certificate and CRL to the Web server. x.

This step occurs automatically during the Enterprise CA installation routine.

Preparing the Capolicy.inf File for the Issuing CA Although a CAPolicy.inf file is not required for the issuing CA, it is necessary if the key size used by the CA needs to be changed. This file should be created before the issuing CA is set up even though one can be added later and then renew the CA certificate, if need be.

Secure Wireless Access Point Configuration

39

To create a CAPolicy.inf file 1. Log on to the issuing CA server with a local Administrator account or equivalent. 2. Use a text editor, such as Notepad, to create a plaintext file with the following information: [Version] Signature= “$Windows NT$” [Certsrv_Server] RenewalKeyLength=2048 3. If a CPS is defined for this CA, include the following lines in the Capolicy.inf file: [CAPolicy] Policies=policyname [policyname] OID=the.org.oid URL=”http://the.org.url/TheCPSPage.htm” Note

Items in italics will need to be replaced with organization-specific information.

4. Save the file as %windir%\Capolicy.inf (replace %windir% with the absolute path to the Windows installation folder, such as C:\Windows). Installing the Certificate Services Software Components As was the case with installing certificate services on the root CA, so too will this step require use of the Windows Server 2003 installation media along with use of the Windows Components Wizard. To install Certificate Services 1. Log on to the issuing CA as a member of the local Administrators group or equivalent and run the Optional Components Manager: sysocmgr /i:sysoc.inf 2. Select the Certificate Services component and click OK to dismiss the rename warning message box. 3. Select the CA type as Enterprise Subordinate CA and ensure that the Use custom setting check box is selected. 4. Leave the default settings in the Public and Private Key Pair dialog box except for: •

Key Length – 2048 bits

•

CSP Type – Microsoft Strong Cryptographic Provider

5. Enter the Certificate Authority identifying information as follows: •

CA Common Name

•

Distinguished Name Suffix

•

Validity Period: (as determined by parent CA)

6. The CSP will generate a key pair at this point and write it to the local computer key store.

40

Midsize Business Security Guidance

7. Enter the locations of the certificate database, database logs, and configuration as suggested in the following: •

Certificate Database: D:\CertLog

•

Certificate Database Log: %windir%\System32\CertLog

•

Shared Folder: Disabled

The CA database and logs should be stored on physically separate volumes when possible for performance and resiliency reasons. The certificate database and database logs must both reside on local NTFS formatted drives. 8. At this point a certificate request file is generated which should be copied to a disk. The Optional Component Manager will then install the Certificate Services components which require access to the Windows Server 2003 installation media. 9. Click OK to dismiss the warning about IIS and continue the installation until completion. The setup wizard will display a notice that a certificate from the parent CA will be needed before continuing. Submitting the Certificate Request to the Root CA At this point the issuing CA certificate request must be taken to the root CA for the request to be signed and a certificate issued to the issuing CA. To submit the certificate request to the root CA 1. Log on to the root CA with a Certificate Managers group member account. 2. Ensure that the disk used to store the certificate request file is in the drive. 3. From the CA Tasks menu in the Certification Authority management console select Submit New Request and then submit the request transferred from the issuing CA. 4. Locate the newly issued certificate in the Issued Certificates container and open it. 5. Verify that the Certificate details are correct and then export the certificate to a file by clicking Copy to File. Save this file to a disk as a PKCS#7 file and select the option to include all possible certificates in the chain. Refreshing Certificate Information on the Issuing CA The root CA certificate has already been published to the trusted root store of Active Directory and now it should be verified that the issuing CA has downloaded this information and placed the certificate into its own root store. To refresh and verify the certificate trust information on the Issuing CA 1. Log on to the issuing CA as a local administrator or equivalent account. 2. Run the following at a command prompt: certutil –pulse This command will force the CA to download the new trusted root information from the directory and place the root CA certificate into its own trusted root store. Although this step is not necessary, it does act to verify that the earlier publishing steps were successful before continuing. 3. Run mmc.exe and add the Certificates snap-in. 4. Select Computer Account as the certificate store to manage. 5. Ensure that the root CA certificate is in the Trusted Root Certificate Authorities folder.

Secure Wireless Access Point Configuration

41

Installing the Certificate on the Issuing CA The signed response from the root CA has been created as a PKCS#7 certificate package and is now ready to be installed on the issuing CA. To publish the CA certificate to the Active Directory NTAuth store, which identifies the CA as an Enterprise CA, the CA certificate must be installed using an account that is both a member of the Enterprise PKI Admins group and the local Administrators group on the issuing CA. The former group has rights to install the CA certificate to the directory and the later group has rights to install the certificate to the CA server. If the simple administration model mentioned earlier is in use then the CAAdmin role is already a member of both groups. To install the issuing CA certificate 1. Log on to the issuing CA using an account that is a member of both the Enterprise PKI Admins group and the local Administrators group. 2. Insert the disk containing the signed certificate issued by the root CA. 3. Select Install Certificate from the CA Tasks menu in the Certificate Authority management console to install the issuing CA certificate from the disk. The CA should start up at this point. Configuring the Issuing CA Properties The following procedure will configure the environment specific parameters collected during the prerequisite section on the issuing CA. Prior to continuing this step it is important to make certain that the organization specific information collected in the prerequisite steps has been inserted into the C:\MSSScripts\pkiparams.vbs file on the root CA and that these changes have also been transferred to the issuing CA. To configure the issuing CA properties 1. Log on to the issuing CA server as a member of the local Administrators group. 2. Verify that the changes made to the C:\MSSScripts\pkiparams.vbs match the environment specific settings outlined earlier in this section. 3. Run the following script: Cscript //job:IssCAConfig C:\MSSScripts\ca_setup.wsf Configuring the issuing CA Administrative Roles To use the administrative roles that this guide describes, they must be mapped to security groups. As mentioned previously, even though the simplified roles would be sufficient for most midsized businesses this process will implement the detailed roles designed for maximum flexibility and separation of responsibilities. To configure roles on the issuing CA 1. Log on to the issuing CA server as a member of the local Administrators group. 2. Click properties from the Certification Authority management console to edit the properties of the CA. 3. Click the Security tab and add the domain security groups listed in the following table and add the permissions as shown for each.

42

Midsize Business Security Guidance

Table 14. Issuing CA Permissions Group

Permission

Allow/Deny

CA Admins

Manage CA

Allow

Certificate Managers

Issue and Manage Certificates

Allow

4. The CA Auditors group should be added to the local Administrators group even though this group has already been partially defined through the security policy applied earlier.

Publishing the Issuing CA Information Although certificates and CRLs are automatically published from the issuing CA to Active Directory the publication of the CA certificate and CRLs to the HTTP CDP and AIA paths is not. To automate the publishing of the CA certificate to the HTTP CDP and AIA paths there must be a scheduled job to perform that task. CA certificates are updated very rarely so they can be published to the AIA manually by using the following process. To publish the issuing CA certificate 1. Log on to the issuing CA with an account that has permissions to write to the published Web server folder. 2. Update the WWW_REMOTE_PUB_PATH parameter in C:\MSSScripts\PKIParams.vbs to match the destination path of the Web server folder. a. If the Web server is on a remote server, ensure that the Web server folder is shared and record that UNC path for the shared folder. b. If the Web server is on the same server as the CA then record the local path to that folder. (default is local path C:\CAWWWPub) 3. Run the following script to publish the CA certificate to the Web server: Cscript //job:PublishIssCertsToIIS C:\MSSScripts\CA_Operations.wsf Note This procedure is designed with internal Web servers in mind. If the certificates are to be published to an Internet-facing Web server, additional steps will need to be performed because this solution relies on Windows network file sharing, which is usually blocked on Internet firewalls.

CRLs are published more frequently than CA certificates so an automated method of publishing these to the Web server is required. To automate the publication of CRLs 1. Log on to the issuing CA with an account that is member of local Administrators 2. Ensure that the Web server folder is accessible from this server. 3. If the Web server is remote, the issuing CA will require write access to the file system folder (allow Modify access) and to the share (allow Change access). If the remote Web server is a member of the forest, the domain Cert Publishers group should be used to grant access to ensure that any Enterprise CA can publish certificates and CRLs.

Secure Wireless Access Point Configuration

43

4. Create a scheduled job to copy the CRLs by running the following command: schtasks /creat /tn “Publish CRLs” /tr “cscript.exe //job:PublishIssCRLsToIIS C:\MSSScripts\CA_Operations.wsf” /sc Hourly /ru “System” Removing Unwanted Issuing CA Templates It is generally best practice to remove templates that correspond to any type of certificate that will not be used so that they cannot be issued accidentally. These templates can easily be re-created if needed as they are always available in the directory. To remove unwanted templates from the issuing CA 1. Log on as a member of the CA Admins domain group. 2. Select the Certificate Templates container in the Certificate Authority management console. 3. Remove the following template types: •

EFS Recovery Agent

•

Basic EFS

•

Web Server

•

Computer

•

User

•

Subordinate Certification Authority

•

Administrator

Internet Authentication This section provides detailed information that will assist with the implementation of a RADIUS infrastructure to support the secure WLAN solution provided for by this guide. The RADIUS infrastructure implemented in this guide is based on Windows Server 2003 Internet Authentication Servers (IAS).

RADIUS Infrastructure Design The following tables can be used as worksheets in which to gather the prerequisite information that will be referred to throughout the guide. Some of this information is set using scripts that come with this guidance or manually as listed in the appropriate sections where they apply. Prerequisite User-Defined Configuration Information The following table lists information that is specific for each different organization. Ensure that the information is collected, decided upon, and recorded before continuing further. Table 15. User-Defined Configuration Settings Configuration Item DNS name of Active Directory forest root domain NetBIOS name of domain Primary IAS server name Secondary IAS server name

Setting

44

Midsize Business Security Guidance

Prerequisite Solution-Defined Configuration Information The following table lists settings that do not need to be changed unless there is a specific need to do so. Ensure that the implications and dependencies caused by any changes are completely understood and planned for before changing any of these parameters, including script changes that would be required. Table 16. Solution-Defined Configuration Settings Configuration Item

Setting

Full name of the Administrative group that controls the IAS configuration

IAS Admins

Full name of the group that reviews IAS authentication and accounting request logs

IAS Security Auditors

Path for installation scripts

C:\MSSScripts

IAS configuration export batch file

IASExport.bat

IAS configuration import batch file

IASImport.bat

IAS RADIUS client configuration export batch file

IASClientExport.bat

IAS RADIUS client configuration import batch file

IASClientImport.bat

Path for configuration backup files

D:\IASConfig

Location of IAS authentication and auditing request logs

D:\IASLogs

Share name of RADIUS request logs

IASLogs

IAS Server Deployment The solution detailed in subsequent sections includes two centrally located IAS servers configured as RADIUS servers for WLAN access control. With this in mind, the following tasks should be completed before continuing forward. •

Server hardware should be allocated and configured.

•

Server operating system should be installed and configured per any established organizational procedures.

•

Active Directory should be in place and functioning normally.

•

Organizational server hardening procedures and additional applications required by established policies should be in place.

Installing the Configuration Scripts Numerous support scripts have been supplied with this solution to help simplify its implementation. These scripts must be installed on each server before continuing and they should not be deleted, even after completing the steps outlined in this guide. To install the setup scripts 1. Create a folder called C:\MSSScripts 2. Copy the scripts from the distribution source to the folder created above.

Secure Wireless Access Point Configuration

45

Additional Server Software Requirements In addition to the server operating system and any other applications that may be required per an established server build policy, the CAPICOM 2.1 executable and supporting DLL library needs to be installed to support the scripts that this guide supplies. For more information about CAPICOM, including the download location and installation instructions, see www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843462f-abb5-ff88ea5896f6&DisplayLang=en Configuring IAS Administration Groups The following script command will create the IAS Admins and IAS Security Auditors security groups: Cscript //job:CreateIASGroups C:\MSSScripts\IAS_Tools.wsf In multi-domain environments these groups should be created in the same domain in which the IAS servers will reside. After creating the required groups they must be configured to be able to perform IAS configuration tasks by doing the following: •

Add the IAS Admins domain global group to the local Administrators group on each IAS server.

•

If IAS is installed on domain controllers, the IAS Admins group must be added to the Administrators group for the domain.

•

The IAS Admins and IAS Security Auditors groups need to be populated with the appropriate user accounts.

Configuring Server System Security Settings As mentioned previously, this guide assumes that most midsized businesses have established server hardening procedures and policies in place. For this reason there is no in-depth instruction concerning the process of securing the servers required by this solution. If there are no established policies or procedures for server hardening, or if more information about securing IAS servers is required, see the Windows 2003 Security Guide at http://go.microsoft.com/fwlink/?LinkId=14846.

Installing and Configuring IAS The following section describes how to install IAS onto servers. It is important that each installation and configuration step is performed as listed on each IAS server. IAS is installed by selecting the Network Services – Internet Authentication Service component in the Windows Optional Components Manager (accessible through the Add/Remove Components item in Control Panel). To simplify this process, use the following script: sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIAS.txt Registering IAS in Active Directory IAS servers must be registered in each domain by making the computer account of each IAS server a member of the RAS and IAS Servers security group within each domain where they will be required for authentication. Membership in these groups will ensure that the IAS servers have permission to read the remote access properties of all user and computer accounts in the domains.

46

Midsize Business Security Guidance

To register IAS in Active Directory 1. Log on to each server with an account that has Domain Admin privilege for the domains where the IAS server needs to be registered. 2. For the default domain run the following at a command prompt: netsh ras add registeredserver 3. For domains other than the default domain run the following at a command prompt: netsh ras add registeredserver domain = DomainName Note Alternatively the IAS Server computer object can be added into the RAS and IAS Servers security groups through the Active Directory Users and Computers MMC snap-in.

Creating and Securing IAS Data Directories There are some directory requirements for storing configuration and log data on IAS servers. To ease the configuration process for creating and securing these directories, the following batch file can be used at the command prompt: C:\MSSScripts\IAS_Data.bat Note It may be necessary to edit and replace the %DomainName% entries to reflect the NETBIOS domain name of the specific environment in this batch file prior to running.

Configuring the Primary IAS Server The server selected to act as a primary IAS server will need to be configured prior to any other IAS server in the environment because it will serve as a template for configuring the settings on all subsequent IAS servers. Logging Authentication and Accounting Requests IAS does on log RADIUS authentication and accounting requests by default but both should be enabled to ensure that security events are recorded and can be used in case an investigation is necessary. To configure authentication and accounting request logging 1. Select Remote Access Logging in the Internet Authentication Service MMC snap-in and then view the properties of the Local File logging method. 2. Select Accounting requests and Authentication requests. 3. Ensure that the log file directory is set to D:\IASLogs and that Database-compatible format is selected. (this allows logs to be directly imported into databases such as Microsoft SQL Server™).

WLAN 802.1X Authentication This section steps through the process of implementing WLAN security with the 802.1X protocol specification as based on the Windows Server 2003 and Windows XP SP1 platforms. These instructions include information regarding the configuration of Active Directory groups, the deployment of X.509 certificates, modification of IAS server settings, deployment of WLAN Group Policy, and some tips for configuring wireless access points to support the 802.1X EAP-TLS implementation upon which this guide is based.

Preparing the Environment for a Secure WLAN Now that the underlying certificate and RADIUS infrastructures are in place, the actual 802.1X specific configuration steps can be implemented. The following tables of prerequisite settings can assist with the information gathering process that must occur

Secure Wireless Access Point Configuration

47

prior to the actual implementation. Some of these settings are enabled manually and others are a part of the scripts which have been supplied with this guide. Prerequisite User-Defined Configuration Settings The following table lists organizational-specific parameters that need to be collected or decided upon before continuing with this phase of the secure WLAN implementation. The space provided can be used to record the settings needed for each specific environment. Table 17. Prerequisite User-Defined Settings Configuration Item

Setting

Active Directory forest root domain DNS name NetBIOS domain name Primary IAS server name Secondary IAS server name Prerequisite Solution-Defined Configuration Settings The following table lists settings that do not need to be changed unless there is a specific need to do so. Ensure that the implications and dependencies caused by any changes are completely understood and planned for before changing any of these parameters, including script changes that would be required. Table 18. Solution-Defined Configuration Settings Configuration Item

Setting

Active Directory global group controlling deployment of 802.1X user authentication certificates

AutoEnroll Client Authentication – User Certificate

Active Directory global group controlling deployment of 802.1X computer authentication certificates

AutoEnroll Client Authentication – Computer Certificate

Active Directory global group containing IAS server requiring 802.1X authentication certificates

AutoEnroll RAS and IAS Server Authentication Certificate

Active Directory global group containing users allowed to access the wireless network

Remote Access Policy – Wireless Users

Active Directory global group containing computers allowed to access the wireless network

Remote Access Policy – Wireless Computers

Active Directory universal group containing both the Wireless Users group and Wireless Computers group

Remote Access Policy – Wireless Access

Active Directory global group containing computers requiring configuration of wireless network properties

Wireless Network Policy – Computer

Certificate template used to generate certificates for user client authentication

Client Authentication – User

Certificate template used to generate certificates for computer client authentication

Client Authentication – Computer

Certificate template used to generate server authentication certificates for IAS

RAS and IAS Server Authentication

Path for installation scripts

C:\MSSScripts

48

Midsize Business Security Guidance

Configuration Item

Setting

Path for configuration backup files

D:\IASConfig

Path for IAS authentication and auditing logs

D:\IASLogs

Policy Name

Allow Wireless Access

Active Directory GPO Name

Wireless Network Policy

Wireless Network policy within the above GPO

Client Computer Wireless Configuration

Creating the Required Active Directory Groups for WLAN Access The following script must be run with an account that has permission to create Active Directory security groups because it creates the required groups needed to implement wireless authentication certificate enrollment, remote access policy, and wireless network Group Policy: Cscript //job:CreateWirelessGroups C:\MSSScripts\wl_tools.wsf Note In multi-domain forest environments, the groups should be created in the same domain as the wireless users.

Verifying DHCP Settings To accommodate wireless networks, the DHCP servers should be configured with wireless specific scopes and IP address lease times that are shorter than other wired clients. Check with DHCP server administrators to ensure that DHCP has been configured properly. For more information about DHCP planning for Wireless LANs, see the Windows Server 2003 Deployment Kit at www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx.

Configuring WLAN Authentication Certificates To implement EAP-TLS based WLAN security as detailed in this guide, it is necessary to create and deploy the following types of certificates: •

Client Authentication – Computer

•

Client Authentication – User

•

RAS and IAS Server Authentication

Creating a Certificate Template for IAS Server Authentication IAS servers require a server certificate to authenticate computers to clients during the EAP-TLS protocol handshake. The Certificate Services administrator should perform the following steps to create a server authentication certificate template for use by the IAS servers. To create a certificate template for server authentication 1. Log on to the issuing CA with a CA Administrative group account and run the Certificate Templates MMC. 2. Create a duplicate of the RAS and IAS Server certificate template. On the General tab of the new template’s properties, in the Template display name field, type RAS and IAS Server Authentication. 3. On the Extensions tab ensure that the Issuance policies only include Server Authentication (OID 1.3.6.1.5.5.7.3.1).

Secure Wireless Access Point Configuration

49

4. Also, in the Extensions tab, edit the Issuance policies to add the Medium Assurance policy. 5. On the Subject Name tab, select Build from this Active Directory information. Also ensure that the Subject Name Format is set to Common Name and that only DNS Name is selected under Include This Information in Subject Alternative Name. 6. On the Request Handling tab, click the CSPs button, ensure that Requests Must Use One of the Following CSPs is selected and that only the Microsoft RSA SChannel Cryptographic Provider is selected. 7. On the Security tab, add the AutoEnroll RAS and IAS Server Authentication Certificate security group with Read, Enroll, and Autoenroll permissions and remove any other groups that may have permissions to enroll or autoenroll this certificate template. Note It may be advantageous to set this certificate to require Certificate Manager approval because it is considered to have a relatively high security value. Enabling this value will help ensure that a rogue IAS server is not enrolled but will require manual approval after certificates are issued and automatically sent by the IAS server.

Creating a Certificate Template for User Authentication End users need to have user certificates to authenticate to the IAS server during the EAP-TLS handshake process. Again, the following steps should be performed by the account holder designated to be a Certificate Services administrator. To create a user authentication certificate template 1. Launch the Certificate Templates MMC snap-in on the issuing CA server. 2. Create a duplicate of the Authenticated Session template, under the General tab of the new template, in the Template Display Name field, type Client Authentication – User. 3. On the Request Handling tab, select CSPs and clear the Microsoft Base DSS Cryptographic Provider check boxes. 4. On the Subject Name tab, ensure that Build From This Active Directory Information is selected. Under Subject Name Format, select Common Name. Ensure that User Principal Name (UPN) is the only option selected under Include this Information in Subject Alternate Name. 5. On the Extensions tab, ensure that only Client Authentication (OID 1.3.6.1.5.5.7.3.2) is included in Application Policies. Also edit the Issuance policies and add the Low Assurance policy. 6. On the Security tab, add the AutoEnroll Client Authentication – User Certificate security group with Read, Enroll, and Autoenroll permissions. Also, any other group with enroll or autoenroll permissions should be removed. Creating a Certificate Template for Computer Authentication This certificate is used by computers when authenticating to the IAS server during the EAP-TLS handshake. Once again the Certificate Services administrator should perform the following tasks.

50

Midsize Business Security Guidance

To create a computer authentication certificate template 1. Launch the Certificate Templates MMC snap-in on the issuing CA. 2. Create a duplicate of the Workstation Authentication template. On the General tab of the new template, in the Template Display Name field, type Client Authentication – Computer. 3. On the Subject Name tab, ensure that you select Build from this Active Directory Information. Under Subject Name Format, select Common Name. Ensure that DNS Name is the only option selected under Include this Information in Subject Alternate Name. 4. On the Extensions tab, edit the application policies and ensure that only Client Authentication (OID 1.3.6.1.5.5.7.3.2) is included. Also edit the Issuance policies and add the Low Assurance policy. 5. On the Security tab, add the AutoEnroll Client Authentication – Computer Certificate security group with Read, Enroll, and Autoenroll permissions. Any other groups with permissions should be removed. Adding WLAN Authentication Certificates to the CA Now that the certificate templates have been configured, they must be added to the CA to enable enrollment. To do this, the Certificate Services administrator will need to perform the following tasks. To add certificate templates to the CA •

On the issuing CA, launch the Certificate Authority MMC snap-in and right-click the Certificate Templates folder, click New, and then click Certificate Template to Issue. Select the following certificates and then click OK: •

Client Authentication – Computer

•

Client Authentication – User

•

RAS and IAS Server Authentication

Enrolling for the IAS Server Certificate Deploying the server authentication certificates to IAS servers is fairly straightforward and automatic. To enroll an IAS server 1. Launch the Active Directory Users and Computers MMC snap-in and add the IAS computer accounts to the AutoEnroll RAS and IAS Server Authentication Certificate security group. 2. Restart the IAS server and log on as a member of the local Administrators group. 3. From a command prompt, run GPUPDATE /force 4. Open the MMC and then add the Certificates snap-in. When prompted, select the Computer Account option and then select Local Computer. 5. Select Certificates (Local Computer) from the console tree, on the Action menu, click All Tasks, and then click Automatically Enroll Certificates. Note If the option to require Certificate Manager approval was enabled then the CA administrator will need to verify the validity of this request and issue the certificate.

Secure Wireless Access Point Configuration

51

Adding Users and Computers to Autoenrollment Groups Users and computers that require WLAN connectivity will need user and computer certificates issued before they can authenticate to and access the network through a wireless connection. The process of issuing and renewing those certificates is transparent to the end user due to the autoenrollment groups that have been set up previously. To add users and their computers to the autoenrollment groups, simply use the Active Directory Users and Computers MMC snap-in to add the user accounts to the AutoEnroll Client Authentication – User Certificate group and add their computers to the AutoEnroll Client Authentication – Computer Certificate group. After this is done, the users in question will receive their user and computer certificates after they restart their computers and log back on to the network. Note This solution uses custom groups to control which users and computers can receive certificates. If the environment demands that all users and computers require certificates, simply add Domain Users to the AutoEnroll Client Authentication – User Certificate group and Domain Computers to the AutoEnroll Client Authentication –Computer Certificate group.

Configuring the WLAN Access Infrastructure The primary IAS server needs to be configured with a remote access policy and connection request settings that determine authentication and authorization of wireless clients to the WLAN. These settings must then be replicated to other IAS servers and then each IAS server must be uniquely configured to accept connections from RADIUS clients, such as wireless access points. After this the wireless access points themselves must be configured to use the IAS server as the authentication and authorization sources for the wireless 802.1X network. Creating an IAS Remote Access Policy for WLANs Use the Internet Authentication Service MMC snap-in on the primary IAS server to configure IAS with a remote access policy as follows. To create a remote access policy 1. Right-click the Remote Access Policies folder, and then click Create New Remote Access Policy. 2. Name the new policy Allow Wireless Access and instruct the wizard to set up A Typical Policy for a Common Scenario. 3. Select Wireless for the access method. 4. Grant access based on groups and use the Remote Access Policy – Wireless Access security group. 5. Choose Smart Card or Other Certificate for the Extensible Authentication Protocol (EAP) type and then select the server authentication certificate installed for IAS. 6. Finish and exit the wizard. 7. Open the properties of the Allow Wireless Access policy and then click Edit Profile. 8. On the Advanced tab, add the Ignore-User-Dialin-Properties attribute, set it to True, and then add the Termination-Action attribute and set it to RADIUS Request. Note The Allow Wireless Access policy can coexist with other user-created policies or the default access policies but the default remote access policy must be listed after the Allow Wireless Access policy in the Remote Access Policies folder to function correctly.

52

Midsize Business Security Guidance

Adding RADIUS Clients to IAS Wireless Access Points and RADIUS Proxies must be added to the IAS as RADIUS clients before they can use authentication and accounting services through the RADIUS protocol. To add RADIUS clients to IAS 1. Launch the Internet Authentication Server MMC snap-in. 2. Right-click the RADIUS Clients folder, and then click New RADIUS Client. 3. Enter the friendly name and IP address of the wireless access point. 4. Select RADIUS Standard as the client-vendor attribute and enter the shared secret for the specific wireless access point. Then select the Request Must Contain the Message Authenticator attribute. Note This process should be repeated on each IAS server to ensure that each server has a unique set of wireless access point Clients and Shared Secrets. To make this process easier, this guide contains a script that can be used to generate shared secrets which can then be stored in a secure location in case a system restore is necessary. To use this script simply issue the following at a command prompt:

Cscript //job:GenPWD C:\MSSScripts\wl_tools.wsf /client:ClientName

Deploying Configurations to Multiple IAS Servers After the following items are configured on the primary IAS server, they can be exported to text files by using the netsh command. Once exported, these text files can then be imported to each IAS server that has a similar role within the environment, this ensures that a common configuration exists throughout the environment. Exportable configuration settings include: •

Server Settings

•

Logging Configuration

•

Remote Access Policies

•

RADIUS Clients

•

Full Configuration

Each IAS server should contain its own unique list of RADIUS clients and shared secrets, therefore this information must be configured individually on each server and backed up separately. Additionally, a full configuration dump contains highly sensitive information that must be carefully secured as this information can be used to gain access to the wireless network if stolen. Exporting the Primary IAS Server Configuration The following types of settings should be exported to text files for replication to other IAS servers. •

Server Configuration

•

Logging Settings

•

Remote Access Policy

•

Connection Request Policies

Secure Wireless Access Point Configuration

53

To make this process easier this guide comes with batch files that contain the netsh commands, which can export the common configuration information to text files in the D:\IASConfig directory by issuing the following at a command prompt. C:\MSSScripts\IASExport.bat Importing Configuration Information from the Primary IAS Server As previously mentioned, IAS uses the netsh command to transfer configuration states between servers. This process makes deployment more efficient while reducing the chances of error during the configuration process. Now that the primary IAS server’s configuration information has been exported the secondary IAS servers can import the configuration state. To import the primary IAS configuration state to other IAS servers 1. Copy all configuration files from the D:\IASConfig directory on the Primary IAS server to the corresponding D:\IASConfig directory on other IAS servers. 2. Use the following batch file (included with this guide) at a command line on the secondary servers to import the configuration state: C:\MSSScripts\IASImport.bat

Wireless Access Points and Clients The procedure for configuring wireless access points can vary significantly depending on the make and model of the device in question. However, wireless access point vendors generally provide detailed instruction for configuring devices with the following necessary details: •

802.1X networking settings

•

Configuring the Primary RADIUS server address

•

Configuring the Secondary RADIUS server address

•

RADIUS secret shared with the Primary RADIUS server

•

RADIUS secret shared with the Secondary RADIUS server

For instructions for configuring a specific brand and model of wireless equipment please refer to that vendor’s instructions or support Web site.

Deploying WLAN Authentication Certificates This section describes a few important configuration tasks required to enable automatic certificate enrollment for Windows XP–based clients. Although previous sections dealt with enabling policies and templates to support certificate autoenrollment in the certificate infrastructure, Windows XP support for this functionality is disabled by default. To enable support for certificate autoenrollment, the proper settings must be configured using Group Policy. By using security groups to control autoenrollment this capability can be enabled for all users and computers in a domain and the security groups can determine who receives the certificates of each type. To enable autoenrollment for all users and computers in a domain 1. Log on with an account that has permissions to create GPOs and link GPOs to the domain. 2. In Active Directory Users and Computers, select the domain object by right-clicking it and then click properties. 3. On the Group Policy tab, click New and then type a name for the GPO, (Domain PKI Policies, for example).

54

Midsize Business Security Guidance

4. Click Edit and then browse to Public Key Policies under Computer Configuration\Windows Settings\Security Settings. 5. In the Details pane, double-click Autoenrollment Settings. 6. Ensure that the following items are selected: •

Enroll Certificates Automatically

•

Renew Expired Certificates, Update Pending Certificates, and Remove Revoked Certificates

•

Update Certificates that use Certificate Templates

7. Repeat steps 5 and 6 for the user Autoenrollment Settings at User Configuration\Windows Settings\Security Settings\Public Key Policies. 8. Close the GPO 9. Make certain that the GPO has a higher priority than the Default Domain Policy GPO. 10. Repeat this process for each domain where certificate autoenrollment will be enabled if in a multi-domain forest. Note If users do not use roaming profiles and autoenrollment is allowed universally, certificates will be issued for users at every computer to which they log on. This may be unwanted when administrative users log onto servers. To prevent this, it is recommended that a GPO be created for servers to disable autoenrollment. Also, if it is disadvantageous to enable autoenrollment for all users, a GPO can be linked to OUs that contain the subset of users that need autoenrollment.

Enabling WLAN Access for Users and Computers The final steps to enable users and computers for secure WLAN access include a few actions that must be performed on Active Directory objects. These actions include modifying account permissions, group permissions, and implementing WLAN Group Policy settings. Adding Users to Remote Access Policy Groups IAS remote access policy uses Active Directory–based security groups to determine whether users and computers are authorized to establish connections to the WLAN. These security groups which have been created in early sections include: •

Remote Access Policy – Wireless Users

•

Remote Access Policy – Wireless Computers

•

Remote Access Policy – Wireless Access

To add users and computers to the WLAN access groups 1. Open the Active Directory Users and Computers MMC snap-in. 2. Add the Remote Access Policy – Wireless Users group and the Remote Access Policy – Wireless Computers group to the Remote Access – Wireless Access group. 3. Add users permitted to access the WLAN to the Remote Policy – Wireless Users group. 4. Add computers permitted to access the WLAN to the Remote Policy – Wireless Computers group. Note If it is decided that allowing all users and computers to access the WLAN by default is preferred then Domain Users and Domain Computers groups can be added to their corresponding policy groups to simplify administration.

Secure Wireless Access Point Configuration

55

Creating the Active Directory WLAN Group Policy Group Policy can be used to automate and enforce client computer WLAN configuration settings as the Group Policy MMC in Windows Server 2003 contains Wireless Network Policy settings that relate to 802.1X and 802.11 standards. To create a Wireless Network Group Policy 1. Open the Active Directory Users and Computers MMC snap-in on a Windows Server 2003–based server or a workstation with the Windows Server 2003 Administration tools installed. 2. Select the properties of the domain object, on the Group Policy tab, click New, then name the GPO Wireless Network Policy. 3. Click the Properties button, and on the Security tab grant the Wireless Network Policy – Computer security group Read and Apply Group Policy permissions. Also, remove Apply Group Policy permissions from Authenticated Users on the GPO. 4. On the General tab, select Disable User Configuration Settings on the policy object and select Yes to any warning messages that appear. Apply the changes and close the window. 5. Click the Edit button and browse to \Computer Configuration\Windows Settings\Security Settings\Wireless Network (IEEE 802.11) Policies. 6. Select the Wireless Network (IEEE 802.11) Policies object from the navigation pane and then, on the Action menu, click Create Wireless Network Policy. Use the wizard to name the policy Client Computer Wireless Configuration. Leave the Edit Properties option selected and then click Finish to close the wizard. 7. In the Client Computer Wireless Configuration policy, on the Preferred Networks tab, select Add and then enter the Network Name or Service Set ID (SSID) of the wireless network. 8. Click the IEEE 802.1X tab and then open the settings for the Smartcard or Other Certificate EAP Type. Under Trusted Root Certificate Authorities, select the root CA certificate for the PKI that issued the IAS server certificates. 9. Close the properties for Client Computer Wireless Configuration and the Group Policy Object Editor. Note WPA2 is currently not applicable using GPO. However, GPO support of WPA2 is anticipated with the release of Windows Vista and Longhorn and updates are planned to address this for current Windows releases as well.

Adding Computers to Security Groups for the WLAN Group Policy Active Directory–based security groups are used to determine which computers have Wireless Network policies applied to automatically configure required 802.11 and 802.1X settings. These settings should be deployed before configuring the 802.1X settings on any wireless access points and activating the WLAN. This approach ensures that client computers have an adequate chance to download and apply the computer–based Group Policy, even if they rarely connect to the wired network. The Group Policy settings can even be applied prior to the installation of a WLAN network interface adapter (nic) because it will automatically retrieve and apply the correct Wireless Network Group Policy settings. To add computers to the groups for Wireless Network Group Policy, use the Active Directory Users and Computers MMC snap-in to add the authorized computer objects to the Wireless Network Policy – Computer group. Note The Wireless Network GPO settings will update on client computers during the next computer Group Policy refresh interval. To force a refresh simply issue the GPUPDATE /force command.

56

Midsize Business Security Guidance

WPA2 Client Requirements The solution outlined in this guide was designed for wireless capable client computers using Windows XP Professional with SP2 or Windows XP Tablet Edition. These versions of Windows offer built-in 802.1X and WLAN support. Additionally, Windows XP–based clients supply automatic certificate enrolment and renewal functionality, which makes a certificate-based solution such as this particularly cost effective when tied to a certificate infrastructure. Although Windows XP with SP2 offers built-in support for WPA, it is necessary to install an additional update to enable IEEE 802.11i WPA2 support on Windows XP with SP2– based clients. For more information about this additional update along with download instructions, see Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Service Information Element (WPS IE) update for Windows XP with Service Pack 2 is available at http://support.microsoft.com/default.aspx?scid=kb;en-us;893357.

Summary After reviewing the myriad solutions available to address the well-known flaws in the older wireless security standards while reviewing how industry standards have made those workarounds obsolete, the solution to improve the security of wireless networks in a midsized business environment has become clear. Now midsized businesses can efficiently implement this valuable technology to take advantage of great productivity enhancements reliably and more securely by using the WPA or WPA2 EAP-TLS with Certificate Services solution that this guide provides. After following the detailed steps and using the tools that this document provides, a midsized business can have a reliable and safer wireless solution that boosts productivity without any interruption to the network end user.