Assistance Required for Azure AD (Entra ID) Based SSO Authentication for Meraki Wireless Network

Microsoft Entra ID is not a native RADIUS server, so the recommended design for Intune-managed Windows 11 devices is WPA2/WPA3-Enterprise with EAP-TLS certificates, using either Meraki Access Manager with Entra ID lookup or an external RADIUS service that can validate those certificates.

Recommended architecture

Preferred for a cloud-oriented deployment

Windows 11
  ├─ Intune Enterprise Wi-Fi profile
  ├─ Trusted CA certificates
  └─ Device or user SCEP/PKCS certificate
          │ EAP-TLS / 802.1X
          ▼
Meraki MR access point
          ▼
Meraki Access Manager
  ├─ Validates certificate and trust chain
  └─ Optional Entra ID lookup for identity/policy

Cisco documents EAP-TLS certificate authentication with optional Entra ID lookup through Meraki Access Manager. This is the closest documented design to “Meraki Wi-Fi authentication using Entra ID,” but Entra ID supplies identity information rather than acting as the RADIUS server.^1^

Before selecting this design, confirm with Cisco that Access Manager is available and licensed for your Meraki organization, AP models, region, and required WPA mode.

Alternative: external RADIUS

Use Meraki WPA2-Enterprise with an external RADIUS platform, such as NPS where its AD dependencies fit. The AP is the RADIUS client and relays EAP between Windows and the authentication server; it does not authenticate the certificate itself.^2^

For resilience, deploy two RADIUS servers and configure both on the Meraki side. Record AP/RADIUS IP addresses, configure matching shared secrets, allow the required RADIUS traffic, and define any needed Meraki vendor-specific attributes.^3^

Important NPS and SSO boundaries

The Microsoft Entra MFA NPS extension is not a replacement for AD-based primary authentication. Its documented flow is:

1. NPS authenticates primary credentials against Active Directory.
2. The NPS extension requests secondary authentication from Entra MFA.
3. NPS returns the RADIUS result.

Therefore, this option assumes Active Directory-backed users and does not accomplish a cloud-only migration from AD to native Entra RADIUS.^4^

Also distinguish these unrelated SSO functions:

• Meraki Entra splash-page integration is captive-portal authentication, not WPA-Enterprise 802.1X.^5^
• Meraki SAML SSO authenticates administrators to Dashboard, not wireless clients.^6^

Certificate and Intune deployment

1. Establish the PKI
   • Use Microsoft Cloud PKI, Cloud PKI with your own CA, or another PKI compatible with the selected authentication service.
   • Issue client certificates through SCEP or PKCS.
   • Ensure the client certificate has Client Authentication EKU.
   • Give the RADIUS/authentication service a certificate with Server Authentication EKU.
   • Deploy the full required CA trust chain to both Windows devices and the authentication service.^7^
   Microsoft Cloud PKI can issue SCEP certificates to Intune-managed devices, but it does not supply the TLS server certificate used by the Wi-Fi authentication service; obtain that separately and deploy its issuing CA through an Intune trusted-certificate profile.^8^
2. Create Intune certificate profiles
   • Devices → Configuration: create a trusted-certificate profile containing the authentication server’s root/issuing CA.
   • Create a SCEP or PKCS client-certificate profile.
   • Choose whether the certificate represents the device or user. Verify that all Entra attributes used in its subject or SAN exist; otherwise issuance fails.^9^
3. Create the Windows Wi-Fi profile
   • Intune admin center → Devices → Configuration → Create → Windows 10 and later → Wi-Fi → Enterprise.
   • Enter the Meraki SSID and enable automatic connection.
   • Select EAP-TLS.
   • Enter the exact certificate server names.
   • Select the trusted-root profile.
   • Select the SCEP or PKCS client-certificate profile.
   • Set authentication mode to:
     • Machine for device authentication before user sign-in.
     • User for per-user authorization.
     • User or machine only when the authentication service and certificate deployment support both identities.
   Intune supports these authentication modes, EAP-TLS certificate selection, server-name validation, trusted roots, preauthentication, and PMK caching.^10^

Deployment guidance

• Prefer device EAP-TLS for managed corporate endpoints, pre-logon connectivity, and passwordless roaming.
• Use user EAP-TLS only when network policy must distinguish individual users.
• Keep guest/BYOD access on a separate SSID and use splash-page authentication if appropriate.
• Pilot with a dedicated SSID and a small Intune group before migration.
• Validate certificate issuance, chain trust, revocation reachability, server-name matching, roaming, renewal, and behavior before and after Windows sign-in.
• For Meraki EAP-TLS testing, do not rely solely on Dashboard’s RADIUS test; Cisco notes that it consistently fails for EAP-TLS. Use authentication-server logs and packet captures instead.^2^

References

1. EAP-TLS Certificate-Based Authentication with Entra ID Lookup
2. RADIUS: WPA2-Enterprise With EAP-TLS - Cisco Meraki
3. Plan NPS as a RADIUS server
4. RADIUS authentication with Microsoft Entra ID
5. Microsoft Entra ID Integration with Splash Page - Cisco Meraki
6. Configuring SAML SSO with Microsoft Entra ID - Cisco Meraki
7. Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS
8. Microsoft Cloud PKI deployment for Microsoft Intune
9. Configure Microsoft Cloud PKI - Bring your own CA
10. Add Wi-Fi settings for Windows devices in Intune