The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to configure the PEAP with MS-CHAP authentication with the Microsoft NPS as the RADIUS server.
Cisco recommends that you have knowledge of these topics:
Ensure that these requirements have been met before you attempt this configuration:
For initial installation and configuration information for the Cisco 5508 Series Wireless Controllers, refer to the Cisco 5500 Series Wireless Controller Installation Guide.
Note: This document is intended to give the readers an example on the configuration required on a Microsoft server for PEAP-MS-CHAP authentication. The Microsoft Windows server configuration presented in this document has been tested in the lab and found to work as expected. If you have trouble with the configuration, contact Microsoft for help. The Cisco Technical Assistance Center (TAC) does not support Microsoft Windows server configuration.
Microsoft Windows 2008 installation and configuration guides can be found on Microsoft Tech Net.
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
This document provides a sample configuration for the Protected Extensible Authentication Protocol (PEAP) with Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 2 authentication in a Cisco Unified Wireless network with the Microsoft Network Policy Server (NPS) as the RADIUS server.
PEAP uses Transport Level Security (TLS) to create an encrypted channel between an authenticated PEAP client, such as a wireless laptop, and a PEAP authenticator, such as Microsoft NPS or any RADIUS server. PEAP does not specify an authentication method, but provides additional security for other Extensible Authentication Protocols (EAPs), such as EAP-MS-CHAP v2, that can operate through the TLS-encrypted channel provided by PEAP. The PEAP authentication process consists of two main phases.
The wireless client associates with the AP. An IEEE 802.11-based association provides an open system or shared key authentication before a secure association is created between the client and the access point. After the IEEE 802.11-based association is successfully established between the client and the access point, the TLS session is negotiated with the AP. After authentication is successfully completed between the wireless client and NPS, the TLS session is negotiated between the client and NPS. The key that is derived within this negotiation is used to encrypt all subsequent communication.
EAP communication, which includes EAP negotiation, occurs inside the TLS channel created by PEAP within the first stage of the PEAP authentication process. The NPS authenticates the wireless client with EAP-MS-CHAP v2. The LAP and the controller only forward messages between the wireless client and RADIUS server. The Wireless LAN Controller (WLC) and the LAP cannot decrypt these messages because it is not the TLS end point.
The RADIUS message sequence for a successful authentication attempt (where the user has supplied valid password-based credentials with PEAP-MS-CHAP v2) is:
In this section, you are presented with the information to configure PEAP-MS-CHAP v2.
Note: Use the Command Lookup Tool to obtain more information on the commands used in this section. Only registered Cisco users can access internal Cisco tools and information.
This configuration uses this network setup:
Network Diagram
In this setup, a Microsoft Windows 2008 server performs these roles:
The server connects to the wired network through a Layer 2 switch as shown. The WLC and the registered LAP also connect to the network through the Layer 2 switch.
The wireless clients use Wi-Fi Protected Access 2 (WPA2) - PEAP-MS-CHAP v2 authentication to connect to the wireless network.
The objective of this example is to configure the Microsoft 2008 server, Wireless LAN Controller, and Light Weight AP to authenticate the wireless clients with PEAP-MS-CHAP v2 authentication. There are three major steps in this process:
In this example, a complete configuration of the Microsoft Windows 2008 server includes these steps:
Complete these steps in order to configure the Microsoft Windows 2008 server as a domain controller:






The installation proceeds and completes.












The installation proceeds.


The DHCP service on the Microsoft 2008 server is used to provide IP addresses to the wireless clients. Complete these steps in order to install and configure DHCP services:













The installation proceeds.

The DHCP Server is now installed.













PEAP with EAP-MS-CHAP v2 validates the RADIUS server based on the certificate present on the server. Additionally, the server certificate must be issued by a public CA that is trusted by the client computer (that is, the public CA certificate already exists in the Trusted Root Certification Authority folder on the client computer certificate store).
Complete these steps in order to configure the Microsoft Windows 2008 server as a CA server that issues the certificate to the NPS:














Complete these steps in order to connect the clients to the wired network and to download the domain specific information from the new domain:








In this setup, the NPS is used as a RADIUS server to authenticate wireless clients with PEAP authentication. Complete these steps in order to install and configure NPS on the Microsoft WIndows 2008 server:








Complete these steps in order to install the computer certificate for the NPS:










Complete these steps in order to configure the NPS for authentication:

















In this example, the user database is maintained on the Active Directory. Complete these steps in order to add users to the Active Directory database:



Configure the wireless devices (the Wireless LAN Controllers and LAPs) for this setup.
Configure the WLC to use the NPS as the authentication server. The WLC must be configured in order to forward the user credentials to an external RADIUS server. The external RADIUS server then validates the user credentials and provides access to the wireless clients.
Complete these steps in order to add the NPS as a RADIUS server in the Security > RADIUS Authentication page:


Configure the service set identifier (SSID) (WLAN) to which the wireless clients connects. In this example, create the SSID, and name it PEAP.
Define the Layer 2 Authentication as WPA2 so that the clients perform EAP-based authentication (PEAP-MS-CHAP v2 in this example) and use the advanced encryption standard (AES) as the encryption mechanism. Leave all other values at their defaults.
Note: This document binds the WLAN with the management interfaces. When you have multiple VLANs in your network, you can create a separate VLAN and bind it to the SSID. For information on how to configure VLANs on WLCs, refer to VLANs on Wireless LAN Controllers Configuration Example.
Complete these steps in order to configure a WLAN on the WLC:




Complete these steps to configure the wireless client with the Windows Zero Config Tool to connect to the PEAP WLAN.


There is currently no verification procedure available for this configuration.
If your client did not connect to the WLAN, this section provides information you can use to troubleshoot the configuration.
There are two tools that can be used to diagnose 802.1x authentication failures: the debug client command and the Event Viewer in Windows.
If you perform a client debug from the WLC it is not resource intensive and does not impact service. To start a debug session, open the command-line interface (CLI) of the WLC, and enter debug client mac address, where the mac address is the wireless mac address of the wireless client that is unable to connect. While this debug runs, try to connect the client; there must be output on the CLI of the WLC that looks similar to this example:

This is an example of an issue that could occur with a misconfiguration. Here, the WLC debug shows the WLC has moved into the authentication state, which means the WLC waits for a response from the NPS. This is usually due to an incorrect shared secret on either the WLC or the NPS. You can confirm this via the Windows Server Event Viewer. If you do not find a log, the request never made it to the NPS.
Another example that is found from the WLC debug is an access-reject. An access-reject shows that the NPS received and rejected the client credentials. This is an example of a client that receives an access-reject:
When you see an access-reject, check the logs on the Windows Server Event logs to determine why the NPS responded to the client with an access-reject.
A successful authentication has an access-accept in the client debug, as seen in this example:
If you want to troubleshoot access-rejects and response timeouts it requires access to the RADIUS server. The WLC acts as an authenticator that passes EAP messages between the client and the RADIUS server. A RADIUS server that responds with an access-reject or response timeout must be examined and diagnosed by the manufacturer of the RADIUS service.
Note: TAC does not provide technical support for third-party RADIUS servers; however, the logs on the RADIUS server generally explain why a client request was rejected or ignored.
In order to troubleshoot access-rejects and response timeouts from the NPS, examine the NPS logs in the Windows Event Viewer on the server.

In this section of the Event View, there are logs of passed and failed authentications. Examine these logs to troubleshoot why a client is not passing authentication. Both passed and failed authentications show up as Informational. Scroll through the logs to find the username that has failed authentication and received an access-reject based on the WLC debugs.
This is an example of the NPS when it denies a user access:
When you review a deny statement in the Event Viewer, examine the Authentication Details section. In this example, you can see that the NPS denied the user access due to an incorrect username:
The Event View on the NPS also assists when you need to troubleshoot if the WLC does not receive a response back from the NPS. This is usually caused by an incorrect shared secret between the NPS and the WLC.
In this example, the NPS discards the request from the WLC due to an incorrect shared secret:

| Revision | Publish Date | Comments |
|---|---|---|
4.0 |
04-Dec-2025
|
Reformatted. Recertification. |
3.0 |
14-Mar-2023
|
Updated. Corrected. Recertification. |
1.0 |
24-Feb-2013
|
Initial Release |
Feedback