Designing and Deploying Wireless LAN Connectivity for the Microsoft Corporate Network

  • Article

Microsoft Corporation

Abstract

This paper describes the history of the deployment of the wireless local area network (WLAN) of the Microsoft Corporation, the technologies used to provide secure wireless access, and its current configuration and infrastructure.

On This Page

History of the Microsoft WLAN
Microsoft WLAN Technologies
Design and Deployment Considerations
Current Deployment and Infrastructure
Summary
Related Links

History of the Microsoft WLAN

Demand for wireless access to enterprise local area networks (LANs) is fueled by the growth of mobile computing devices, such as laptops and personal digital assistants (PDAs), and a desire by users for continual connections to the network without being restricted to "plug in areas," which do not move with their work. Microsoft's dedication to providing end-user connectivity anytime and anywhere drives our wireless product enhancements as well as our commitment to providing a secure and reliable wireless networking enterprise infrastructure.

Microsoft was the first large enterprise to embrace WLAN technology as an alternative to wire-attached laptop units. With the IEEE 802.11 WLAN standard newly ratified as an international standard, Microsoft readily endorsed the IEEE 802.11b extension to the newly published standard (ratified September 16, 1999) and began deploying IEEE 802.11b in December of 1999 throughout its Redmond corporate campus. Since then, Microsoft has actively worked to improve and to lead efforts in the IEEE 802.11 standards body to enhance and refine areas of data privacy, authentication, and network reliability.

Shortly after the IEEE 802.11b ratification, the IEEE 802.1 MAC Bridging group began working on the IEEE 802.1X extension to the 802.1 bridging standard in support of authenticated port access to LAN based networks such as IEEE 802.3 (Ethernet), IEEE 802.5 (Token Ring), Fiber Distributed Data Interface (FDDI), and IEEE 802.11.

Microsoft initially offered wireless connectivity as a supplement to the ubiquitous wired connectivity. It was not designed to be an end-user's primary network connectivity device. However, the WLAN service soon became a highly desired connectivity choice enabling impromptu discussions, software demonstrations, and ability to take your work with you to meetings, all of which had a positive impact on worker productivity.

After the initial Redmond campus rollout was finished, Microsoft had the largest enterprise WLAN network in the world. Microsoft was also immediately faced with solving deployment, integration, and maintenance issues of a large WLAN network. From the initial deployment of 2,800 wireless access points (APs) and 19,000 wireless network adapters, Microsoft had to deal with issues of security and scalability from the start. For example, Microsoft realized that MAC address filtering and early VPN solutions would not be a scalable final solution to support a global WLAN.

The initial rollout of 802.11b on the campus used static WEP 128-bit encryption keys for data privacy and IEEE 802.11 shared key authentication. News of ongoing security compromises of WEP and shared key authentication prompted Microsoft to take an aggressive stance toward security of its WLAN infrastructure. The result of this stance is the current WLAN deployment that uses 802.1X, certificate-based EAP-TLS authentication, and per-session WEP keys.

Microsoft continues to lead the security efforts in both authentication and data privacy in the IEEE 802.11i security task group. Microsoft also realizes the benefits to other areas of functionality and provides contributions to support end-user requirements for "world mode" operation of wireless network adapters and an inter-wireless AP protocol that uses connect blocks of session association information.

Microsoft recognizes both the benefits of wireless technology to its users and customers as well as the new threats that wireless technology introduces to enterprise corporate networks.

Microsoft WLAN Technologies

The Microsoft WLAN utilizes the following technologies:

  • IEEE 802.11b

  • IEEE 802.1X

  • EAP-TLS authentication

  • RADIUS

  • Active Directory

  • Certificates

IEEE 802.11b

IEEE 802.11 is an industry standard for a shared, wireless local area network (WLAN) that defines the physical layer and media access control (MAC) sublayer for wireless communications. IEEE 802.11b is an enhancement to the original IEEE 802.11 specification. The major enhancement to IEEE 802.11 by IEEE 802.11b is the standardization of the physical layer to support higher bit rates.

IEEE 802.11b supports two additional speeds, 5.5 megabits per second (Mbps) and 11 Mbps, using the Industrial, Scientific, and Medical (ISM) 2.45 GHz frequency band. The Direct Sequence Spread Spectrum (DSSS) modulation scheme is used in order to provide the higher data rates. The bit rate of 11 Mbps is achievable in ideal conditions. In less-than-ideal conditions, the slower speeds of 5.5 Mbps, 2 Mbps, and 1 Mbps are used.

IEEE 802.1X

The 802.1X standard defines port-based, network access control used to provide authenticated network access for Ethernet networks. This port-based network access control uses the physical characteristics of the switched LAN infrastructure to authenticate devices attached to a LAN port. Access to the port can be denied if the authentication process fails. Although this standard was originally designed for wired Ethernet networks, it has been adapted for use on 802.11 wireless LANs.

To provide a standard authentication mechanism for IEEE 802.1X, the Extensible Authentication Protocol (EAP) was chosen. EAP is a Point-to-Point Protocol (PPP)-based authentication mechanism that was adapted for use on point-to-point LAN segments. EAP messages are normally sent as the payload of PPP frames. To adapt EAP messages to be sent over Ethernet or wireless LAN segments, the IEEE 802.1X standard defines EAP over LAN (EAPOL), a standard way to encapsulate EAP messages.

EAP-TLS Authentication

EAP-Transport Level Security (EAP-TLS) is an EAP type described in RFC 2716 that is used in certificate-based security environments. If you are using smart cards for remote access authentication, you must use the EAP-TLS authentication method. The EAP-TLS authentication process exchanges certificates installed on the access client and the authenticating server and provides mutual authentication, integrity-protected cipher suite negotiation, and secured secret key exchange and determination. EAP-TLS provides a very strong authentication method.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a widely deployed protocol enabling centralized authentication, authorization, and accounting for network access. RADIUS is described in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," (IETF Draft Standard) and RFC 2866, "RADIUS Accounting" (Informational).

Originally developed for dial-up remote access, RADIUS is now supported by wireless APs, authenticating Ethernet switches, virtual private network (VPN) servers, Digital Subscriber Line (DSL) access servers and other network access servers.

Internet Authentication Service (IAS) provided with the Windows 2000 Server and Windows Server 2003 families is the Microsoft implementation of a RADIUS server and (for the Windows Server 2003 family) RADIUS proxy. IAS performs centralized connection authentication, authorization, and accounting for many types of network access, including wireless, authenticating switch, dial-up and virtual private network (VPN) remote access, and router-to-router connections. IAS supports RFCs 2865 and 2866, as well as additional RADIUS extension RFCs and Internet drafts. IAS enables the use of a heterogeneous set of wireless, switch, remote access, or VPN equipment, and can be used with the Windows 2000 Server or Windows Server 2003 Routing and Remote Access service.

When an IAS server is a member of an Active Directory-based domain, IAS uses Active Directory as its user account database and is part of a single sign-on solution. The same set of credentials is used for network access control (authenticating and authorizing access to a network), logging on to an Active Directory-based domain, and accessing resources.

Active Directory

Active Directory is a directory service designed for distributed computing environments. Active Directory allows organizations to centrally manage and share information on network resources and users while acting as the central authority for network security. In addition to providing comprehensive directory services to a Windows environment, Active Directory is designed to be a consolidation point for isolating, migrating, centrally managing, and reducing the number of directories that companies require.

For wireless access, Active Directory domains contain the user and computer accounts for authentication and the Group Policy settings to deploy computer certificates.

Certificates

A certificate is a digitally signed statement using public key cryptography technology that binds the value of a public key to the identity of the person, device, or service that holds the corresponding private key. A certificate is issued by a certification authority (CA). Public key cryptography uses public and private key pairs to encrypt or digitally sign messages.

Design and Deployment Considerations

Microsoft's deployment of wireless connectivity is for production access into the enterprise corporate intranet (hereafter known as Corpnet). Once on the Microsoft Corpnet, no firewalls restrict employees or other authorized users access to network and corporate resources.

Performance

Because the WLAN was designed to supplement, not replace, Microsoft's wired Ethernet LAN infrastructure, on average 2-4 users share 11 Mbps per wireless AP. Real throughput fluctuates between 4-6.5 Mbps. The result of this design rule is that for a fully loaded AP (25 users), the user experience is similar to using a home DSL or cable modem connection.

An additional technique was used to ensure high performance in dense areas such as executive briefing conference rooms and training areas, where large numbers of users are located in a very densely populated area. By reducing transmit power of the wireless APs from 30 milliwatts (mW) to 15 or 5 mW (or even as low as 1 mW), smaller coverage areas were created. This allowed a greater number of wireless APs to be placed in the same area. In a room for 200, where normally only three wireless APs could be placed because of coverage area overlap, multiple wireless APs are used, resulting in a smaller number of wireless clients per wireless AP and better average bandwidth per wireless client.

Scalability

Microsoft's WLAN design is based on a 20-meter diameter coverage area. This is to ensure redundant coverage against the potential failure of a single wireless AP and to provide seamless roaming within a building. Microsoft's Information Technology Group (ITG) verified wireless AP installation for conformance with an internally developed commissioning checklist. They also checked coverage and network connectivity of each wireless AP. On the engineering side, Microsoft was concerned about decreased coverage area size, overlapping coverage areas via channel configuration, and mitigating Bluetooth (BT) interference.

Roaming and Mobility

In Microsoft's WLAN deployment, all the wireless APs within each building are on the same IP subnet. Therefore, intra-building wireless roaming is seamless. When wireless clients associate with different wireless APs, the DHCP renewal process just renews the lease on the existing TCP/IP configuration. Inter-building roaming and the DHCP renewal process causes a change in the TCP/IP configuration, which might cause problems for applications that cannot gracefully handle a change in the TCP/IP configuration. In either case, because EAP-TLS and certificates are used for authentication, the user is never prompted to authenticate to the WLAN.

Security

Elements of the security design include the following:

  • Authentication

  • Eavesdropping

  • Rogue wireless APs

Authentication

Microsoft choose EAP-TLS using registry-based user and computer certificates as the authentication method for wireless connectivity for the following reasons:

  • EAP-TLS does not require any dependencies on the user account's password.

  • EAP-TLS authentication occurs automatically, usually with no intervention by the user.

  • EAP-TLS uses certificates, which is a relatively strong authentication method.

  • The EAP-TLS exchange is protected with public key cryptography and is not susceptible to offline dictionary attacks.

  • The EAP-TLS authentication process results in mutually determined keying material for data encryption (the WEP unicast session encryption key) and signing.

Eavesdropping

Wireless traffic on the Microsoft WLAN is protected from eavesdropping in the following ways:

  • EAP messages for IEEE 802.1X negotiation are sent as clear text. However, the use of EAP-TLS and public key encryption prevents the eavesdropper from obtaining the information needed to masquerade as either the wireless client or the authenticating server.

  • After EAP-TLS negotiation is complete, all traffic sent between an authenticated wireless client and its associated wireless AP is encrypted with either the WEP multicast/global or unicast session key.

By monitoring the 802.1X exchange and 802.11 control and data traffic, an eavesdropper listening to wireless traffic could obtain information such as:

  • The names of the computer or user accounts involved in each EAP-TLS negotiation

  • Wireless client and wireless AP MAC addresses

  • MAC addresses of nodes on the wireless AP subnets

  • Time of association and disassociation

An eavesdropper could use such information to do long-term traffic profiling and analysis that may provide user or device details.

For an eavesdropper listening on the wired network, sensitive attributes of RADIUS messages sent between the wireless APs and the RADIUS servers and proxies are protected with the RADIUS shared secret.

Rogue Wireless APs of the Microsoft WLAN

Protection from rogue wireless APs of the Microsoft WLAN is done through the use of EAP-TLS, which provides mutual authentication of the wireless client and the authenticating RADIUS server. To masquerade as a Microsoft corporate wireless AP, it must have a security relationship with a Microsoft ITG RADIUS server, which is defined by the configuration of the wireless AP as a RADIUS client on the RADIUS server or proxy and a RADIUS shared secret. If a wireless AP does not have this security relationship and configuration, it cannot exchange RADIUS messages with the RADIUS server and therefore, cannot authenticate 802.1X wireless clients. It is possible for the rogue wireless AP to be configured as the RADIUS client of a rogue RADIUS server. However, by default Microsoft wireless clients validate the certificate of the RADIUS server. Therefore, if the RADIUS server of the wireless AP cannot provide a valid certificate and proof of knowledge of its corresponding private key, the wireless client terminates the connection.

Deployment Process

Microsoft's deployment of wireless access occurred in four phases:

  1. Pre-installation

  2. Installation

  3. Delivery

  4. Rollout to Microsoft users

Phase 1: Pre-installation

Pre-installation involved three steps:

  1. Development of a wireless AP location plan based on design guidelines in which 95% of the installations require no specialized antenna.

  2. Field-verification of proposed wireless AP locations to check for physical interference.

  3. Presenting the final locations to a Microsoft ITG designer for approval prior to starting installation.

Phase 2: Installation

Physical installation of the wireless APs involved the following steps:

  • Enclose wireless APs and antennas within plenum-rated enclosures to meet fire safety code requirements.

  • Configure central, low voltage power supply on backup power using uninterruptible power supplies.

  • Build out RADIUS infrastructure.

Phase 3: Delivery

Delivery involved the following steps:

  • Spot-check wireless AP installation for conformance with commissioning checklist.

  • Verify RF coverage and network connectivity of each wireless AP.

  • Deliver "as-built" documents, reflecting the final placement of each wireless AP.

Phase 4: Rollout to Microsoft Users

The rollout to Microsoft users involved the following steps:

  • Create a Cryptographic API Component Object Model (CAPICOM) script to install certificates

  • Create Web site to host information about instructions, updated drivers, and the CAPICOM script

  • Inform users of Web site with information to obtain wireless access

To obtain the computer and user certificates required for wireless connectivity to the Microsoft corporate wireless network, the computer, typically a wireless laptop computer, must connect to the Microsoft Corpnet using an Ethernet connection.

For more information about CAPICOM, see Cryptography, CryptoAPI, and CAPICOM.

Current Deployment and Infrastructure

There are currently over 3,200 wireless APs of the Microsoft WLAN installed worldwide. The magnitude of this deployment created unique challenges for Microsoft in areas of security and authentication. Microsoft ITG involved the efforts of several departments to create and deploy its 802.11 WLAN solution. End User Services (EUS), Corporate Security, Enterprise Network Engineering and Corporate Server support groups provided integration testing and deployment of the secure Microsoft WLAN.

The current WLAN deployment consists of:

  • Active Directory domain controllers

  • Windows 2000 CAs

  • Wireless clients running Windows XP

  • Cisco Aironet 340 and 350 Series Access Points

  • RADIUS servers and proxies running Windows Server 2003

Active Directory Domain Controllers

The Microsoft Corpnet uses native mode domains with domain controllers running a member of the Windows Server 2003 family. During the transition to Windows Server 2003, there were domain controllers running Windows 2000 Server with Service Pack 2 (SP2) and the required patches for Active Directory to allow computer accounts to have dial-in properties and the SChannel certificate mapper installed (these patches are now part of Windows 2000 Service Pack 3). For links to these components, see "Related Links" in this article. Within the Microsoft Corpnet, there are following Active Directory forests:

  • Corpnet.ms.com

  • NT.Dev

  • Win.SE

  • Win.Deploy

The corpnet.ms.com forest contains the corpnet.ms.com domain and a series of child domains that represent the major geographical regions of the Microsoft Corporation. Figure 1 shows this structure.

Figure 1: The structure of the corpnet.ms.com forest

Figure 1: The structure of the corpnet.ms.com forest

As defined by the forest structure for Active Directory, a member server of any domain within the forest can validate the credentials of any account in any domain in the forest. For example, a member server in the Redmond domain can validate the user or computer credentials for accounts in the North America, Europe, South Pacific, and other child domains.

For more information about the Microsoft Corpnet Active Directory infrastructure, see Designing and Deploying Active Directory Service for the MS Internal Corpnet.

The remote access permission on the Dial-in tab of user and computer accounts is set to Control access through Remote Access Policy. Because it was determined that all valid domain machine and user accounts are allowed wireless access, the dial-in properties of the account are ignored for the evaluation of authorization and the determination of connection constraints. There is no global or universal group for all the accounts that have wireless access. For more information, see "RADIUS Servers and Proxies Running Windows Server 2003" in this article.

Windows 2000 CAs

To issue user and computer certificates for wireless access and provide certificate revocation list (CRL) publication, the existing Microsoft PKI was used. In conformance with Microsoft-recommended PKI best practices, the Microsoft PKI consists of the following:

  • An offline root CA

  • A level of offline intermediate CAs

  • A level of online issuing CAs

This hierarchy is shown in Figure 2.

Figure 2: Hierarchy for the Microsoft PKI

Figure 2: Hierarchy for the Microsoft PKI

This PKI provides flexibility and insulates the root CA from attempts to compromise its private key by malicious users. All CAs in the Microsoft PKI are running on a Windows 2000 member server.

To issue computer certificates, auto-enrollment using the Automatic Certificate Request Settings Computer Configuration Group Policy setting was configured on the appropriate domain system containers for all of the forests. All member computers requested and obtained a computer certificate from the appropriate issuing CA after updating Computer Configuration Group Policy settings.

To issue user certificates, Microsoft ITG staff created a CAPICOM script. Because auto-enrollment of user certificates is not possible with Windows 2000 enterprise CAs, the other alternatives are Web enrollment, using the Certificates snap-in to request or import a user certificate, or the use of a CAPICOM script. The use of CAPICOM scripts was chosen because it requires no user intervention for selecting certificate settings.

To educate Microsoft users and provide a location from which the CAPICOM script could be launched, Microsoft ITG staff created an internal Web site. The CAPICOM script verifies whether a user or computer certificate is already installed. If not, the script causes the computer to request a user or computer certificate from an appropriate issuing CA.

The computer certificate (installed through auto-enrollment) and the user certificate (installed through the CAPICOM script) are obtained while the computer is connected to the Microsoft Corpnet using an Ethernet connection.

Wireless Clients Running Windows XP

The operating system platform for wireless clients at Microsoft is Microsoft Windows XP, which includes built-in support for 802.11 and 802.1X. A wireless client user uses the Windows XP Zero Configuration service to connect to the Microsoft corporate wireless network. Default settings enable WEP encryption, the use of 802.1X authentication, and the EAP-TLS authentication method using a registry-based certificate. All wireless network adapters used at Microsoft support the Windows XP Zero Configuration service.

If a Microsoft user has a wireless network at home, the Windows XP Zero Configuration service allows the user to have both wireless networks in their list of preferred wireless networks: the Microsoft corporate wireless network and their home wireless network. While at work, their wireless laptop connects to the Microsoft corporate network. While at home, their wireless laptop connects to their home wireless network. Each wireless network can have it own configuration, including wireless network type (infrastructure vs. ad hoc) and authentication and encryption settings.

Cisco Aironet 340 and 350 Series Access Points

The Microsoft WLAN uses Cisco Aironet 340 and 350 Series Access Points, which are running Wireless IOS release 11.21 or later. The wireless APs are initially installed with a minimal configuration designed to provide TCP/IP and Simple Network Management Protocol (SNMP) access. A Microsoft-designed PERL-based SNMP script is launched and configures standard settings for the wireless AP, and individual settings such as channel number and signal power, which are extracted from a structured query language (SQL) database. Access point firmware and radio firmware software is deployed by upgrading a single wireless AP in each building and then using the "distribute image" capability of the wireless APs to transfer that image to all wireless APs within the building.

All wireless APs are configured as RADIUS clients to two RADIUS servers, each of which is a member server in a child domain of the corpnet.ms.com forest. There are no wireless APs that use the RADIUS servers in the NT.Dev, Win.SE, or Win.Deploy forests. This is shown in Figure 3.

Figure 3: Configuration of wireless APs as RADIUS clients

Figure 3: Configuration of wireless APs as RADIUS clients

Although the wireless APs are configured with a primary and secondary RADIUS server, the behavior of the wireless APs is to use the primary RADIUS server exclusively until it becomes unavailable, at which time they switch to the secondary RADIUS server and use it exclusively. If the secondary RADIUS server becomes unavailable, then the wireless APs switch back to the primary RADIUS server and use it exclusively. To balance the load of all the authentications for all the wireless APs in a domain, approximately half of the wireless APs are configured with specific primary and secondary RADIUS servers (for example, primary is RAD1 and secondary is RAD2) and the other half of the wireless APs are configured with the opposite primary and secondary RADIUS servers (for example, primary is RAD2 and secondary is RAD1). This manual configuration of the wireless APs assures that, assuming both RADIUS servers are available, the RADIUS authentication load is approximately split in half between the two RADIUS servers in the domain.

RADIUS Servers and Proxies Running Windows Server 2003

The RADIUS infrastructure for the Microsoft WLAN consists of pairs of domain member servers, each running a member of the Windows Server 2003 family and IAS. The IAS servers are acting as RADIUS servers, RADIUS proxies, or both. Pairs are used to provide failover support in the event that one of the members of the pair becomes unavailable.

Figure 4 shows the RADIUS infrastructure.

Figure 4: RADIUS infrastructure for the Microsoft WLAN

Figure 4: RADIUS infrastructure for the Microsoft WLAN

North America Child Domain

North America contains most of the wireless APs and accounts being authenticated. In order to accommodate this heavy load, IAS servers were deployed as RADIUS proxies to handle all the RADIUS traffic. The RADIUS proxies provide load balancing of RADIUS traffic to the RADIUS servers and allow for the scaling out of the authentication infrastructure without having to reconfigure each wireless AP.

A pair of IAS servers acting as RADIUS proxies route messages from the wireless APs in North America to the following:

  • For accounts in the corpnet.ms.com forest, to the North America RADIUS servers.

  • For accounts in the NT.Dev, Win.SE, or Win.Deploy forests, to the RADIUS servers in the appropriate forest.

This routing is accomplished by the configuration of the following connection request policies in the following order:

  • For authentication requests for which the User-Name attribute ends with corpnet.ms.com, forward traffic to the NorthAmerica remote RADIUS server group (consisting of the two RADIUS servers in the North America domain).

  • For authentication requests for which the User-Name attribute ends with NT.Dev.ms.com, forward traffic to the NT.Dev remote RADIUS server group (consisting of the two RADIUS servers in the NT.Dev.ms.com forest).

  • For authentication requests for which the User-Name attribute ends with Win.SE.ms.com, forward traffic to the Win.SE remote RADIUS server group (consisting of the two RADIUS servers in the Win.SE.ms.com forest).

  • For authentication requests for which the User-Name attribute ends with Win.Deploy.ms.com, forward traffic to the Win.Deploy remote RADIUS server group (consisting of the two RADIUS servers in the Win.Deploy.ms.com forest).

  • For Windows XP, the format for computer account names sent during computer authentication is Domain/ComputerAccount. In contrast, the format for user accounts names sent during user authentication is UserAccount@Domain.Forest. To accommodate the different format for computer account names, additional connection request policies were created for each domain that matched the computer account name and forwarded the RADIUS traffic to the appropriate remote RADIUS server group. For example, a connection request policy for the computer accounts in the North America domain was created with the following settings: for authentication requests for which the User-Name attribute begins with North America/, forward traffic to the NorthAmerica remote RADIUS server group. For another example, a connection request policy for the computer accounts in the NT.DEV domain was created with the following settings: for authentication requests for which the User-Name attribute begins with NT.Dev/, forward traffic to the NT.Dev remote RADIUS server group. With Windows XP Service Pack 1 (SP1), the format for computer account names sent during computer authentication is ComputerAccount@Domain.Forest and additional connection request policies for computer accounts are not needed.

A layer of RADIUS proxies is used in the North America domain to provide load balancing of authentication requests to the IAS servers in the NorthAmerica remote RADIUS server group, for wireless APs in the entire North America region (not including the Redmond corporate campus). For the IAS servers acting as RADIUS servers in the North America domain, a single connection request policy is used to perform authentication at the IAS server for all authentication requests for which the User-Name attribute ends with corpnet.ms.com.

For more information about using Windows Server 2003 IAS as a RADIUS proxy and the configuration of connection request policies, see the Windows Server 2003 family online Help.

Other Child Domains

A pair of IAS servers acting as RADIUS server/proxies in the other child domains of the corpnet.ms.com forest perform the following:

  • For accounts in the corpnet.ms.com forest, the IAS server performs authentication.

  • For accounts in the NT.Dev, Win.SE, or Win.Deploy forests, messages are forwarded to the RADIUS servers in the appropriate forest.

This is accomplished by the configuration of the following connection request policies in the following order:

  • For authentication requests for which the User-Name attribute ends with corpnet.ms.com, perform authentication on this server.

  • For authentication requests for which the User-Name attribute ends with NT.Dev.ms.com, forward traffic to the NT.Dev remote RADIUS server group.

  • For authentication requests for which the User-Name attribute ends with Win.SE.ms.com, forward traffic to the Win.SE remote RADIUS server group.

  • For authentication requests for which the User-Name attribute ends with Win.Deploy.ms.com, forward traffic to the Win.Deploy remote RADIUS server group.

  • To accommodate the different format for computer account names, additional connection request policies were created for each domain that matched the computer account name and forwarded the RADIUS traffic to the appropriate remote RADIUS server group.

NT.Dev, Win.SE, and Win.Deploy Forests

In each of these forests, a pair of IAS servers acting as RADIUS servers performs the following:

  • For accounts in the forest, the IAS server performs authentication.

This is accomplished by the configuration of the following connection request policy:

  • For authentication requests for which the User-Name attribute ends with the forest name, perform authentication on this server.

Wireless Remote Access Policy Settings

For each IAS server that is performing authentication and authorization as a RADIUS server, a wireless remote access policy is configured with the following settings:

  • Conditions: NAS-Port-Type=Wireless-IEEE 802.11

  • Permissions: Grant remote access permission.

  • Profile, Dial-in Constraints tab: Minutes server can remain idle before it is disconnected (Idle-Timeout) is set to 120. This forces a reauthentication for a wireless connection that has no activity for two hours.

  • Profile, Authentication tab: Extensible Authentication Protocol and the Smart Card or other Certificate EAP type selected. All other check boxes are cleared.

  • Profile, Encryption tab: Clear all other check boxes except the Strongest check box. This forces all wireless connections to use 128-bit encryption.

  • Profile, Advanced tab: Ignore-User-Dialin-Properties attribute set to True.

    To simplify the evaluation of authorization and the evaluation of connection constraints for wireless and ensure that wireless connections can be made, the wireless remote access policies for all the IAS servers acting as RADIUS servers are configured to ignore the settings on the Dial-in tab of computer and user accounts.

Centralized Logging to a SQL Server

Using the new SQL logging feature of Windows Server 2003 IAS, all connection information is logged to a central SQL server for analysis (not shown in Figure 4).

Summary

The Microsoft WLAN is a secure wireless network using a combination of IEEE 802.11b, IEEE 802.1X, EAP-TLS certificate-based authentication, RADIUS, certificates, and Active Directory. The wireless clients run Windows XP and the servers for the certificate and authentication infrastructure run Windows Server 2003. Computer certificates are deployed to wireless computers using auto-enrollment. User certificates and Windows XP wireless configuration information is deployed to wireless computers through an internal Web site and a CAPICOM script. The RADIUS infrastructure uses a combination of RADIUS servers and proxies to load balance and route RADIUS traffic for different Active Directory forests.

See the following resources for further information: