Microsoft KB Archive/822057

= How to Migrate to the Protected Extensible Authentication Protocol (PEAP) =

Article ID: 822057

Article Last Modified on 9/27/2007

-

APPLIES TO


 * Microsoft Windows Server 2003, Enterprise Edition
 * Microsoft Windows Server 2003, Standard Edition (32-bit x86)

-





SUMMARY
This article contains an overview of Protected Extensible Authentication Protocol (PEAP), also known as EAP-MSCHAPv2. This article also describes how to migrate from Lightweight Extended Authentication Protocol (LEAP) to PEAP in your wireless environment.

Note LEAP is also known as EAP-Cisco.



MORE INFORMATION
PEAP creates an encrypted Secure Sockets Layer/Transport Layer Security (SSL/TLS) tunnel between the client and the authentication server that helps to protect user authentication. PEAP is also defined as an extensible authentication method that can embrace new EAP authentication schemes as they become available. Microsoft Windows PEAP supports passwords and certificate authentication, and it also allows any EAP-based method that is provided by Microsoft software partners to be used in PEAP.

PEAP helps increase your protection against the deployment of unauthorized access points, because the client verifies the identity of the authentication server before it completes authentication or continues connectivity. The access point cannot decrypt the authentication messages that are encrypted by PEAP.

Remote Authentication Dial-In User Service (RADIUS) is a frequently used protocol that provides centralized authentication, authorization, and accounting for dial-up, virtual private network (VPN), and wireless network access. Internet Authentication Service (IAS) is the Microsoft RADIUS server product. Microsoft Windows 2000 Server and Windows Server 2003 support PEAP with password authentication (EAP-MSCHAPv2).

A Windows Server 2003 IAS RADIUS proxy server can detect the difference between clients that use LEAP and those that use PEAP; it then forwards the authentication to a LEAP-compatible RADIUS server (for this example, a Cisco Access Control Server [ACS]) and an IAS server, respectively. The RADIUS proxy does not have to reside on a separate computer from the IAS server.

Use the following guidelines to configure the wireless client and the access point so that the RADIUS proxy can detect the difference between the LEAP and the PEAP protocols:  Deploy separate wireless Access Points (APs) for each protocol. Use one AP for LEAP and another AP for PEAP. Configure the IAS server to forward the authentication to the Cisco ACS, based on the contents of the NAS-IP-Address or the NAS-Identifier. For example, IAS may have two Connection Request policies:  The first Connection Request policy corresponds to the LEAP AP and is based on the NAS-IP-ADDRESS condition (the IP address of the LEAP AP) or on the NAS-Identifier condition. Configure this policy to forward the requests to a remote radius group. You must create a remote radius group and, for this example, name the group “LEAP Servers.” Add the ACS servers to the LEAP Servers radius group. On the ACS servers, add the IAS server as a radius client with the same shared secret defined while you create the group. The second Connection Request policy corresponds to the PEAP AP and is also based on the IP-ADDRESS condition (the IP address of the PEAP AP) or on the NAS-Identifier condition. In this policy, activate the Authenticate the requests on this server option. On the Remote Access policy, activate the PEAP protocol, and then define the conditions for your environment.  Deploy access points with more than one Service Set Identifier (SSID). Specify LEAP on one SSID and PEAP on the other SSID. Configure the IAS server to forward the authentication to the Cisco ACS, based on the contents of the Called-Station-ID. The Called-Station-ID will contain the SSID, as in the following example:  The first Connection Request policy corresponds to the LEAP AP and is based on the station ID. Configure this policy to forward the requests to a remote radius group. You must create a remote radius group and, for this example, name the group “LEAP Servers.” Add the ACS servers to the LEAP Servers radius group. On the ACS servers, add the IAS server as a radius client with the same shared secret defined while you create the group. The second Connection Request policy corresponds to the PEAP AP and is based also on the called station ID. In this policy, activate the Authenticate the requests on this server option. On the Remote Access policy, activate the PEAP protocol, and then define the conditions for your environment.</li></ol> </li> Users who use LEAP will enter a user name that specifies a special realm. The realm makes it possible to distinguish between clients that use LEAP and clients that use PEAP. Forward the authentication, based on the contents of user name. The user name will contain the realm. Configure the IAS server to remove the realm before it forwards the authentication to the Cisco ACS server. For example, you must have two Connection Request policies:  The Connection Request policy that corresponds to the LEAP Users is based on the user-name condition. Use a definition that is similar to leap* to define the Connection Request Policy. This definition will match any user name that contains “leap” as a prefix. On the Attribute tab of this policy, add a rule to replace “leap” with “” (empty string). The empty string value causes the policy to forward the correct user name to the ACS. Configure this policy to forward the requests to the ACS servers.</li> The second Connection Request policy is same as in step a.

Note Any condition can be used in the second policy; however, this policy must be listed after the LEAP policy.</li></ol> </li> Require that only computer authentication be used for PEAP clients. Configure the IAS server to forward the authentication to the Cisco ACS, based on the contents of user name. The computer name will always end with a $ character. The clients must be configured to force only computer authentication. You must configure the PEAP clients to use computer authentication instead of client authentication. In this example, the Connection Request policy is as follows:  The first policy must correspond to PEAP and be based on the user-name condition (for example: *$). Configure this policy to authenticate locally.</li> The second Connection Request policy can have any criteria, but it must be configured to forward to the ACS.</li></ol> </li></ul>

The third-party products that are discussed in this article are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.

<div class="references_section">