Deployment of Protected 802.11 Networks Using Microsoft Windows

Article
09/11/2009

Abstract

This article describes how to deploy protected IEEE 802.11 wireless access in medium and large organizations with IEEE 802.1X authentication using wireless access points, wireless client computers running Microsoft® Windows Vista™, Windows® XP, or Windows Server® 2003, and a wireless authentication infrastructure consisting of Windows Server 2003 or Windows 2000 Server-based Active Directory® directory service domain controllers, certification authorities, and Internet Authentication Service servers.

Bb457068.3squares(en-us,TechNet.10).gif

Introduction

This article describes how to create an infrastructure for authentication, authorization, and accounting for protected wireless connections to an organization using Windows wireless clients. This is a typical configuration for an organization that uses the following:

Wireless client computers running Windows Vista, Windows XP, or Windows Server 2003.

Windows Vista, Windows XP, and Windows Server 2003 have built-in support for IEEE 802.11 wireless access and IEEE 802.1X authentication using the Extensible Authentication Protocol (EAP).
At least two Internet Authentication Service (IAS) servers.

At least two IAS servers (one primary and one secondary) are used to provide fault tolerance for Remote Authentication Dial-In User Service (RADIUS)-based authentication. If only one RADIUS server is configured and it becomes unavailable, wireless clients cannot connect. By using two IAS servers and configuring all wireless access points (APs) or switches (the RADIUS clients) for both the primary and secondary IAS servers, the RADIUS clients can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.

You can use either Windows Server 2003 or Windows 2000 Server IAS. IAS servers running Windows 2000 must have Windows 2000 SP4 installed. IAS is not included with Windows Server 2003, Web Edition.
Active Directory domains.

Active Directory domains contain the user accounts, computer accounts, and dial-in properties that each IAS server requires to authenticate credentials and evaluate authorization. While not a requirement, to both optimize IAS authentication and authorization response times and minimize network traffic, IAS should be installed on Active Directory domain controllers. You can use either Windows Server 2003 or Windows 2000 Server domain controllers. Windows 2000 domain controllers must have Windows 2000 SP4 installed.
Computer certificates installed on the IAS servers.

Regardless of which wireless authentication method you use—Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Protected EAP-TLS (PEAP-TLS), or PEAP-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2)—you must install computer certificates on the IAS servers.
For EAP-TLS or PEAP-TLS authentication, a certificate infrastructure.

When the EAP-TLS or PEAP-TLS authentication protocol is used with computer and user certificates on wireless clients, a certificate infrastructure, also known as a public key infrastructure (PKI), is needed to issue certificates to wireless clients.
For PEAP-MS-CHAP v2 authentication, root certification authority (CA) certificates on each wireless client.

PEAP-MS-CHAP v2 is a password-based protected authentication method for wireless connections. Depending on the issuing CA of the IAS server computer certificates, you might also have to install root CA certificates on each wireless client.
Wireless remote access policy.

An IAS remote access policy authorizes wireless connections so that employees can access the organization intranet.
Multiple wireless APs or switches.

Multiple third-party wireless APs or switches provide wireless access for different locations of an organization. The wireless APs or switches must support IEEE 802.1X, RADIUS, and either Wi-Fi Protected Access (WPA™) or Wi-Fi Protected Access 2 (WPA2™). Wired Equivalent Privacy (WEP) is recommended only for temporary use when transitioning to WPA or WPA2.

Figure 1 shows a typical wireless configuration for an organization using a protected wireless deployment.

Figure 1: Wireless configuration when using a protected wireless deployment

Figure 1: Wireless configuration when using a protected wireless deployment

For background information about the technologies, components, and processes of protected wireless authentication, see Wireless Deployment Technology and Component Overview.

Intranet Wireless Deployment Steps

For a protected wireless configuration, complete the following steps:

Configure the certificate infrastructure.
Configure Active Directory for accounts and groups.
Configure the primary IAS server on a computer.
Configure the secondary IAS server on another computer.
Deploy and configure wireless APs.
Configure Wireless Network (IEEE 802.11) Policies Group Policy settings.
Configure wireless clients for EAP-TLS or PEAP-TLS.
Configure wireless clients for PEAP-MS-CHAP v2.

Step 1: Configuring the Certificate Infrastructure

Table 1 summarizes the certificates needed for the different types of protected wireless authentication.

Authentication Type	Certificates on Wireless Client	Certificates on IAS Server
EAP-TLS or PEAP-TLS	Computer certificates User certificates Root CA certificates for issuers of IAS server computer certificates	Computer certificates Root CA certificates for issuers of wireless client computer and user certificates
PEAP-MS-CHAP v2	Root CA certificates for issuers of IAS server computer certificates	Computer certificates

EAP-TLS or PEAP-TLS

Computer certificates

User certificates

Root CA certificates for issuers of IAS server computer certificates

Computer certificates

Root CA certificates for issuers of wireless client computer and user certificates

PEAP-MS-CHAP v2

Root CA certificates for issuers of IAS server computer certificates

Computer certificates

Table 1: Authentication types and certificates

Regardless of which authentication method you use for wireless connections, you must install computer certificates on the IAS servers.

For PEAP-MS-CHAP v2, you do not have to deploy a certificate infrastructure to issue computer and user certificates for each wireless client computer. Instead, you can obtain individual certificates for each IAS server in your organization from a commercial CA and install them on the IAS servers. For more information, see "Step 3: Configuring the Primary IAS Server" and "Step 4: Configuring the Secondary IAS Server" in this article. Windows wireless clients include a number of root CA certificates for well known and trusted commercial CAs. If you obtain computer certificates from a commercial CA for which there is already an installed root CA certificate, there are no additional certificates to install on the Windows wireless clients. If you obtain computer certificates from a commercial CA for which there is not already an installed root CA certificate, you must install the root CA certificates for the issuers of the computer certificates installed on the IAS servers on each Windows wireless client. For more information, see "Step 8: Configuring Wireless Clients for PEAP-MS-CHAP v2" in this article.

For computer authentication with EAP-TLS or PEAP-TLS, you must install a computer certificate, also known as a machine certificate, on each wireless client computer. A computer certificate installed on the wireless client computer is used to authenticate the wireless client computer so that the computer can obtain network connectivity to the organization intranet and computer configuration Group Policy updates prior to user login. For user authentication with EAP-TLS or PEAP-TLS after a network connection is made and the user logs on, you must use a user certificate on the wireless client computer.

The computer certificate is installed on the IAS server computer so that during EAP-TLS or PEAP-TLS authentication, the IAS server has a certificate to send to the wireless client computer for mutual authentication, regardless of whether the wireless client computer authenticates with a computer certificate or a user certificate. The computer and user certificates submitted by the wireless client and IAS server during EAP-TLS or PEAP-TLS authentication must conform to the requirements specified in "Using a Third-Party CA" in this article.

In Windows Vista, Windows XP, Windows Server 2003, and Windows 2000 Server, you can view the certificate chain of an installed certificate from the Certification Path tab in the properties of a certificate in the Certificates snap-in. You can view the installed root CA certificates in the Trusted Root Certification Authorities\Certificates folder and you can view the intermediate CA certificates in the Intermediate Certification Authorities\Certificates folder.

In a typical certificate deployment in a large organization, the certificate infrastructure is configured using single root CA in a three-level hierarchy consisting of root CA/intermediate CAs/issuing CAs. Issuing CAs are configured to issue computer certificates or user certificates. When the computer or user certificate is installed on the wireless client, the issuing CA certificate, intermediate CA certificates, and the root CA certificate is also installed. When the computer certificate is installed on the IAS server computer, the issuing CA certificate, intermediate CA certificates, and the root CA certificate is also installed. The issuing CA for the IAS server certificate can be different than the issuing CA for the wireless client certificates. In this case, both the wireless client and the IAS server computer have all the required certificates to perform certificate validation for EAP-TLS or PEAP-TLS authentication.

Best Practice If you are using EAP-TLS or PEAP-TLS authentication, use both user and computer certificates.

If you are using EAP-TLS authentication, do not also use PEAP-TLS. Allowing both protected and unprotected authentication traffic for the same type of network connection renders the protected authentication traffic susceptible to spoofing attacks.

If you already have a certificate infrastructure for EAP-TLS or PEAP-TLS authentication and are using RADIUS for dial-up or virtual private network (VPN) remote access connections, you can skip some of the certificate infrastructure steps. You can use the same certificate infrastructure for wireless connections. However, you must ensure that computer certificates are installed for computer authentication. For computers running Windows XP with no service packs installed, you must have user certificates stored on the computer for user authentication (rather than using smart cards). For computers running Windows Vista, Windows XP with Service Pack 2 (SP2), Windows XP with Service Pack 1 (SP1), or Windows Server 2003, you can use either user certificates stored on the computer or a smart card for user authentication.

Step 1a: Installing a Certificate Infrastructure

When installing a certificate infrastructure, use the following best practices:

Plan your public key infrastructure (PKI) before deploying CAs.
The root CA should be offline and its signing key should be secured by a Hardware Security Module (HSM) and kept in a vault to minimize potential for key compromise.
Large organizations should not issue certificates to users or computers directly from the root CA, but rather should deploy the following:
- An offline root CA
- Offline intermediate CAs
- Online issuing CAs (using Windows Server 2003 or Windows 2000 Server Certificate Services as an enterprise CA)
This CA hierarchy provides flexibility and insulates the root CA from attempts to compromise its private key by malicious users. The offline root and intermediate CAs do not have to be Windows Server 2003 or Windows 2000 Server CAs. Issuing CAs can be subordinates of a third party intermediate CA.
Backing up the CA database, the CA certificate, and the CA keys is essential to protect against the loss of critical data. The CA should be backed up on a regular basis (daily, weekly, monthly) based on the number of certificates issued over the same interval. The more certificates issued, the more frequently you should back up the CA.
You should review the concepts of security permissions and access control in Windows, since enterprise CAs issue certificates based on the security permissions of the certificate requester.

Additionally, if you want to take advantage of autoenrollment for computer certificates, use Windows 2000 Server or Windows Server 2003 Certificate Services and create an enterprise CA at the issuer CA level. If you want to take advantage of autoenrollment for user certificates, use Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, Certificate Services and create an enterprise CA at the issuer CA level.

For more information, see the resources at the Public Key Infrastructure for Windows Server 2003 Web page.

By default, the IAS server checks for certificate revocation for all the certificates in the certificate chain sent by the wireless client during the EAP-TLS or PEAP-TLS authentication process. If certificate revocation fails for any of the certificates in the chain, authentication fails and the connection attempt is denied. The certificate revocation check for a certificate can fail because of the following:

The certificate has been revoked.

The issuer of the certificate has explicitly revoked the certificate.
The certificate revocation list (CRL) for the certificate is not reachable or available.

CAs maintain CRLs and publish them to specific CRL distribution points. The CRL distribution points are included in the CRL Distribution Points property of the certificate. If the CRL distribution points cannot be contacted to check for certificate revocation, then the certificate revocation check fails.

Additionally, if there are no CRL distribution points in the certificate, the IAS server cannot verify that the certificate has not been revoked and the certificate revocation check fails.
The publisher of the CRL did not issue the certificate.

Included in the CRL is the publishing CA. If the publishing CA of the CRL does not match the issuing CA for the certificate for which certificate revocation is being checked, then the certificate revocation check fails.
The CRL is not current

Each published CRL has a range of valid dates. If the CRL Next update date has passed, the CRL is considered invalid and the certificate revocation check fails. New CRLs should be published before the expiration date of the last published CRL.

Certificate revocation checking behavior for IAS can be modified with registry settings. For more information, see Troubleshooting Windows IEEE 802.11 Wireless Access.

Because certificate revocation checking can prevent wireless access due to the unavailability or expiration of CRLs for each certificate in the certificate chain, design your PKI for high availability of CRLs. For instance, configure multiple CRL distribution points for each CA in the certificate hierarchy and configure publication schedules that ensure that the most current CRL is always available.

Certificate revocation checking is only as accurate as the last published CRL. For example, if a certificate is revoked, by default the new CRL containing the newly revoked certificate is not automatically published. CRLs are typically published based on a configurable schedule. This means that the revoked certificate can still be used to authenticate because the published CRL is not current; it does not contain the revoked certificate and can therefore still be used to create wireless connections. To prevent this from occurring, the network administrator must manually publish the new CRL with the newly revoked certificate.

By default the IAS server uses the CRL distribution points in the certificates. However, it is also possible to store a local copy of the CRL on the IAS server. In this case, the local CRL is used during certificate revocation checking. If a new CRL is manually published to the Active Directory, the local CRL on the IAS server is not updated. The local CRL is updated when it expires. This can create a situation wherein a certificate is revoked, the CRL is manually published, but the IAS server still allows the connection because the local CRL has not yet been updated.

Step 1b: Installing Computer Certificates

If you are using a Windows Server 2003 or Windows 2000 Certificate Services enterprise CA as an issuing CA, you can install a computer certificate on the IAS server by configuring Group Policy for the autoenrollment of computer certificates for computers in an Active Directory container (a domain, site, or organizational unit).

To configure computer certificate autoenrollment for an enterprise CA

Open the Active Directory Users and Computers snap-in.
In the console tree, double-click Active Directory Users and Computers, right-click the domain name to which your CA belongs, and then click Properties.
On the Group Policy tab, click the appropriate Group Policy object (the default object is Default Domain Policy), and then click Edit.
In the console tree, open Computer Configuration, then Windows Settings, then Security Settings, then Public Key Policies, then Automatic Certificate Request Settings.
Right-click Automatic Certificate Request Settings, point to New, and then click Automatic Certificate Request.
The Automatic Certificate Request wizard appears. Click Next.
In Certificate templates, click Computer, and then click Next.

Your enterprise CA appears on the list.
Click the enterprise CA, click Next, and then click Finish.

After the domain is configured for autoenrollment, each computer that is a member of the domain requests a computer certificate when Computer Configuration Group Policy is refreshed. By default, the Winlogon service polls for changes in Group Policy every 90 minutes. To force a refresh of Computer Configuration Group Policy, restart the computer or type gpupdate /target:computer (for a computer running Windows Vista, Windows XP, or Windows Server 2003) or secedit /refreshpolicy machine_policy (for a computer running Windows 2000 Server) at a Windows command prompt

Perform this procedure for each domain container as appropriate.

Best Practice If you use a Windows Server 2003 or Windows 2000 enterprise CA as an issuing CA, configure autoenrollment of computer certificates to install computer certificates on all computers. Ensure that all appropriate domain containers are configured for autoenrollment of computer certificates either through the inheriting of group policy settings of a parent container or explicit configuration.

Step 1c: Installing User Certificates

If you are using a Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, enterprise CA as an issuing CA, you can install user certificates through autoenrollment. Configuring user certificate autoenrollment for wireless user certificates requires you to duplicate existing certificate templates, a feature that is only supported for Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, enterprise CAs.

Only Windows Vista, Windows XP, and Windows Server 2003 wireless clients support user certificate autoenrollment.

To configure user certificate autoenrollment for a Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, enterprise CA

Click Start, click Run, type mmc, and then click OK.
On the File menu, click Add/Remove Snap-in, and then click Add.
Under Snap-in, double-click Certificate Templates, click Close, and then click OK.
In the console tree, click Certificate Templates. All of the certificate templates will be displayed in the details pane.
In the details pane, click the User template.
On the Action menu, click Duplicate Template.
In the Display Name field, type WirelessUserAccess (example name).
Make sure that the Publish Certificate in Active Directory check box is selected.
Click the Security tab.
In the Group or user names field, click Domain Users.
In the Permissions for Domain Users list, select the Enroll and Autoenroll permission check boxes and then click OK.
Open the Certification Authority snap-in.
In the console tree, open Certification Authority, then the CA name, then Certificate Templates.
On the Action menu, point to New, and then click Certificate to Issue.
Click WirelessUserAccess (example name) and click OK.
Open the Active Directory Users and Computers snap-in.
In the console tree, double-click Active Directory Users and Computers, right-click the domain container that contains the wireless user accounts, and then click Properties.
On the Group Policy tab, click the appropriate Group Policy object (the default object is Default Domain Policy), and then click Edit.
In the console tree, open User Configuration, then Windows Settings, then Security Settings, then Public Key Policies.
In the details pane, double-click Autoenrollment Settings.
Click Enroll certificates automatically.
Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box.
Select the Update certificates that use certificate templates check box and click OK.

Perform steps 17-23 for each domain container as appropriate.

Best Practices If you use a Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, enterprise CA as an issuing CA, configure autoenrollment of user certificates to install user certificates on all computers. Ensure that all appropriate domain containers are configured for autoenrollment of user certificates either through the inheriting of group policy settings of a parent container or explicit configuration.

Step 2: Configuring Active Directory for Accounts and Groups

To configure Active Directory user and computer accounts and groups for wireless access, do the following:

If you are using Windows 2000 domain controllers, install Windows 2000 SP4 on all domain controllers.
Ensure that all users that are making wireless connections have a corresponding user account.
Ensure that all computers that are making wireless connections have a corresponding computer account.
Set the remote access permission on user and computer accounts to the appropriate setting (either Allow access or Control access through Remote Access Policy). The remote access permission setting is on the Dial-in tab on the properties of a user or computer account in the Active Directory Users and Computers snap-in. For a native-mode domain, new user and computer accounts have their remote access permission set to Control access through Remote Access Policy by default.
To simplify the configuration of a wireless remote access policy on the IAS servers, organize your wireless access user and computer accounts into the appropriate groups. For a native-mode domain, you can use universal and nested global groups. For example, create a universal group named WirelessUsers that contains global groups of wireless user and computer accounts for intranet access.

Best Practice Use a native-mode domain and universal groups and global groups to organize your wireless accounts into a single group.

Step 3: Configuring the Primary IAS Server

Configuring the primary IAS server on a computer involves the following:

Configuring IAS to be able to access account information, perform logging, use specified UDP ports, and for the RADIUS clients corresponding to the wireless APs.
Configuring a remote access policy for protected wireless access.

Step 3a: Configuring IAS

To configure the primary IAS server on a computer, do the following:

If you are using computer certificate autoenrollment and Windows Server 2003 IAS, force a refresh of Computer Configuration Group Policy by typing gpupdate /target:computer from a command prompt. If you are using computer certificate autoenrollment and Windows 2000 Server IAS, force a refresh of Computer Configuration Group Policy by typing secedit /refreshpolicy machine_policy from a command prompt.
If you are using PEAP-MS-CHAP v2 authentication and have obtained a computer certificate from a commercial CA, use the Certificates snap-in to import it into the Certificates (Local Computer)\ Personal\Certificates folder. To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. It is also possible to import a certificate by double-clicking a certificate file that is stored in a folder or sent in an email message. Although this works for certificates created with Windows CAs, this method does not work for third-party CAs. The recommended method of importing certificates is to use the Certificates snap-in.

For information about how to install a VeriSign, Inc. certificate for PEAP-MS-CHAP v2 authentication, see Obtaining and Installing a VeriSign WLAN Server Certificate for PEAP-MS-CHAP v2 Wireless Authentication.
Install IAS as an optional networking component.
If you are using Windows 2000 Server IAS, install Windows 2000 SP4.
The primary IAS server computer must be able to access account properties in the appropriate domains. If IAS is being installed on a domain controller, no additional configuration is required in order for IAS to access account properties in the domain of the domain controller.

If IAS is not installed on a domain controller, you must configure the primary IAS server computer to read the properties of user accounts in the domain. For more information, see the "Enable the IAS server to read user accounts in Active Directory" procedure in this section.

If the IAS server authenticates and authorizes wireless connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see the "Enable the IAS server to read user objects in Active Directory" procedure in this section.

If there are accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, you must configure a RADIUS proxy between the two untrusted domains. If there are accounts in other Active Directory forests, you must configure a RADIUS proxy between the forests. For more information, see “Cross-Forest Authentication” in this article.
If you want to store authentication and accounting information for connection analysis and security investigation purposes, enable logging for accounting and authentication events. Windows 2000 Server IAS can log information to a local file. Windows Server 2003 IAS can log information to a local file and to a Structured Query Language (SQL) server database. For more information, see the topic titled "Configure log file properties" in Windows 2000 Help and the topic titled "Configure logging for user authentication and accounting" in Windows Server 2003 Help and Support.
If needed, configure additional UDP ports for RADIUS authentication and accounting messages that are sent by RADIUS clients (the wireless APs). For more information, see the "Configure IAS port information" procedure in this section. By default, IAS uses UDP ports 1812 and 1645 for RADIUS authentication messages and UDP ports 1813 and 1646 for RADIUS accounting messages.
Add the wireless APs as RADIUS clients to the IAS server. For more information, see the "Add RADIUS clients" procedure in this section. Verify that you are configuring the correct name or IP address and RADIUS shared secret for each wireless AP.

Use a different shared secret for each wireless AP. Each shared secret should be a random sequence of upper and lowercase letters, numbers, and punctuation that is at least 22 characters long. To ensure randomness, use a random character generation program to create shared secrets to configure on the IAS server and the wireless AP.

To ensure the maximum security for RADIUS messages, it is recommended that you use Internet Protocol security (IPsec) Encapsulating Security Payload (ESP) with certificate authentication to provide data confidentiality, data integrity, and data origin authentication for RADIUS traffic sent between the IAS servers and the wireless APs. Windows Server 2003 and Windows 2000 Server support IPsec. IPsec must also be supported by the wireless APs.

Enable the IAS server to read user accounts in Active Directory

To register the IAS server in the default domain using Internet Authentication Service:

Log on to the IAS server with an account that has domain administrator permissions.
Open the Internet Authentication Service snap-in.
Right-click Internet Authentication Service, and then click Register Server in Active Directory. When the Register Internet Authentication Service in Active Directory dialog box appears, click OK.

To register the IAS server in the default domain using the netsh tool:

Log on to the IAS server with an account that has domain administrator permissions.
Open a command prompt.
At the command prompt, type: netsh ras add registeredserver

To register the IAS server in the default domain using Active Directory Users and Computers:

Log on to the IAS server with an account that has domain administrator permissions.
Open the Active Directory Users and Computers snap-in.
In the console tree, click the Users folder in the appropriate domain.
In the details pane, right-click RAS and IAS Servers, and then click Properties.
In the RAS and IAS Servers Properties dialog box, on the Members tab, add the IAS server.

To register the IAS server in another domain using Active Directory Users and Computers:

Log on to the IAS server with an account that has domain administrator permissions.
Open the Active Directory Users and Computers snap-in.
In the console tree, click the Users folder in the appropriate domain.
In the details pane, right-click RAS and IAS Servers, and then click Properties.
In the RAS and IAS Servers Properties dialog box, on the Members tab, add each of the appropriate IAS servers.

To register the IAS server in another domain using the netsh tool:

Log on to the IAS server with an account that has domain administrator permissions.
Open a command prompt.
At the command prompt, type: netsh ras add registeredserver Domain IASServer

in which Domain is the DNS domain name of the domain and IASServer is the name of the IAS server computer.

Configure IAS port information

Open the Internet Authentication Service snap-in.
Right-click Internet Authentication Service, and then click Properties.
For Windows Server 2003, click the Ports tab. For Windows 2000 Server IAS, click the RADIUS tab. Examine the settings for ports. If your RADIUS authentication and accounting UDP ports differ from the default values provided (1812 or 1645 for authentication and 1813 or 1646 for accounting), in Authentication and Accounting, type your port settings.

To use multiple ports for authentication or accounting requests, separate the ports with commas.

Add RADIUS clients

Open the Internet Authentication Service snap-in.
For Windows Server 2003 IAS, in the console tree, right-click RADIUS Clients, and then click New RADIUS Client. For Windows 2000 Server IAS, in the console tree, right-click Clients, and then click New Client.
In Friendly name, type a descriptive name.
In Protocol, click RADIUS, and then click Next.
In Client address (IP or DNS), type the DNS name or IP address for the client (the wireless AP or the wireless switch). If you are using a DNS name, click Verify. In the Resolve DNS Name dialog box, click Resolve, and then select the IP address you want to associate with that name from Search Results.
If you are planning to use wireless AP or switch-specific remote access policies for configuration purposes (for example, a remote access policy that contains vendor-specific attributes), click Client Vendor, and select the manufacturer's name. If you do not know the manufacturer or it is not in the list, click RADIUS Standard.
In Shared secret, type the RADIUS shared secret for the client, and then type it again in Confirm shared secret.
Click Finish.

Best Practices

If possible, use IPsec ESP to provide data confidentiality for RADIUS traffic between the wireless AP and the IAS servers. Use at least 3DES encryption and, if possible, certificates for Internet Key Exchange (IKE) main mode authentication.

Use RADIUS shared secrets that consist of a random sequence of upper and lower case letters, numbers, and punctuation at least 22 characters long and use a different shared secret for each wireless AP. If possible, use a random string-generating computer program to create the shared secret.

Step 3b: Configuring a Wireless Remote Access Policy

To configure a wireless remote access policy for the primary IAS server, do the following:

For Windows 2000 Server IAS, create a new remote access policy for wireless intranet access with the following settings:

Policy name: Wireless access to intranet (example)

Conditions: NAS-Port-Type=Wireless-Other and Wireless-IEEE 802.11, Windows-Groups=WirelessUsers

Permissions: Select Grant remote access permission.

Profile, Authentication tab: If you are using EAP-TLS authentication, select Extensible Authentication Protocol and the Smart Card or other Certificate EAP type. Clear all other check boxes. If you have multiple computer certificates installed on the IAS server, click Configure, and then select the appropriate computer certificate. If the intended computer certificate is not displayed, then it does not support SChannel.

If you are using PEAP-TLS authentication, select Extensible Authentication Protocol and the Protected EAP (PEAP) EAP type, and then click Configure. In the Protected EAP Properties dialog box, select the appropriate computer certificate and ensure that Smart Card or other Certificate is selected as the EAP type.

If you are using PEAP-MS-CHAP v2 authentication, select Extensible Authentication Protocol and the Protected EAP (PEAP) EAP type, and then click Configure. In the Protected EAP Properties dialog box, select the appropriate computer certificate and ensure that Secured password (EAP-MSCHAP v2) is selected as the EAP type.

Profile, Encryption tab: Clear all other check boxes except the Strongest check box. This forces all wireless connections to use 128-bit encryption. The settings on the Encryption tab correspond to the MS-MPPE-Encryption-Policy and MS-MPPE-Encryption-Types RADIUS attributes and might be supported by the wireless AP. If these attributes are not supported, clear all the check boxes except No encryption.

For more information, see the "Add a remote access policy" procedure in this section.
For Windows Server 2003 IAS, use the New Remote Access Policy Wizard to create a common remote access policy with the following settings:

Policy name: Wireless access to intranet (example)

Access Method: Wireless

User or Group Access: Group with the WirelessUsers group selected (example group name)

Authentication Methods: Smart Card or other Certificate type (for EAP-TLS) or Protected EAP (PEAP) type (for PEAP-MS-CHAP v2)
If the wireless APs require vendor specific attributes (VSAs), you must add the VSAs to the remote access policy. For more information, see the "Configure vendor-specific attributes for a remote access policy" procedure in this section.
For Windows 2000 Server IAS, delete the default remote access policy named Allow access if dial-in permission is enabled. To delete a remote access policy, right-click the policy name in the Internet Authentication Service snap-in and click Delete.

Best Practice If you are managing the remote access permission of user and computer accounts on a per-account basis, use remote access policies that specify a connection type. If you are managing the remote access permission through the remote access policy, use remote access policies that specify a connection type and group. The recommended method is to manage remote access permission through the remote access policy.

Add a remote access policy

Open the Internet Authentication Service snap-in.
In the console tree, right-click Remote Access Policies, and then click New Remote Access Policy.

Configure vendor-specific attributes for a remote access policy

Open the Internet Authentication Service snap-in.
In the console tree, click Remote Access Policies.
In the details pane, double-click the policy for which you want to configure a vendor-specific attribute (VSA).
Click Edit Profile, click the Advanced tab, and then click Add.
Look at the list to see whether your vendor-specific attribute is already in the list of available RADIUS attributes. If it is, double-click it, and then configure it as specified in your wireless AP documentation.
If the vendor-specific attribute is not in the list of available RADIUS attributes, click the Vendor-Specific attribute, and then click Add.
In the Multivalued Attribute Information dialog box, click Add.
Specify the vendor for your wireless AP or switch. To specify the vendor by selecting the name from the list, click Select from list, and then select the vendor of the wireless AP or switch for which you are configuring the VSA. If the vendor is not listed, specify the vendor by typing the vendor code.
To specify the vendor by typing the vendor code, click Enter Vendor Code and then type the vendor code in the space provided. See RFC 1007 for a list of SMI Network Management Private Enterprise Codes.
Specify whether the attribute conforms to the VSA format specified in RFC 2865. If you are not sure, see your wireless AP documentation.
If your attribute conforms, click Yes. It conforms, and then click Configure Attribute. In Vendor-assigned attribute number, type the number assigned to the attribute (this should be an integer from 0 to 255). In Attribute format, specify the format for the attribute, and then in Attribute value, type the value you are assigning to the attribute.
If the attribute does not conform, click No. It does not conform, and then click Configure Attribute. In Hexadecimal attribute value, type the value for the attribute.

Best Practice Investigate whether the wireless APs or switches need VSAs and configure them during the configuration of the remote access policy. If you configure the VSAs after you configure the wireless APs or switches, you have to re-synchronize the configuration of the primary IAS server to the secondary IAS server.

Step 4: Configuring the secondary IAS server

To configure the secondary IAS server on another computer, do the following:

If you are using computer certificate autoenrollment and Windows Server 2003 IAS, force a refresh of Computer Configuration Group Policy by typing gpupdate /target:computer from a command prompt. If you are using computer certificate autoenrollment and Windows 2000 Server IAS, force a refresh of Computer Configuration Group Policy by typing secedit /refreshpolicy machine_policy from a command prompt.
If you are using PEAP-MS-CHAP v2 authentication and have obtained a computer certificate from a commercial CA, use the Certificates snap-in to import it into the Certificates (Local Computer)\ Personal\Certificates folder.
Install IAS as an optional networking component.
If you are using Windows 2000 Server IAS, install Windows 2000 SP4.
The secondary IAS server computer must be able to access account properties in the appropriate domains. If IAS is being installed on a domain controller, no additional configuration is required in order for IAS to access account properties in the domain of the domain controller.

If IAS is not installed on a domain controller, you must configure the secondary IAS server computer to read the properties of user accounts in the domain. For more information, see the "Enable the IAS server to read user accounts in Active Directory" procedure previously described.

If the secondary IAS server authenticates and authorizes connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see the "Enable the IAS server to read user objects in Active Directory" procedure previously described.

If there are accounts in other domains, and those domains do not have a two-way trust with the domain in which the secondary IAS server computer is a member, you must configure a RADIUS proxy between the two untrusted domains. If there are accounts in other Active Directory forests, you must configure a RADIUS proxy between the forests. For more information, see “Cross-Forest Authentication” in this article.
To copy the configuration of the primary IAS server to the secondary IAS server, type netsh aaaa show config > path\file.txt at a command prompt on the primary IAS server. This stores the configuration settings, including registry settings, in a text file. The path can be relative, absolute, or a network path.
Copy the file created in step 6 to the secondary IAS server. At a command prompt on the secondary IAS server, type netsh exec path\file.txt . This command imports all the settings configured on the primary IAS server to the secondary IAS server.

Note You cannot copy the IAS settings from an IAS server running Windows Server 2003 to an IAS server running Windows 2000 Server.

Best Practice If you change the IAS server configuration in any way, use the Internet Authentication Service snap-in to change the configuration of the primary IAS server and then use steps 6 and 7 in the preceding procedure to synchronize those changes on the secondary IAS server.

Step 5: Deploying and Configuring Wireless APs

Deploy your wireless APs or switches to provide coverage for all the areas of coverage for your wireless network. Configure your wireless APs or switches to support WPA, WPA2, or WEP encryption with 802.1X authentication. Additionally, configure RADIUS settings on your wireless APs or switches with the following:

The IP address or name of a primary RADIUS server, the RADIUS shared secret, UDP ports for authentication and accounting, and failure detection settings.
The IP address or name of a secondary RADIUS server, the RADIUS shared secret, UDP ports for authentication and accounting, and failure detection settings.

To balance the load of RADIUS traffic between the two IAS servers, configure half of the wireless APs or switches with the primary IAS server as the primary RADIUS server and the secondary IAS server as the secondary RADIUS server and the other half of the wireless APs or switches with the secondary IAS server as the primary RADIUS server and the primary IAS server as the secondary RADIUS server.

For more information about how to configure RADIUS settings, see the documentation for the wireless AP or switch.

If the wireless APs or switches require vendor specific attributes (VSAs) or additional RADIUS attributes, you must add the VSAs or attributes to the remote access policies of the IAS servers. For more information about VSAs, see the "Configure vendor-specific attributes for a remote access policy" procedure previously described. If you add VSAs or RADIUS attributes to the remote access policy on the primary IAS server, perform steps 6 and 7 of the “Step 4: Configuring the secondary IAS server” procedure to copy the primary IAS server configuration to the secondary IAS server.

Step 6: Configuring Wireless Network (IEEE 802.11) Policies Group Policy Settings

With the Wireless Network (IEEE 802.11) Policies Group Policy extension provided in Windows Server 2003, you can specify a list of preferred networks and their settings to automatically configure wireless LAN settings for wireless clients running Windows Vista, Windows XP with SP2, Windows XP with SP1, or Windows Server 2003. For each preferred network, you can specify association settings (such as the wireless network name and the authentication and encryption method) and 802.1X authentication settings (such as the EAP type).

To configure Wireless Network (IEEE 802.11) Policies Group Policy settings, do the following:

Open the Active Directory Users and Computers snap-in.
In the console tree, double-click Active Directory Users and Computers, right-click the domain container that contains your wireless computer accounts, and then click Properties.
On the Group Policy tab, click the appropriate Group Policy object (the default object is Default Domain Policy), and then click Edit.
In the console tree, open Computer Configuration, then Windows Settings, then Security Settings, then Wireless Network (IEEE 802.11) Policies.
Right-click Wireless Network (IEEE 802.11) Policies, and then click Create Wireless Network Policy. In the Wireless Network Policy Wizard, type a name and description.
In the details pane, double-click your newly created wireless network policy.
Change settings on the General tab as needed.
Click the Preferred Networks tab. Click Add to add a preferred network.
On the Network Properties tab, type the wireless network name (SSID) and change wireless network key settings as needed.
Click the IEEE 802.1x tab. Change 802.1X settings as needed, including specifying and configuring the correct EAP type. Click OK twice to save changes.

For more information about wireless Group Policy settings, see Configuring Wireless Settings Using Windows Server 2003 Group Policy.

The next time your Windows Vista, Windows XP with SP2, Windows XP with SP1, or Windows Server 2003 wireless clients update Computer Configuration Group Policy, their wireless network configuration will be automatically updated.

Wireless Group Policy and WPA

The version of the Wireless Network (IEEE 802.11) Policies Group Policy extension in Windows Server 2003 with no service packs installed does not support the configuration of WPA authentication and encryption settings for WPA-capable Windows wireless client computers. However, support for WPA settings configured through the Wireless Network (IEEE 802.11) Policies Group Policy extension has been added to Windows Server 2003 with either Windows Server 2003 SP1 or the 811233 update.

Wireless Group Policy and Windows 2000 Domains

To get the new Wireless Network (IEEE 802.11) Policies Group Policy extension in a Windows 2000 Active Directory domain, the Active Directory schema must be updated to include the new extension. To update the Windows 2000 Active Directory schema, you must install at least one domain controller in your Windows 2000 Active Directory domain that runs either Windows Server 2003 with no service packs installed or Windows Server 2003 with SP1 (for WPA authentication and encryption settings). Then, you must use the Group Policy Object Editor snap-in from any domain member computer running either Windows Server 2003 with no service packs installed or Windows Server 2003 with SP1 to configure Wireless Network (IEEE 802.11) Policies settings.

Wireless Group Policy and WPA2 Settings

To configure WPA2 authentication settings for wireless clients running Windows XP with SP2 using the Wireless Network (IEEE 802.11) Policies Group Policy extension, the client computers must be members of a Windows Server 2003 Active Directory domain and have the Wireless Client Update for Windows XP with Service Pack 2 installed. The WPA2 authentication settings in the Wireless Network (IEEE 802.11) Policies Group Policy extension must be configured from the Group Policy Object Editor snap-in running on a computer running Windows Vista.

For an example configuration in a test lab, see the Windows Vista Wireless Networking Evaluation Guide.

The WPA2 authentication settings configured in this way for Windows XP with SP2 wireless clients also apply to Windows Vista wireless clients.

Enhanced Wireless Group Policy Settings for Windows Vista

Windows Vista supports an enhanced set of wireless Group Policy settings designed for use by Windows Vista and Windows Server “Longhorn” wireless clients. Windows Vista supports both Windows XP-based Group Policy settings and Windows Vista-based Group Policy settings. The Windows Vista-based Group Policy settings include the ability to configure multiple profiles and their order, lists of wireless networks that are either allowed or denied, and Single Sign On settings. When both types of wireless settings are configured, Windows Vista wireless clients use the Windows Vista settings. If the Windows Vista wireless settings are not configured, Windows Vista wireless clients use the Windows XP wireless settings.

The Windows Vista-based wireless settings can be configured in a Windows Server “Longhorn” Active Directory domain using the Group Policy Object Editor snap-in from a computer running Windows Vista. However, Windows Server “Longhorn” is currently in beta testing.

To configure and use Windows Vista-based wireless settings in a Windows Server 2003 Active Directory domain, you must extend your Windows Server 2003 Active Directory schema to support the new Windows Vista-based wireless settings. For more information and the directory extension file, see Active Directory Schema Extensions for Windows Vista Wireless and Wired Group Policy Enhancements. After extending your schema, configure Windows Vista-based wireless settings from the Group Policy Object Editor snap-in on a computer running Windows Vista.

For an example configuration in a test lab, see the Windows Vista Wireless Networking Evaluation Guide.

Step 7: Configuring Wireless Clients for EAP-TLS or PEAP-TLS

Configuring wireless clients for EAP-TLS or PEAP-TLS involves the following steps:

Step 7a: Install computer certificates on wireless clients
Step 7b: Install user certificates on wireless clients
Step 7c: Configure wireless clients for EAP-TLS or PEAP-TLS

Step 7a: Installing Computer Certificates on Wireless Clients

For computer authentication with EAP-TLS or PEAP-TLS, you must install a computer certificate on the wireless client computer.

To install a computer certificate on a wireless client computer running Windows Vista, Windows XP, or Windows Server 2003, connect to the organization intranet using an Ethernet port and do the following:

If the domain is configured for autoenrollment of computer certificates, each computer that is a member of the domain requests a computer certificate when Computer Configuration Group Policy is refreshed. To force a refresh of Computer Configuration Group Policy for a computer running Windows Vista, Windows XP, or Windows Server 2003, restart the computer or type gpupdate /target:computer at a command prompt.
If the domain is not configured for autoenrollment, you can request a “Computer” certificate using the Certificates snap-in or you can execute a CAPICOM script to install a computer certificate.

Additionally, a large organization's information technology (IT) group can install a computer certificate before the computer, typically a laptop, is delivered to its user.

For information about CAPICOM, search for "CAPICOM" at https://msdn.microsoft.com/.

Step 7b: Install User Certificates on Wireless Clients

For user authentication with EAP-TLS, you must use a locally installed user certificate or a smart card. The locally installed user certificate must be obtained through autoenrollment, Web enrollment, by requesting the certificate using the Certificates snap-in, by importing a certificate file, or by running a CAPICOM program or script.

The easiest methods of installing user certificates assume that network connectivity already exists, such as using an Ethernet port. When the user connects to the intranet, they can obtain a user certificate through autoenrollment or by submitting a user certificate request using Web enrollment or the Certificate snap-in. For more information about requesting a user certificate, see the “Submit a user certificate request via the Web” and "Request a certificate" procedures in this section.

Alternately, the user can run a CAPICOM program or script provided by the network administrator. The execution of the CAPICOM program or script can be automated through the user logon script.

If you have configured autoenrollment of user certificates, then the wireless user must update User Configuration Group Policy to obtain a user certificate.

If you are not using autoenrollment for user certificates, use one of the following procedures to obtain a user certificate.

Submit a user certificate request via the Web

Open Internet Explorer.
In Internet Explorer, connect to http://servername/certsrv, where servername is the name of the Windows Server 2003 or Windows 2000 Server Web server where the CA you want to access is located.
Click Request a certificate, and then click Next.
On the Choose Request Type Web page, under User certificate request, select the type of certificate you want to request, and click Next.
Do one of the following from the Identifying Information Web page:

If you see the message "All the necessary identifying information has already been collected. You may now submit your request," click Submit.

Enter your identifying information for the certificate request, and click Submit.
If you see the Certificate Issued Web page, click Install this certificate.
Close Internet Explorer.

Request a certificate with the Certificates snap-in

Open an MMC console that contains Certificates – Current User.
In the console tree, right-click Personal, then point to All Tasks, and then click Request New Certificate to start the Certificate Request wizard.
In the Certificate Request Wizard, select the following information:

The type of certificate you want to request.

If you have selected the Advanced check box:
- The cryptographic service provider (CSP) you are using.
- The key length (measured in bits) of the public key associated with the certificate.
- Do not enable strong private key protection.
- If you have more than one CA available, select the name of the CA that will issue the certificate.
Type a friendly name for your new certificate.
After the Certificate Request Wizard has successfully finished, click OK.

Disk-Based Installation

Another method of installing a user certificate is to export the user certificate onto a disk (such as a floppy disk, CD-ROM, or USB drive) and import it from the disk onto the wireless client computer. For a disk-based enrollment, perform the following:

Obtain a user certificate for the wireless client's user account from the CA through Web-based enrollment. For more information, see the "Submit a user certificate request via the Web" procedure previously described.
Export the user certificate of the wireless client's user account to a .pfx file. For more information, see the "Export a certificate" procedure in this section. Within the Certificate Manager Export wizard, export the private key and select Delete the private key if the import is successful. Save this file to a disk and deliver it to the user of the wireless client computer.
On the wireless client computer, import the user certificate. For more information, see the "Import a certificate" procedure in this section.

Export a certificate

Open an MMC console containing Certificates - Current User.
Open Personal, and then open Certificates.
In the details pane, right-click the certificate you want to export, point to All Tasks, and then click Export.
In the Certificate Export Wizard, click Yes, export the private key. (This option will appear only if the private key is marked as exportable and you have access to the private key.) Click Next.
Select Personal Information Exchange – PKCS (.PFX) as the export file format and click Next.
On the Password page, type a password in Password and Confirm password to protect the private key in the certificate and then click Next.
On the File to Export page, type the certificate filename or click Browse to specify the name and location of the certificate file. Click Next.
On the Completing the Certificate Export Wizard page, click Finish.

Import a certificate

Open an MMC console containing Certificates - Current User.
Open Personal, and then open Certificates.
In the details pane, right-click the certificate you want to export, point to All Tasks, and then click Import.
Type the file name containing the certificate to be imported. (You can also click Browse and navigate to the file.)
If it is a PKCS #12 file, do the following:

Type the password used to encrypt the private key.

(Optional) If you want to be able to use strong private key protection, select the Enable strong private key protection check box.

(Optional) If you want to back up or transport your keys at a later time, select the Mark key as exportable check box.
Do one of the following:

If the certificate should be automatically placed in a certificate store based on the type of certificate, select Automatically select the certificate store based on the type of certificate.

If you want to specify where the certificate is stored, select Place all certificates in the following store, click Browse, and select the certificate store to use.

Step 7c: Configuring Wireless Clients for EAP-TLS or PEAP-TLS

If you have configured settings for the Wireless Network (IEEE 802.11) Policies Group Policy extension and specified the use of EAP-TLS authentication (the Smart Card or other Certificate EAP type) or PEAP-TLS authentication (the Protected EAP (PEAP) EAP type with the Smart Card or other Certificate PEAP type) for your wireless network, no other configuration is needed for wireless clients running Windows Vista, Windows XP with SP2, Windows XP with SP1, or Windows Server 2003.

To manually configure EAP-TLS authentication on a wireless client running Windows Vista, do the following:

From the Network and Sharing Center, click the Manage wireless networks task. In the Manage Wireless Networks window, double-click your wireless network name.
Click the Security tab. In Security type, select 802.1x, WPA-Enterprise, or WPA2-Enterprise. In Choose a network authentication method, select Smart Card or other certificate, and then click Settings.
In the Smart Card or other Certificate Properties dialog box, select Use a certificate on this computer to use a registry-based user certificate or Use my smart card for a smart card-based user certificate.

If you want to validate the computer certificate of the IAS server, select Validate server certificate (recommended and enabled by default). If you want to specify the names of the IAS servers that must perform the TLS authentication, select Connect to these servers and type the names.
Click OK twice.

You can also manually configure wireless clients running Windows Vista with a wireless network that uses EAP-TLS authentication by importing a wireless profile in Extensible Markup Language (XML) format with the netsh wlan add profile command. To create an XML-based wireless profile, configure a Windows Vista wireless client with a wireless network that has all the appropriate settings (including EAP-TLS authentication). You can also create, configure, and export an XML profile from the Wireless Network (IEEE 802.11) Policies Group Policy extension for Windows Vista. Then, use the netsh wlan export profile command to write the wireless network profile to an XML file. For more information, see Netsh Commands for Wireless Local Area Network (wlan).

To manually configure EAP-TLS authentication on a wireless client running Windows XP with SP2, Windows XP with SP1, or Windows Server 2003, do the following:

Obtain properties of the wireless connection in the Network Connections folder. Click the Wireless Networks tab, then click the name of the wireless network in the list of preferred networks and click Properties.
Click the Authentication tab and select Enable network access control using IEEE 802.1X and the Smart Card or other Certificate EAP type. This is enabled by default.
Click Properties. In the properties of the Smart Card or other Certificate EAP type, select Use a certificate on this computer to use a registry-based user certificate or Use my smart card for a smart card-based user certificate.

If you want to validate the computer certificate of the IAS server, select Validate server certificate (recommended and enabled by default). If you want to specify the names of the authentication servers that must perform the TLS authentication, select Connect to these servers and type the names.
Click OK to save changes to the Smart Card or other Certificate EAP type.

To configure EAP-TLS authentication on a wireless client running Windows XP with no service packs installed, do the following:

Obtain properties of the wireless connection in the Network Connections folder. Click the Authentication tab, and then select Enable network access control using IEEE 802.1X and the Smart Card or other Certificate EAP type. This is enabled by default.
Click Properties. In the properties of the Smart Card or other Certificate EAP type, select Use a certificate on this computer.

If you want to validate the computer certificate of the IAS server, select Validate server certificate (recommended and enabled by default).

If you want to ensure that the server’s DNS name ends in a specific string, select Connect only if server name ends with and type the string. For typical deployments where more than one IAS server is used, type the part of the DNS name that is common to all of the IAS servers. For example, if you have two IAS servers named IAS1.example.microsoft.com and IAS2.example.microsoft.com, then type the string "example.microsoft.com". Ensure that you type the correct string, otherwise, authentication will fail.
Click OK to save changes to the Smart Card or other Certificate EAP type.

To manually configure PEAP-TLS authentication on a wireless client running Windows Vista, do the following:

From the Network and Sharing Center, click the Manage wireless networks task. In the Manage Wireless Networks window, double-click your wireless network name.
Click the Security tab. In Security type, select 802.1x, WPA-Enterprise, or WPA2-Enterprise. In Choose a network authentication method, select Protected EAP (PEAP), and then click Settings.
In the Protected EAP Properties dialog box, if you want to validate the computer certificate of the IAS server for the PEAP authentication, select Validate server certificate (recommended and enabled by default). If you want to specify the names of the IAS servers that must perform the PEAP authentication, select Connect to these servers and type the names.
In Select Authentication Method, click Smart Card or other certificate. Click Configure. In the Smart Card or other Certificate Properties dialog box, select Use a certificate on this computer to use a registry-based user certificate or Use my smart card for a smart card-based user certificate.

If you want to validate the computer certificate of the IAS server for the TLS authentication, select Validate server certificate (recommended and enabled by default). If you want to specify the names of the IAS servers that must perform the TLS authentication, select Connect to these servers and type the names.
Click OK to save changes to the Smart Card or other Certificate PEAP type. Click OK to save the changes to the Protected EAP type. Click OK to save the changes to the wireless network configuration.

You can also manually configure wireless clients running Windows Vista with a wireless network that uses PEAP-TLS authentication by importing a wireless profile containing PEAP-TLS authentication settings with the netsh wlan add profile command.

To manually configure PEAP-TLS authentication on a wireless client running Windows XP with SP2, Windows XP with SP1, or Windows Server 2003, do the following:

Obtain properties of the wireless connection in the Network Connections folder. Click the Wireless Networks tab, click the name of the wireless network in the list of preferred networks, and then click Properties.
Click the Authentication tab and select Enable network access control using IEEE 802.1X and the Protected EAP EAP type.
Click Properties. In the Protected EAP Properties dialog box, select Validate server certificate to validate the computer certificate of the IAS server for the PEAP authentication (recommended and enabled by default). If you want to specify the names of the authentication servers that must perform PEAP authentication, select Connect to these servers and type the names. In Select Authentication Method, click Smart Card or other Certificate.
Click Configure. In the Smart Card or other Certificate Properties dialog box, select Use a certificate on this computer to use a registry-based user certificate or Use my smart card for a smart card-based user certificate.

If you want to validate the computer certificate of the IAS server for the TLS authentication, select Validate server certificate (recommended and enabled by default). If you want to specify the names of the IAS servers that must perform the TLS authentication, select Connect to these servers and type the names.
Click OK to save changes to the Smart Card or other Certificate PEAP type. Click OK to save the changes to the Protected EAP type. Click OK to save the changes to the wireless network configuration.

Step 8: Configuring Wireless Clients for PEAP-MS-CHAP v2

If you have configured settings for the Wireless Network (IEEE 802.11) Policies Group Policy extension and specified the use of PEAP-MS-CHAP v2 authentication for your wireless network (the Protected EAP (PEAP) type with the Secured password (EAP-MSCHAP v2) authentication method), no other configuration for wireless clients running Windows Vista, Windows XP with SP2, Windows XP with SP1, or Windows Server 2003 is needed.

To manually configure PEAP-MS-CHAP v2 authentication on a wireless client running Windows Vista, do the following:

From the Network and Sharing Center, click the Manage wireless networks task. In the Manage Wireless Networks window, double-click your wireless network name.
Click the Security tab. In Security type, select 802.1x, WPA-Enterprise, or WPA2-Enterprise. In Choose a network authentication method, select Protected EAP (PEAP), and then click Settings.
In the Protected EAP Properties dialog box, if you want to validate the computer certificate of the IAS server for the PEAP authentication, select Validate server certificate (recommended and enabled by default). If you want to specify the names of the IAS servers that must perform the PEAP authentication, select Connect to these servers and type the names.
In Select Authentication Method, select Secured password (EAP-MS-CHAP v2).
Click OK twice.

You can also manually configure wireless clients running Windows Vista with a wireless network that uses PEAP-MS-CHAP v2 authentication by importing a wireless profile containing PEAP-MS-CHAP v2 authentication settings with the netsh wlan add profile command.

To manually configure PEAP-MS-CHAP v2 authentication on a wireless client running Windows XP with SP2, Windows XP with SP1, or Windows Server 2003, do the following:

Obtain properties of the wireless connection in the Network Connections folder. Click the Wireless Networks tab, click the name of the wireless network in the list of preferred networks, and then click Properties.
Click the Authentication tab and select Enable network access control using IEEE 802.1X and the Protected EAP EAP type.
Click Properties. In the Protected EAP Properties dialog box, select Validate server certificate to validate the computer certificate of the IAS server (enabled by default). If you want to specify the names of the authentication servers that must perform validation, select Connect to these servers and type the names. In Select Authentication Method, click Secured password (EAP-MSCHAP v2).

If the root CA certificate of the issuer of the computer certificates installed on the IAS servers is already installed as a root CA certificate on your wireless clients, no other configuration is necessary. If your issuing CA is a Windows 2000 Server or Windows Server 2003 online root enterprise CA, then the root CA certificate is automatically installed on each domain member through computer configuration Group Policy.

To verify, obtain the properties of the computer certificate on the IAS server using the Certificates snap-in and view the certificate chain from the Certification Path tab. The certificate at the top of the path is the root CA certificate. Use the Certificates snap-in of a wireless client for each Windows operating system to ensure that this certificate is in the list of trusted root certification authorities in the Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates folder.

If it is not, you must install the root CA certificate(s) of the issuer(s) of the computer certificates of the IAS servers on each wireless client for the Windows operating systems that do not contain them.

The easiest way to install a root CA certificate on all your wireless clients is to do the following:

Using the Certificates snap-in on an IAS server, export the root CA certificate of the issuing CA of computer certificates on the IAS servers to a file (*.PB7). You can find the root CA certificate in the Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates folder.
Open the Active Directory Users and Computers snap-in.
In the console tree, double-click Active Directory Users and Computers, right-click the appropriate domain container, and then click Properties.
On the Group Policy tab, click the appropriate Group Policy object (the default object is Default Domain Policy), and then click Edit.
In the console tree, open Computer Configuration, then Windows Settings, then Security Settings, and then Public Key Policies.
Right-click Trusted Root Certification Authorities, and then click Import.
In the Certificate Import Wizard, specify the file that was saved in Step 1.
Repeat steps 3-7 for all appropriate containers.

The next time the wireless client computers update their computer configuration Group Policy, the root CA certificate of the issuing CA of computer certificates on the IAS servers is installed in their local computer certificate store.

Alternately, you can use the Certificates snap-in to import the root CA certificates to the Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates folder on each wireless client computer.

Additional Intranet Wireless Deployment Configurations

The section describes the following additional intranet wireless deployment configurations:

Internet access for business partners
Using a third-party CA
Cross-forest authentication
Using RADIUS proxies to scale authentications

Internet Access for Business Partners

The following is the behavior of most wireless APs in use today with respect to the receipt of RADIUS Access-Accept and Access-Reject messages:

When the wireless AP receives an Access-Accept message, the connection is allowed.
When the wireless AP receives an Access-Reject message, the connection is denied.

To allow a business partner, vendor, or other non-employee to gain access to a separate network using the same wireless infrastructure that allows employees to access to the organization intranet, the connection request must result in an Access-Accept message from the RADIUS server. To get an Access-Accept message from the RADIUS server, you must either use guest access or the business partner, vendor, or other non-employee must have a valid account and certificates.

Using Guest Access

Guest access occurs when wireless clients are connected without sending a user identity. The wireless client does not provide a user name or credentials to the wireless AP. Therefore, the wireless AP does not include user identity (the User-Name attribute) or credential attributes in the Access-Request message. When the IAS server receives an Access-Request message that contains no user identity or credentials attributes, it verifies whether unauthenticated access is enabled for the remote access policy that matches the connection attempt. If a user identity attribute is not included, the IAS server uses the Guest account to obtain user account dial-in properties and group membership. If a user identity attribute is included but credential attributes are not, the IAS server uses the indicated account to obtain user account dial-in properties and group membership.

Restricted network access for guest access clients is supported on wireless APs by using IP filtering or VLANs. To specify a virtual LAN identifier for unauthenticated access, configure the Tunnel-Type and Tunnel-Pvt-Group-ID attributes on the advanced properties of the appropriate remote access policy.

For more information about unauthenticated and guest access with IAS, see Windows 2000 Server Help or Windows Server 2003 Help and Support.

Using Validated Access

For validated access for business partners, vendors, or other non-employees, you must create computer and user accounts and issue certificates for each business partner, vendor, or other non-employee. Next, create groups with these accounts as members so that you can manage access using group-based remote access policies. For example, create a WirelessInternetUsers that contains global groups of business partner, vendor, or other non-employee user and computer accounts.

To configure a wireless remote access policy for Internet access for business partners, vendors, or other non-employees, create a new custom remote access policy for wireless Internet access with the following settings:

Policy name: Wireless access to Internet (example)
Conditions: NAS-Port-Type=Wireless-Other or Wireless-IEEE 802.11, Windows-Groups=WirelessInternetUsers
Permissions: Select Grant remote access permission.
Profile, Authentication tab: For Windows 2000 Server IAS, select Extensible Authentication Protocol and the Smart Card or other Certificate EAP type. Clear all other check boxes. If you have multiple computer certificates installed on the IAS server, click Configure, and then select the appropriate computer certificate.

For Windows Server 2003 IAS, clear all other check boxes. Click EAP Methods and add the Smart Card or other Certificate EAP type. If you have multiple computer certificates installed on the IAS server, click Edit, and then select the correct computer certificate.
Profile, Encryption tab: If the wireless AP supports the MS-MPPE-Encryption-Policy and MS-MPPE-Encryption-Types RADIUS attributes, clear all other check boxes except the Strongest check box. This forces all wireless connections to use 128-bit encryption. If they are not, clear all the check boxes except No encryption.
Profile, Advanced tab (if the wireless AP supports VLANs):
- Add the Tunnel-Type attribute with the value of “Virtual LANs (VLAN)”.
- Add the Tunnel-Pvt-Group-ID attribute with the value of the VLAN ID of the VLAN that is connected to the Internet.
If the wireless APs require vendor specific attributes (VSAs), you must add the VSAs to the appropriate remote access policies. For more information, see the "Configure vendor-specific attributes for a remote access policy" procedure previously described.

Using a Third-Party CA

You can use third-party CAs to issue certificates for wireless access as long as the certificates installed can be validated and have the appropriate properties.

Certificates on IAS Servers

For the computer certificates installed on the IAS servers, the following must be true:

They must be installed in the Local Computer certificate store.
They must have a corresponding private key. When you view the properties of the certificate with the Certificate snap-in, you should see the text You have a private key that corresponds to this certificate on the General tab.
The cryptographic service provider for the certificates supports SChannel. If not, the IAS server cannot use the certificate and it is not selectable from the properties of the Smart Card or Other Certificate EAP type from the Authentication tab on the properties of a profile for a remote access policy.
They must contain the Server Authentication certificate purpose (also known as an Enhanced Key Usage [EKU]). An EKU is identified using an object identifier (OID). The OID for Server Authentication is "1.3.6.1.5.5.7.3.1".
They must contain the fully qualified domain name (FQDN) of the computer account of the IAS server computer in the Subject Alternative Name property.

Additionally, the root CA certificates of the CAs that issued the wireless client computer and user certificates must be installed in the Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates folder.

Certificates on Wireless Client Computers

For the user and computer certificates installed on wireless client computers, the following must be true:

They must have a corresponding private key.
They must contain the Client Authentication EKU (OID "1.3.6.1.5.5.7.3.2")
Computer certificates must be installed in the Local Computer certificate store.
Computer certificates must contain the FQDN of the wireless client computer account in the Subject Alternative Name property.
User certificates must be installed in the Current User certificate store.
User certificates must contain the universal principal name (UPN) of the user account in the Subject Alternative Name property.

Additionally, the root CA certificates of the CAs that issued the IAS server computer certificates must be installed in the Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates or Certificates (Current User)\Trusted Root Certification Authorities\Certificates folder.

Configuring Proxy Server Settings

Certificates issued from third-party CAs, such as VeriSign, Inc., can contain a certificate revocation list (CRL) uniform resource locator (URL) that points to an Internet Web site. If the IAS server cannot reach the Internet Web site to perform certificate revocation checking, it cannot validate the certificates of wireless clients for EAP-TLS authentication.

Many organization networks use a proxy server, such as Microsoft Internet Security and Acceleration Server (ISA), to access Internet services. Configuration of proxy server settings is normally done through Dynamic Host Configuration Protocol (DHCP) options. However, many IAS servers have a static IP address configuration and therefore might not be properly configured with the appropriate proxy server settings to access the Internet. The result is that IAS servers cannot perform certificate revocation checking for its own local computer certificate or wireless client certificates and authentication can fail for all wireless connections.

To configure an IAS server with the appropriate proxy server settings so that it can access Internet services, do the following:

On the IAS server, login using an account that has local administrator permissions.
Open a command prompt.
At the command prompt, type time and press ENTER.
At the Enter the new time: prompt, press ENTER.
At the command prompt, type at [time+1 minute]/interactive "cmd.exe" and press ENTER. For example, if the current time from step 4 is 13:31, the command is at 13:32/interactive "cmd.exe".
After a minute, a new command prompt opens. Commands run from this command prompt execute in the local system security context. IAS also runs in the local system security context. Therefore, you must configure proxy server settings from the local system security context so that they apply to IAS. Otherwise, the proxy server settings only apply to the user account that was used to login to the IAS server in step 1.
From inside the new command prompt, type “%programfiles%\Internet Explorer\Iexplore.exe” (including the quotes) and press ENTER. This opens Internet Explorer in the local system security context.
Click Tools, and then click Internet Options.
Click the Connections tab, and then click LAN Settings.
In Proxy server, select Use a proxy server for your LAN.
Type the name or IP address of your proxy server in Address, and then type the Web port number (typically 80) in Port. For example, if the name of your proxy server is CorpProxy and you use port 80 for your Web traffic, you would type corpproxy in Address and 80 in Port.
Click OK to save the proxy server settings.
Click OK to close the Internet Options dialog box.
Close Internet Explorer.
Close the new command prompt that was opened in step 6.

Another way to configure proxy server settings is to use the ProxyCfg.exe tool from the command prompt opened in step 6. ProxyCfg.exe is included with Windows Server 2003. For a version of ProxyCfg.exe that works with Windows 2000 Server, see 830605 - The Proxycfg.exe configuration tool is available for WinHTTP 5.1. For more information about how to use ProxyCfg.exe, see ProxyCfg.exe, a Proxy Configuration Tool.

Cross-Forest Authentication

Because IAS uses Active Directory to validate credentials and obtain user and computer account properties, a RADIUS proxy must be placed between the wireless APs and the IAS server computers when the user and computer accounts for wireless client computers and users exist in the following authentication databases:

Two different Active Directory forests.
Two different domains that do not trust each other.
Two different domains that have a one-way trust.

The following discussion assumes a cross-forest configuration.

When an access client sends user credentials, a user name is often included. Within the user name are two elements:

Identification of the user account name
Identification of the user account location

For example, for the user name user1@microsoft.com, user1 is the user account name and microsoft.com is the location of the user account. The identification of the location of the user account is known as a realm. There are different forms of realm names:

The realm name can be a prefix.

For microsoft\user1, "microsoft" is the name of a Windows NT® 4.0 domain.
The realm name can be a suffix.

For user1@microsoft.com, "microsoft.com" is either a DNS domain name or the name of an Active Directory-based domain.

Note You do not need to use a RADIUS proxy if you are using PEAP-MS-CHAP v2 and Windows NT 4.0-style user names (for example, microsoft\user1).

The user name is passed from the wireless client to the wireless AP during the authentication phase of the connection attempt. This user name becomes the User-Name RADIUS attribute in the Access-Request message that is sent by the wireless AP to its configured RADIUS server, which in this configuration is a RADIUS proxy. When the RADIUS proxy receives the Access-Request message, configured rules or policies on the RADIUS proxy determine the IAS server to which the Access-Request message is forwarded. Figure 2 shows IAS RADIUS proxies being used to forward RADIUS messages between wireless APs and multiple IAS servers in two different Active Directory forests.

Figure 2: Using IAS RADIUS proxies for cross-forest authentication

Figure 2: Using IAS RADIUS proxies for cross-forest authentication

The following configuration is for an organization that uses:

Active Directory domains.

Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate authorization.
At least two IAS servers in each forest.

At least two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication, authorization, and accounting in each forest. If only one RADIUS server is configured and it becomes unavailable, access clients for that forest cannot connect. By using at two IAS servers and configuring the IAS RADIUS proxies for both primary and secondary IAS servers, the IAS RADIUS proxies can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.
Remote access policies.

Remote access policies are configured to specify, based on group membership, the different types of connection constraints for users.
At least two IAS RADIUS proxies.

At least two IAS RADIUS proxies are used to provide fault tolerance for RADIUS requests that are sent from the wireless APs.

To configure IAS for this example, complete the following steps:

Configure the Active Directory forests for accounts and groups.
Configure the primary IAS server on a computer in the first forest.
Configure the secondary IAS server on another computer in the first forest.
Configure the primary IAS server on a computer in the second forest.
Configure the secondary IAS server on another computer in the second forest.
Configure the primary IAS RADIUS proxy.
Configure the secondary IAS RADIUS proxy.
Configure RADIUS authentication and accounting on wireless APs.

IAS for Windows 2000 does not support RADIUS proxy. However, you can use IAS in Windows Server 2003 to act as a RADIUS proxy in this configuration. For more information, see the topic titled "Authentication across forests" in Windows Server 2003 Help and Support.

Configuring the Active Directory Forests for Accounts and Groups

To configure Active Directory for user accounts and groups, do the following:

On each Windows 2000 domain controller computer, install Windows 2000 SP4.
Ensure that all users who are making wireless connections have a corresponding user account. Ensure that all computers who are making wireless connections have a corresponding computer account.
Set the remote access permission on user and computer accounts to the appropriate setting.
Organize your accounts into the appropriate groups in order to take advantage of group-based remote access policies.

Configuring the primary IAS server on a computer in the first forest

To configure the primary IAS server on a computer in the first forest, do the following:

If you are using Windows 2000 Server IAS, install IAS as an optional networking component on a computer in the first forest, and then install Windows 2000 SP4. If you are using Windows Server 2003 IAS, install IAS as an optional networking component on a computer in the first forest.
Configure the IAS server computer to read the properties of user accounts in the domain.
If the IAS server is authenticating connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains.
If needed, enable logging for accounting and authentication events.
Add the IAS RADIUS proxies as RADIUS clients of the IAS server. Verify that you are configuring the correct name or IP address and shared secrets.
Create the appropriate remote access policy for wireless clients in the first forest.

Configuring the secondary IAS server on another computer in the first forest

To configure the secondary IAS server on another computer in the first forest, do the following:

If you are using Windows 2000 Server IAS, install IAS as an optional networking component on another computer in the first forest, and then install Windows 2000 SP4. If you are using Windows Server 2003 IAS, install IAS as an optional networking component on another computer in the first forest.
Configure the secondary IAS server computer to read the properties of user accounts in the domain.
If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains.
Copy the configuration of the primary IAS server to the secondary IAS server.

Configuring the primary IAS server on a computer in the second forest

To configure the primary IAS server on a computer in the second forest, do the following:

If you are using Windows 2000 Server IAS, install IAS as an optional networking component on a computer in the second forest, and then install Windows 2000 SP4. If you are using Windows Server 2003 IAS, install IAS as an optional networking component on a computer in the second forest.
Configure the primary IAS server computer to read the properties of user accounts in the appropriate domain containers.
If the IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains.
If needed, enable logging for accounting and authentication events.
Add the IAS RADIUS proxies as RADIUS clients of the IAS server. Verify that you are configuring the correct name or IP address and shared secrets.
Create the appropriate remote access policy for wireless clients in the second forest.

Configuring the secondary IAS server on another computer in the second forest

To configure the secondary IAS server on another computer in the second forest, do the following:

If you are using Windows 2000 Server IAS, install IAS as an optional networking component on another computer in the second forest, and then install Windows 2000 SP4. If you are using Windows Server 2003 IAS, install IAS as an optional networking component on another computer in the second forest.
Configure the secondary IAS server computer to read the properties of user accounts in the appropriate domain containers.
If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains.
Copy the configuration of the primary IAS server in the second forest to the secondary IAS server.

Configuring the primary IAS RADIUS proxy

To configure the primary IAS RADIUS proxy, do the following:

On a computer running Windows Server 2003, install IAS as an optional networking component. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. For example, you can install IAS on a file server.
If needed, configure additional UDP ports for RADIUS messages that are sent by the wireless APs. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
Add the wireless APs as RADIUS clients of the IAS RADIUS proxy. Verify that you are configuring the correct name or IP address and shared secrets.
Create a connection request policy that forwards RADIUS request messages (that are based on the realm name of accounts in the first forest) to the IAS servers in the first forest. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server group and where the realm name matches the realm name of the user accounts in the first forest. Clear the check box that removes the realm name for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS servers in the first forest.
Create a connection request policy that forwards RADIUS request messages (that are based on the realm name of accounts in the second forest) to the IAS servers in the second forest. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server group and where the realm name matches the realm name of the user accounts in the second forest. Clear the check box that removes the realm name for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS servers in the second forest.
Delete the default connection request policy named Use Windows authentication for all users.

Configuring the secondary IAS RADIUS proxy

To configure the secondary IAS RADIUS proxy on another computer, do the following:

On another computer running Windows Server 2003, install IAS as an optional networking component.
Copy the configuration of the primary IAS RADIUS proxy to the secondary IAS RADIUS proxy.

Configuring RADIUS authentication and accounting on the wireless APs

Configure RADIUS settings on your third-party wireless APs with the following:

The IP address or name of a primary RADIUS server, the common shared secret, UDP ports for authentication and accounting, and failure detection settings.
The IP address or name of a secondary RADIUS server, the common shared secret, UDP ports for authentication and accounting, and failure detection settings.

To balance the load of RADIUS traffic between the two IAS RADIUS proxies, configure half of the wireless APs or switches with the primary IAS RADIUS proxy as the primary RADIUS server and the secondary IAS RADIUS proxy as the secondary RADIUS server and the other half of the wireless APs with the secondary IAS RADIUS proxy as the primary RADIUS server and the primary IAS RADIUS proxy as the secondary RADIUS server.

For more information, see the documentation provided by the wireless AP or switch manufacturer.

Using RADIUS Proxies to Scale Authentications

When performing authentication for a large number of wireless clients using EAP-TLS and certificates, the volume of authentication traffic needed to keep wireless clients connected can be substantial. In a large deployment, it would be best to attempt to spread the load of authentication traffic among multiple IAS server computers. Because you cannot rely on the wireless APs to consistently or adequately spread their authentication traffic among multiple IAS servers, intermediate IAS RADIUS proxies can provide this service.

Without RADIUS proxies, each wireless AP sends its RADIUS requests to one or multiple RADIUS servers and detects unavailable RADIUS servers. The wireless AP might or might not be balancing the load of RADIUS traffic across multiple RADIUS servers. By using IAS RADIUS proxies, consistent load balancing is used to spread the load of authentication, authorization, and accounting traffic across all the IAS servers in the organization. Additionally, there is a consistent scheme for failure detection and RADIUS server fail over and fail back.

The following configuration is for an organization that uses:

Active Directory domains.

Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate authorization.
Multiple IAS servers.

To balance the load of RADIUS authentication, authorization, and accounting traffic, there are multiple IAS servers.
Remote access policies.

Remote access policies are configured to specify, based on group membership, the different types of connection constraints for users.
Two IAS RADIUS proxies.

Two IAS RADIUS proxies are used to provide fault tolerance for RADIUS requests that are sent from the wireless APs.

Figure 3 shows the use of IAS RADIUS proxies to balance the load of RADIUS traffic from wireless APs across multiple IAS servers.

Figure 3: Using IAS RADIUS proxies for load balancing of authentication traffic

Figure 3: Using IAS RADIUS proxies for load balancing of authentication traffic

To configure IAS for this example, complete the following steps:

Configure the Active Directory forests for user accounts and groups.
Configure IAS as a RADIUS server on multiple computers.
Configure the primary IAS RADIUS proxy.
Configure the secondary IAS RADIUS proxy.
Configure RADIUS authentication and accounting on wireless APs.

IAS for Windows 2000 does not support RADIUS proxy. However, you can use IAS in Windows Server 2003 to act as a RADIUS proxy in this configuration. For more information, see the topic titled “Using IAS proxy for load balancing” in Windows Server 2003 Help and Support.

Configuring Active Directory for user accounts and groups

To configure Active Directory for user accounts and groups, do the following:

On each Windows 2000 domain controller computer, install Windows 2000 SP4.
Ensure that all users who are making wireless connections have a corresponding user account. Ensure that all computers who are making wireless connections have a corresponding computer account.
Set the remote access permission on user and computer accounts to the appropriate setting.
Organize your accounts into the appropriate groups in order to take advantage of group-based remote access policies.

Configuring IAS as a RADIUS server on multiple computers

To configure IAS as a RADIUS server on each computer, do the following:

If you are using Windows 2000 Server IAS, install IAS as an optional networking component, and then install Windows 2000 SP4. If you are using Windows Server 2003 IAS, install IAS as an optional networking component.
Configure each IAS server computer to read the properties of user accounts in the appropriate domain containers.
If needed, enable logging for accounting and authentication events.
Add the IAS RADIUS proxies as RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets.
Create the appropriate remote access policy for wireless network access.

Configuring the primary IAS RADIUS proxy

To configure the primary IAS RADIUS proxy, do the following:

On a computer running Windows Server 2003, install IAS as an optional networking component. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. For example, you can install IAS on a file server.
If needed, configure additional UDP ports for RADIUS messages that are sent by the wireless APs. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
Add the wireless APs as RADIUS clients of the IAS server. Verify that you are configuring the correct name or IP address and shared secrets.
Use the New Remote RADIUS Server Group Wizard to create a custom remote RADIUS server group. Add each IAS RADIUS server as a member of the remote RADIUS server group and configure each group member with the priority of 1 and a weight of 50 (the default settings).
Create a connection request policy that forwards RADIUS request messages to the IAS servers where the realm name matches the accounts in the domain. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server and where the realm name matches the realm name for the user accounts in the forest. Clear the check box that removes the realm name for authentication. Select the previously created remote RADIUS server group as the group to forward connection requests.
Delete the default connection request policy named Use Windows authentication for all users.

Configuring the secondary IAS RADIUS proxy

To configure the secondary IAS RADIUS proxy on another computer, do the following:

On another computer running Windows Server 2003, install IAS as an optional networking component.
Copy the configuration of the primary IAS RADIUS proxy to the secondary IAS RADIUS proxy.

Configuring RADIUS authentication and accounting on the wireless APs

Configure RADIUS settings on your third-party wireless APs with the following:

The IP address or name of the primary RADIUS server, the common shared secret, UDP ports for authentication and accounting, and failure detection settings.
The IP address or name of the secondary RADIUS server, the common shared secret, UDP ports for authentication and accounting, and failure detection settings.

For more information, see the documentation provided by the wireless AP or switch manufacturer.

Appendix A: Using Computer-only Authentication

Some network administrators want to use only computer authentication. By using only computer authentication, a wireless client computer must perform computer-level 802.1X authentication with a wireless AP using either a computer certificate (when using EAP-TLS authentication) or the computer's account name and password (when using PEAP-MS-CHAP v2 authentication) before it can access the organization network. With computer-only authentication, only valid computers can connect to the wireless network. Computers that do not have a computer account in the organization's domain cannot connect. This prevents users from bringing computers from home and connecting to the organization's wireless LAN. Home computers represent a threat to the organization network because they are not managed in the same way as member computers and can introduce viruses or other malicious programs into the organization network.

For more information about computer authentication and user authentication, see Wireless Deployment Technology and Component Overview.

You can configure computer-only authentication using the Wireless Network (IEEE 802.11) Policies Group Policy extension or through the registry.

Configuring Computer-only Authentication using the Windows Server 2003 Wireless Network (IEEE 802.11) Policies Group Policy Extension

To configure computer-only authentication using the Wireless Network (IEEE 802.11) Policies Group Policy extension, select Computer only in Computer authentication on the 802.1x tab for the preferred network the corresponds to your wireless network. Figure 4 shows an example.

Figure 4: Selecting computer-only authentication in the Windows Server 2003 Wireless Network (IEEE 802.11) Policies Group Policy extension

Figure 4: Selecting computer-only authentication in the Windows Server 2003 Wireless Network (IEEE 802.11) Policies Group Policy extension

For more information, see Configuring Wireless Settings Using Windows Server 2003 Group Policy.

Enabling Computer-only Authentication Using the Registry

To configure computer-only authentication through the registry, all the Windows wireless clients must have the following registry value set:

HKEY_LOCAL_MACHINE\Software\Microsoft\EAPOL\Parameters\General\Global\AuthMode=2

With the AuthMode setting set to 2, only computer authentication is attempted. User authentication is never attempted.

To add this registry setting on all of your computers running Windows, you can use the following tools:

Regini.exe from the Windows 2000 Server Resource Kit Tools
Reg.exe from the Windows Server 2003 Resource Kit Tools

In both cases, you create a script file that is read by the tool to add a registry setting. The tool has to be run in the security context of a local administrator account.

Alternately, you can use network management software to change registry settings on managed computers.

Summary

You can perform protected wireless authentication with EAP-TLS, PEAP-TLS, or PEAP-MS-CHAP v2. For EAP-TLS or PEAP-TLS, you must deploy a certificate infrastructure capable of issuing computer certificates to your IAS servers and both computer and user certificates to your wireless client computers and users. For PEAP-MS-CHAP v2, you only need to install computer certificates on the IAS servers, provided that the appropriate root CA certificates are already installed on the wireless clients. For both cases, you must manage your Active Directory users and groups for wireless access, configure your IAS servers as RADIUS servers to the wireless APs, and configure your wireless APs as RADIUS clients to the IAS servers. You can also configure Internet access for business partners, use third-party CAs, and use IAS RADIUS proxies for cross-forest authentication or load balancing.

See the following resources for further information:

Share via

Deployment of Protected 802.11 Networks Using Microsoft Windows

On This Page

Introduction

Intranet Wireless Deployment Steps

Step 1: Configuring the Certificate Infrastructure

Step 1a: Installing a Certificate Infrastructure

Step 1b: Installing Computer Certificates

Step 1c: Installing User Certificates

Step 2: Configuring Active Directory for Accounts and Groups

Step 3: Configuring the Primary IAS Server

Step 3a: Configuring IAS

Step 3b: Configuring a Wireless Remote Access Policy

Step 4: Configuring the secondary IAS server

Step 5: Deploying and Configuring Wireless APs

Step 6: Configuring Wireless Network (IEEE 802.11) Policies Group Policy Settings

Wireless Group Policy and WPA

Wireless Group Policy and Windows 2000 Domains

Wireless Group Policy and WPA2 Settings

Enhanced Wireless Group Policy Settings for Windows Vista

Step 7: Configuring Wireless Clients for EAP-TLS or PEAP-TLS

Step 7a: Installing Computer Certificates on Wireless Clients

Step 7b: Install User Certificates on Wireless Clients

Disk-Based Installation

Step 7c: Configuring Wireless Clients for EAP-TLS or PEAP-TLS

Step 8: Configuring Wireless Clients for PEAP-MS-CHAP v2

Additional Intranet Wireless Deployment Configurations

Internet Access for Business Partners

Using Guest Access

Using Validated Access

Using a Third-Party CA

Certificates on IAS Servers

Certificates on Wireless Client Computers

Configuring Proxy Server Settings

Cross-Forest Authentication

Configuring the Active Directory Forests for Accounts and Groups

Configuring the primary IAS server on a computer in the first forest

Configuring the secondary IAS server on another computer in the first forest

Configuring the primary IAS server on a computer in the second forest

Configuring the secondary IAS server on another computer in the second forest

Configuring the primary IAS RADIUS proxy

Configuring the secondary IAS RADIUS proxy

Configuring RADIUS authentication and accounting on the wireless APs

Using RADIUS Proxies to Scale Authentications

Configuring Active Directory for user accounts and groups

Configuring IAS as a RADIUS server on multiple computers

Configuring the primary IAS RADIUS proxy

Configuring the secondary IAS RADIUS proxy

Configuring RADIUS authentication and accounting on the wireless APs

Appendix A: Using Computer-only Authentication

Configuring Computer-only Authentication using the Windows Server 2003 Wireless Network (IEEE 802.11) Policies Group Policy Extension

Enabling Computer-only Authentication Using the Registry

Summary

Related Links

Additional resources