Current Deployment and Infrastructure

Current Deployment and Infrastructure

There are currently more than 3,200 wireless APs of the Microsoft WLAN installed worldwide, and the magnitude of this deployment created unique challenges for Microsoft in the areas of security and authentication. Microsoft OTG enlisted 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 the following:

  • Active Directory domain controllers

  • Windows Server 2003 certification authorities (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 SP3). Within the Microsoft Corpnet, there are the 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. This forest structure is shown in Figure 9-1.

figure 9-1 the structure of the corpnet.ms.com forest.

Figure 9-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.

More Info
For more information about the Microsoft Corpnet Active Directory infrastructure, search for the white paper titled Windows 2000: Designing and Deploying Active Directory Service for the MS Internal Corpnet at http: //www.microsoft.com/technet.

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 a Microsoft corporate decision 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, later in this chapter.)

Windows Server 2003 CAs

To issue user and computer certificates for wireless access and provide certificate revocation list (CRL) publication, the existing Microsoft PKI was used. To conform to 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 PKI hierarchy is shown in Figure 9-2.

figure 9-2 hierarchy for the microsoft pki.

Figure 9-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 Server 2003 member server.

More Info
For more information about PKI, see the Windows 2000 Security Services Web site at http://www.microsoft.com/windows2000/technologies /security/default.asp and the Windows Server 2003 Security Services Web site at http://www.microsoft.com/windowsserver2003/technologies/security/default.mspx.

To issue computer certificates, autoenrollment using the Automatic Certificate Request Settings in the Computer Configuration Group Policy 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 automatically updating Computer Configuration Group Policy settings.

To issue user certificates, Microsoft OTG staff created a CAPICOM script. Because autoenrollment of user certificates was not possible with Windows 2000 enterprise CAs that were originally in place, the other alternatives were 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 required no user intervention for selecting certificate settings.

To educate Microsoft users and provide a location from which the CAPICOM script could be launched, Microsoft OTG 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 autoenrollment) 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

At Microsoft, the operating system platform for wireless clients is Microsoft Windows XP, which includes built-in support for 802.11 and 802.1X. A wireless client user uses the Windows XP Wireless Zero Configuration (WZC) 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 user and computer certificates. All wireless network adapters used at Microsoft support the WZC service.

If Microsoft users have a wireless network at home, the WZC service enables them 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 its 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 that 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 relational database. Access point firmware and radio firmware software are deployed by upgrading a single wireless AP in each building and then use 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 configuration is shown in Figure 9-3.

figure 9-3 configuration of wireless aps as radius clients.

Figure 9-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 unless it becomes unavailable, at which time they switch to the secondary RADIUS server and use it exclusively. If the secondary RADIUS server becomes unavailable, the wireless APs switch back to the primary RADIUS server and use it exclusively. To balance the load of all authentications for all 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). 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 the RADIUS authentication load is approximately split in half between the two RADIUS servers in the domain (assuming that both RADIUS servers are available).

RADIUS Servers and Proxies Running Windows Server 2003

The RADIUS infrastructure for the Microsoft WLAN consists of pairs of domain member servers, each running Windows Server 2003 and Internet Authentication Service (IAS). The IAS servers act as RADIUS servers, RADIUS proxies, or both. Pairs are used to provide failover support in case one of the members of the pair becomes unavailable.

The RADIUS infrastructure is shown in Figure 9-4.

figure 9-4 radius infrastructure for the microsoft wlan.

Figure 9-4. RADIUS infrastructure for the Microsoft WLAN.

North America Child Domain

North America contains most of the wireless APs and accounts being authenticated. To accommodate this heavy load, IAS servers are 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 in the following way:

  • For accounts in the corpnet.ms.com forest, the IAS servers route messages from the wireless APs in North America to the North America RADIUS servers.

  • For accounts in the NT.Dev, Win.SE, or Win.Deploy forests, the IAS servers route messages from wireless APs in North America 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:

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

  2. 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).

  3. 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).

  4. 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).

  5. For Windows XP (prior to SP1), 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 configured as follows: For authentication requests for which the User-Name attribute begins with NorthAmerica/, 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 configured as follows: For authentication request for which the User-Name attribute begins with NT.Dev/, forward traffic to the NT.Dev remote RADIUS server group.

    With Windows XP (SP1 and later), Windows Server 2003, and Windows 2000, 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.

More Info
For more information about using Windows Server 2003 IAS as a RADIUS proxy and the configuration of connection request policies, see Chapter 4, RADIUS, IAS, and Active Directory.

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.

Forwarding of authentication requests to RADIUS servers in other forests is accomplished by the configuration of the following connection request policies in the following order:

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

  2. 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.

  3. 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.

  4. 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 the NT.Dev, Win.SE, and Win.Deploy forests, a pair of IAS servers acting as RADIUS servers performs the following:

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

This authentication 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 performs 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 setting 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. Clear all other check boxes.

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

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

    To simplify the evaluation of authorization and the evaluation of connection constraints for wireless and to 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 (refer to Figure 9-4).



Deploying Secure 802.11 Wireless Networks with Microsoft Windows
Deploying Secure 802.11 Wireless Networks with Microsoft Windows
ISBN: 0735619395
EAN: 2147483647
Year: 2000
Pages: 123
Authors: Joseph Davies

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net