PEAP — Protected EAP — protects the authentication credential exchange inside a TLS tunnel. The client validates ISE's server certificate to establish the tunnel, then runs an inner EAP method (MSCHAPv2 in most enterprise deployments) inside it. The client never sends its password in cleartext, and the server certificate validation protects against RADIUS impersonation attacks.
PEAP is the right choice when your environment has an Active Directory domain with domain accounts but you are not ready to deploy a PKI for per-device client certificates. If you need mutual certificate-based authentication, see [Article 11: Configuring EAP-TLS with Certificates on Cisco ISE and IOS XE]. This article assumes the switch-to-ISE RADIUS plumbing from [Article 8: Basic 802.1X Port Configuration on Cisco IOS XE Switches] and [Article 9: Configuring Cisco ISE as a RADIUS Server for 802.1X] is complete and working.
PEAP Architecture: What the Switch Sees vs. What ISE Does
The Catalyst 9300 is a transparent relay for PEAP. It forwards EAP frames without parsing them. From the switch's perspective, PEAP looks identical to EAP-TLS — a series of RADIUS Access-Challenge / Access-Request exchanges until a final Access-Accept or Access-Reject arrives.
The PEAP negotiation happens entirely between the supplicant (Windows endpoint) and ISE:
- ISE proposes PEAP in the first EAP-Request
- Supplicant accepts PEAP (or sends a Nak proposing PEAP if ISE proposed something else)
- ISE and supplicant complete a TLS handshake — ISE presents its server certificate, supplicant validates it
- Inside the TLS tunnel, ISE runs EAP-MSCHAPv2: it sends a random challenge, the supplicant responds with an NT hash of the password combined with the challenge
- ISE forwards the MSCHAPv2 credentials to Active Directory for validation
- AD validates the credentials and ISE completes the EAP-MSCHAPv2 exchange
- ISE sends RADIUS Access-Accept with authorization attributes
The TLS outer tunnel uses the server certificate configured on the ISE policy service node. This certificate must be trusted by the supplicant — either issued by a CA in the Windows machine's Trusted Root CA store, or imported manually.
Step 1: ISE Server Certificate Configuration
ISE requires a server certificate bound to the RADIUS/EAP role to perform the PEAP TLS handshake. Using the default self-signed certificate works for lab testing but causes supplicant validation failures in production unless every endpoint has manually imported the ISE self-signed CA.
Using an Internal CA Certificate (Recommended)
Generate a CSR on ISE and have your internal CA sign it:
Navigation: Administration > Certificates > Certificate Signing Requests > Generate Certificate Signing Requests
Certificate(s) will be used for: EAP Authentication
CN (Common Name): ise-psn01.corp.local
SAN (Subject Alternative Name):
DNS: ise-psn01.corp.local
IP: 10.0.0.10
Key Type: RSA
Key Length: 2048
Digest: SHA-256
Submit the CSR to your internal CA. Import the signed certificate back into ISE:
Navigation: Administration > Certificates > System Certificates > Import
After import, bind the certificate to the EAP role:
Navigation: Administration > Certificates > System Certificates > [Select imported cert] > Edit
Usage: EAP Authentication — check this box
Click Save and confirm the restart of the Application Server if prompted. ISE will use this certificate for all PEAP TLS handshakes going forward.
The Windows supplicant validates this certificate against its Trusted Root CA store during the PEAP TLS handshake. If the issuing CA is your internal corporate CA and it is already distributed to all domain members via Group Policy, no additional configuration is required on the endpoints.
Step 2: Active Directory Integration
PEAP-MSCHAPv2 requires ISE to forward credentials to Active Directory. ISE must be joined to the AD domain.
Navigation: Administration > Identity Management > External Identity Sources > Active Directory > Add
Join Point Name: corp-ad
AD Domain: corp.local
Click Submit, then click Join and enter domain administrator credentials:
AD Username: administrator@corp.local
AD Password: [domain admin password]
ISE performs the domain join operation on each Policy Service Node (PSN) in the deployment. Verify the join status:
Navigation: Administration > Identity Management > External Identity Sources > Active Directory > corp-ad > Nodes tab
All PSNs should show Operational status. A PSN that shows Not Joined cannot authenticate PEAP-MSCHAPv2 users.
AD Groups Configuration
Configure which AD groups ISE retrieves for authorization policy use:
Navigation: Administration > Identity Management > External Identity Sources > Active Directory > corp-ad > Groups tab > Add > Select Groups from Directory
Add the groups you plan to use in Authorization Policy conditions:
corp.local/Groups/Domain Computers
corp.local/Groups/Domain Users
corp.local/Groups/IT-Staff
corp.local/Groups/Contractors
ISE will populate the AD:ExternalGroups attribute with the group memberships of the authenticating user or computer, which your Authorization Policy rules can then reference.
Step 3: ISE Allowed Protocols for PEAP
Confirm the Allowed Protocols service used by your Authentication Policy includes PEAP:
Navigation: Policy > Policy Elements > Results > Authentication > Allowed Protocols > [PEAP_EAP-TLS_Allowed]
Allow PEAP: Yes
Inner Methods:
EAP-MSCHAPv2: Yes
EAP-GTC: No
Require Client Certificate for PEAP: No
Require Client Certificate for PEAP: No — this is correct for standard PEAP-MSCHAPv2. The client presents credentials (username/password), not a certificate, inside the PEAP tunnel. If you set this to Yes, the inner method switches to EAP-TLS inside PEAP, which requires client certificates and is a different deployment model.
Step 4: ISE Authentication Policy
Navigation: Policy > Policy Sets > Default > Authentication Policy
The authentication rule for PEAP wired 802.1X:
Rule Name: Wired_Dot1X_PEAP
Priority: 1
Conditions:
- Wired_802.1X (condition: NAS-Port-Type EQUALS Ethernet, EAP Authentication)
Use (Allowed Protocols): PEAP_EAP-TLS_Allowed
Use (Identity Source): corp-ad
Options:
If user not found: Reject
If authentication failed: Reject
Setting If user not found: Reject instead of Continue is important for security — if a user is not in Active Directory, authentication should fail, not fall through to potentially match a more permissive authorization rule.
Step 5: ISE Authorization Policy for PEAP Users
Navigation: Policy > Policy Sets > Default > Authorization Policy
Rule Name: Corp_Computer_Domain_Joined
Priority: 1
Conditions:
- AD:ExternalGroups EQUALS corp.local/Groups/Domain Computers
- AND: Network_Access:EapAuthentication EQUALS PEAP
- AND: Network_Access:EapTunnel EQUALS MSCHAPv2
Authorization Profile: VLAN10_Corp_Data
Rule Name: IT_Staff_Full_Access
Priority: 2
Conditions:
- AD:ExternalGroups EQUALS corp.local/Groups/IT-Staff
- AND: Network_Access:EapAuthentication EQUALS PEAP
Authorization Profile: VLAN10_Corp_Data (with dACL for unrestricted access)
Rule Name: Contractor_Restricted
Priority: 3
Conditions:
- AD:ExternalGroups EQUALS corp.local/Groups/Contractors
- AND: Network_Access:EapAuthentication EQUALS PEAP
Authorization Profile: VLAN30_Guest
Rule Name: Default_Deny
Priority: Last
Conditions: (matches everything else)
Authorization Profile: DenyAccess
The condition Network_Access:EapAuthentication EQUALS PEAP combined with Network_Access:EapTunnel EQUALS MSCHAPv2 pins the rule to PEAP-MSCHAPv2 specifically. This prevents a scenario where a supplicant configured for EAP-TLS matches the same rule — EAP-TLS authentication should match a different rule with different authorization attributes.
Step 6: Switch Configuration — No PEAP-Specific Commands Required
The Catalyst 9300 requires no PEAP-specific configuration. The switch is a transparent forwarder. Confirm the base 802.1X port configuration from [Article 8: Basic 802.1X Port Configuration on Cisco IOS XE Switches] is complete on the target interface:
C9300# show run interface GigabitEthernet1/0/1
Building configuration...
interface GigabitEthernet1/0/1
description User Access Port - 802.1X
switchport mode access
switchport access vlan 10
switchport nonegotiate
spanning-tree portfast
spanning-tree bpduguard enable
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication event fail action authorize vlan 40
authentication event no-response action authorize vlan 30
authentication event server dead action authorize vlan 50
authentication event server alive action reinitialize
dot1x pae authenticator
dot1x timeout tx-period 10
dot1x max-reauth-req 3
mab
ip access-group ACL_PREAUTH in
The only change that impacts EAP method behavior is on ISE (Allowed Protocols) and on the supplicant (Windows NIC settings).
Step 7: Windows 10/11 Supplicant Configuration
Windows 10 and 11 include a built-in 802.1X supplicant (the Wired AutoConfig service). Configure it via NIC properties or Group Policy.
Via NIC Properties (Single Endpoint)
- Open Network Connections (ncpa.cpl)
- Right-click the wired adapter > Properties
- Authentication tab > Enable IEEE 802.1X authentication
- Choose a network authentication method: Microsoft: Protected EAP (PEAP)
- Click Settings next to PEAP
In the PEAP Settings dialog:
Verify the server's identity by validating the certificate: Checked
Connect to these servers: ise-psn01.corp.local
Trusted Root Certification Authorities: [Your internal CA]
Authentication Method (inner): Secured password (EAP-MSCHAP v2)
Automatically use my Windows logon name and password: Checked (for machine/user auth)
Verify the server's identity by validating the certificate — this must be checked in production. Without it, the supplicant accepts any RADIUS server's certificate, enabling man-in-the-middle attacks where a rogue RADIUS server can capture credentials.
Connect to these servers — enter the ISE PSN FQDN as it appears in the server certificate's Subject Alternative Name. If this field is left blank, Windows validates the certificate against the Trusted Root CAs but does not verify the server name — slightly weaker but functional.
Trusted Root Certification Authorities — select your internal CA from the list. If it does not appear, the CA certificate is not installed in the Windows machine's Trusted Root CA store. Install it via Group Policy or certmgr.msc.
Automatically use my Windows logon name and password — enables single sign-on (SSO). The supplicant uses the currently logged-in user's Windows credentials for PEAP-MSCHAPv2 authentication. This is the standard enterprise configuration — users authenticate transparently at login time without a separate credential prompt.
Via Group Policy (Domain-Wide Deployment)
Navigation: Group Policy Management > [GPO] > Computer Configuration > Policies > Windows Settings > Security Settings > Wired Network (IEEE 802.3) Policies
Create a new 802.3 Policy:
Policy Name: Corp_Wired_8021X
Description: 802.1X wired authentication policy
Use Windows Wired Auto Config service: Enabled
Network authentication method: Microsoft: Protected EAP (PEAP)
Authentication mode: Computer authentication
Max authentication failures: 3
PEAP settings:
Verify server certificate: Enabled
Trusted root CA: [Internal CA]
Connect to servers: ise-psn01.corp.local
Inner method: EAP-MSCHAPv2
Enable Fast Reconnect: Enabled
Authentication mode: Computer authentication — the machine authenticates using its computer account credentials, not the logged-in user's credentials. This is the preferred mode for domain-joined machines because it allows Group Policy and SCCM to manage the machine before a user logs in. The machine account is in the Domain Computers group, which matches the ISE authorization rule.
Enable Fast Reconnect — allows PEAP session resumption using TLS session caching, skipping the full TLS handshake on reauthentication. ISE supports PEAP Fast Reconnect by default. This significantly reduces reauthentication time on switch failover or roaming events.
Verifying PEAP Authentication
On the Switch
C9300# show authentication sessions interface GigabitEthernet1/0/1 details
Interface: GigabitEthernet1/0/1
IIF-ID: 0x1E5B7C3D
MAC Address: a4b1.e9f0.3c22
IPv4 Address: 10.0.10.105
User-Name: host/LAPTOP01.corp.local
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Session timeout: 36000s (server), Remaining: 35712s
Common Session ID: 0A006301000001B4E2D34F10
Current Policy: POLICY_Gi1/0/1
Server Policies:
Vlan Group: Vlan: 10
Method status list:
Method State
dot1x Authc Success
User-Name: host/LAPTOP01.corp.local — this is the computer account format for machine authentication. If you see CORP\jsmith instead, the supplicant is performing user authentication, not machine authentication. Both are valid depending on your policy design.
On ISE — Live Logs
Navigation: Operations > RADIUS > Live Logs
Status: Authentication Succeeded
Username: host/LAPTOP01.corp.local
MAC Address: A4:B1:E9:F0:3C:22
NAS-IP: 10.0.99.1
Auth Policy: Wired_Dot1X_PEAP
Authz Policy: Corp_Computer_Domain_Joined
Authz Profile: VLAN10_Corp_Data
EAP Tunnel: PEAP
EAP Authentication: EAP-MSCHAPv2
AD Groups: corp.local/Groups/Domain Computers
The presence of EAP Tunnel: PEAP and EAP Authentication: EAP-MSCHAPv2 in the Live Log confirms PEAP-MSCHAPv2 is in use. The AD Groups field confirms ISE retrieved the computer's group membership and the authorization rule matched correctly.
Common PEAP Design Considerations
Machine vs. User Authentication
Most production environments configure machine authentication (using the computer account) for the initial port authentication at boot time, and optionally user authentication after login. ISE supports both patterns:
- Machine-only: Simplest. Computer account authenticates once. VLAN and policy are based on the machine's AD group membership.
- User-only: VLAN and policy are based on the logged-in user's AD group. Requires the Wired AutoConfig service to re-authenticate when the user logs in.
- Machine + User (EAP chaining): ISE can enforce that both machine and user authentication succeed before granting full access. This requires EAP-FAST with EAP chaining or a policy-based check of session flags. EAP-FAST configuration is beyond the scope of this article.
For most enterprise campus environments, machine authentication is sufficient and simpler to support.
PEAP Identity Privacy
By default, Windows sends the computer name or username as the outer PEAP identity (the EAP-Response/Identity before the TLS tunnel). This exposes the identity in cleartext on the wire. To use an anonymous outer identity:
In the GPO PEAP settings, set the outer identity (anonymous identity) to anonymous@corp.local. ISE receives this as the User-Name in the initial RADIUS Access-Request but uses the inner MSCHAPv2 identity for policy evaluation and identity store lookup.
Troubleshooting
Symptom: Supplicant displays "Unable to connect" or Windows shows authentication failure; ISE Live Logs show "12321 PEAP failed SSL/TLS handshake because the client rejected the ISE local certificate."
Cause: The ISE server certificate is not trusted by the supplicant. The issuing CA is not in the Windows Trusted Root CA store, or the certificate CN/SAN does not match the FQDN the supplicant expects.
Fix: Verify the ISE certificate's SAN includes the FQDN configured in the Windows PEAP settings. Deploy the internal CA certificate to all endpoints via Group Policy (Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certificate Authorities). On a single test endpoint, manually import the CA certificate with certmgr.msc and retry authentication.
Symptom: ISE Live Logs show "24415 User authentication against Active Directory failed since user has invalid credentials" even though the user can log in to Windows normally.
Cause: ISE is not correctly joined to AD, or the AD join point is not in the identity source sequence used by the authentication policy. Alternatively, the computer account (for machine auth) is in a disabled state or the machine's AD password has not replicated to the AD DC ISE is querying.
Fix: Navigate to Administration > Identity Management > External Identity Sources > Active Directory > corp-ad and run Test User with a known valid account. Check which AD DC ISE is using for authentication — if ISE is using a specific DC and that DC is having replication issues, try forcing ISE to use a different DC under the Advanced Settings of the AD join point. Also verify the authentication policy's identity source is corp-ad and not Internal Users.
Symptom: Authentication succeeds for domain computers but the Authorization Policy matches the Default_Deny rule instead of Corp_Computer_Domain_Joined.
Cause: ISE is not retrieving AD group membership for the authenticating account. The AD Groups tab in the join point may not include Domain Computers, or the computer object is in an OU not covered by the AD search scope.
Fix: Navigate to Administration > Identity Management > External Identity Sources > Active Directory > corp-ad > Groups and confirm corp.local/Groups/Domain Computers is listed. If not, add it. Then in Live Logs, expand a failed authentication and check the AD-Groups-Names attribute — it should list the computer's group memberships. If the attribute is empty, the AD group retrieval is failing. Check the ISE-to-AD connectivity and the AD join account's permissions.
What's Next: [Article 11: Configuring EAP-TLS with Certificates on Cisco ISE and IOS XE] — the certificate-based alternative to PEAP-MSCHAPv2, covering PKI prerequisites, ISE certificate authentication profiles, client certificate deployment via SCEP or Active Directory Certificate Services, and per-endpoint policy enforcement using certificate attributes.
