PEAP-MSCHAPv2 with Active Directory, and why it does not work with Entra ID

Notes from reading documentation, not results from testing on a live system. Main source: HPE’s ClearPass 6.8 Deployment Guide and a 2021 community slide deck on Azure integration. Each point carries a page citation at the end; anything that could not be verified is marked.

PEAP builds a TLS tunnel (only the server presents a certificate) and then authenticates the user inside the tunnel, usually with a password. Why people pick it: it reuses the accounts already in Active Directory (username and password), so there is no need to issue smart cards or certificates to every user and every machine¹.

Two things to know before reading on:

• The domain controller decides pass/fail, not ClearPass. The last leg is NTLM to the DC; if AD is broken or ClearPass has not joined the domain, PEAP breaks even though the TLS part is perfectly fine¹.
• PEAP does not work with Entra ID / Azure AD. The way the cloud stores passwords is incompatible with EAP-PEAP² — once on-prem AD is gone, the practical path is EAP-TLS.

Details

This is the core trade-off against EAP-TLS: no infrastructure to issue a certificate to every client, in exchange for strength that depends on user passwords.

Three roles in an 802.1X session

Role	Who
Supplicant	the client device: laptop, tablet, phone
Authenticator	the network device guarding the door: Aruba Mobility Controller or Instant AP
Authentication server	ClearPass Policy Manager, which processes the request and returns accept/reject

The PEAP-MSCHAPv2 handshake with Active Directory

The Deployment Guide walks through all 41 steps. Grouped, they come down to six stages¹:

1. Identity request (outside the tunnel). The authenticator sends an EAP-Request for identity; the supplicant returns an EAP Identity Response — this is the Outer Identity, and it travels unencrypted. The authenticator forwards it to ClearPass.
2. First Active Directory lookup. ClearPass queries the configured authentication source over LDAP to find the username and a few basic attributes such as sAMAccountName.
3. TLS tunnel setup. ClearPass signals that it wants EAP-PEAP. The supplicant sends ClientHello; ClearPass returns ServerHello, Certificate, ServerKeyExchange, ServerHelloDone. This step repeats over several rounds because the certificate has to be cut into fragments that fit the size limit of one EAP message. The supplicant answers with ClientKeyExchange, ChangeCipherSpec, Handshake, ClientFinished; ClearPass closes with ChangeCipherSpec and ServerFinished.
4. EAP starts over, this time inside the tunnel. ClearPass asks for identity again; this time it is the Inner Identity, protected by the tunnel. ClearPass runs a second LDAP lookup.
5. MSCHAPv2 and NTLM. ClearPass sends an MSCHAPv2 challenge. When the answer comes back, ClearPass bundles the username, MSCHAPv2 response, MSCHAPv2 challenge and the domain’s NetBIOS name, and submits the whole bundle to the domain controller over NT LAN Manager (NTLM). The domain controller is the party that actually rules pass/fail, not ClearPass.
6. Session close. The domain controller reports success; the MSCHAPv2 success chain travels back out. ClearPass sends RADIUS Access-Accept with EAPOL success and key material; the authenticator and supplicant run the four-way handshake, and only then does encrypted traffic start to flow.

Two practical consequences of this sequence:

• The outer identity is exposed outside the tunnel, so it is usually set to something anonymous; only the inner identity is the real identity.
• The final authentication is NTLM to the domain controller — a broken AD, a wrong domain NetBIOS name, or ClearPass failing to join the domain breaks PEAP-MSCHAPv2, even though the TLS part is perfectly fine.

Where it sits in ClearPass’s list of methods

The 6.8 Deployment Guide says several authentication protocols can be used at the same time, and lists: PEAP, EAP-FAST, EAP-TLS, EAP-TTLS, EAP-PEAP-Public¹. Notably, TEAP is not in that list.

The limit when identity moves to the cloud

Stage 5 above also explains why PEAP does not work with Entra ID / Azure AD: it ends with NTLM to the domain controller, so it depends on how an old-style directory stores passwords. The Azure integration document says outright that PEAP was designed for NTLM/Kerberos, is not compatible with SAML/OAuth 2.0, and that the way passwords are stored in the cloud is not compatible with EAP-PEAP².

That is why Azure AD Domain Services exists: to extend support for legacy authentication². Drop on-prem AD and still want 802.1X, and the practical path is moving to EAP-TLS — see Cloud identity in NAC.

Unverified. PEAP is not an IETF standard RFC; its specification lives in the Microsoft document [MS-PEAP] and in expired IETF drafts. I have not checked this against the original documents yet.

Compare: EAP-TLS needs a certificate on the client as well; TEAP is the IETF standard for the “tunnel + inner method” pattern.

Sources

Footnotes

1. ClearPass 6.8 Deployment Guide, PDF pp. 18, 36, 303–309 ↩ ↩² ↩³ ↩⁴

2. ClearPass Microsoft Azure Integration — Part 1 (community slides, 2021), PDF pp. 4, 10 ↩ ↩² ↩³