Before the deep dive
An endpoint completes EAP-TLS and the authentication result is successful. But that result alone doesn't establish whether the certificate was mapped to the intended employee, whether the correct authorization rule matched, or whether the network enforced the expected VLAN. Those are separate decisions, and each deserves its own evidence.
This TechTorial builds a deliberately narrow Cisco Access Manager wireless pilot in the Meraki Dashboard. A user certificate must resolve to the correct Microsoft Entra ID user principal name (UPN). Access Manager validates the certificate, then evaluates the user's previously synchronized account and group attributes; Entra is not authenticating each EAP-TLS exchange live.
The focused pilot
The example uses SSID AM-Pilot, the Entra group Employees, and illustrative employee VLAN 250. Only an enabled user with a matching certificate and group membership reaches the restricted employee authorization. A second, network-and-SSID-scoped Pilot-Deny rule catches nonmatches without changing the organization's shared default policy.
Two limits shape what this pilot proves. The Entra attributes are a synchronized copy, not a live directory decision, so a recent group change needs a completed sync and a new authentication before it can affect the result. And a valid user certificate does not establish the endpoint's current compliance posture. Both limits matter when interpreting a successful authentication.
Did EAP-TLS accept the correct certificate and map the expected UPN?
Did the synchronized Entra attributes match the intended rule?
Did the AP apply VLAN 250 and restrict access as intended?
Where availability changes the security boundary
For the baseline, Extended Local Authentication stays disabled. During that optional fallback, Access Manager policy rules aren't evaluated. Cisco's documentation does not fully reconcile how the fallback VLAN is selected, so this tutorial does not claim a safe or predictable replacement for online authorization without deployment-specific testing.
Run four checks: a legitimate employee, a certificate-valid nonmember, an invalid certificate, and a user removed from the group followed by synchronization and reauthentication. Use the Access Manager Session Log to inspect the decision. Then check the client's actual VLAN and reachable networks on the infrastructure. Treat the documented expected outcomes as a test plan, not as measurements from a completed lab.
The expandable walkthrough includes the exact authorization conditions, negative tests, rollback boundaries, and eight numbered Cisco references.
▤ GO DEEPER · COMPLETE ARTICLEFull technical walkthrough and verificationEntra sync · certificate trust · scoped rules · negative tests · fallback behavior · 8 Cisco references
A documented EAP-TLS pilot that distinguishes certificate identity, synchronized Entra authorization, and enforced network access.
The problem
A device completes EAP-TLS authentication. Was its certificate valid, did the certificate identity resolve to the right employee, and did the network actually enforce the intended access? Those are three separate questions. An authentication success alone cannot answer all three.
We'll configure Cisco Access Manager in the Meraki Dashboard to authenticate a user certificate, look up synchronized Microsoft Entra ID user attributes, and assign an employee VLAN only when a narrow rule matches. Entra is not the live EAP-TLS authenticator: Access Manager validates the certificate and evaluates authorization using a previously synchronized copy of Entra user data. [1]
EAP-TLS certificate trust and user-to-UPN mapping
Synced Entra attributes and the first matching Access Manager rule
Assigned VLAN and observed network reachability
Pilot design and prerequisites
Our example uses a dedicated wireless SSID, AM-Pilot, an Entra group, Employees, and employee VLAN 250. These names and numbers are illustrative; substitute real values. Provision VLAN 250 in the pilot network and retain a separate, least-privilege base SSID VLAN. We are testing VLAN assignment, not Adaptive Policy or SGT enforcement.
Confirm before configuring:
- Platform: Supported Meraki MR and MR 30.7+, plus a Cisco Access Manager license. Cisco offers a 90-day evaluation trial only for Meraki co-termination organizations, not subscription organizations; PDL licensing is unsupported. [8] For a wired variant, Cisco lists supported MS platforms beginning at MS 17+. Consult the device table for model-specific capabilities; SGTs have separate hardware and device-license requirements. [2], [3]
- Cloud: Access Manager is not available in Meraki's Canada, China, or India regional clouds or the Meraki FedRAMP cloud. [8] The Entra integration separately requires an Azure Global tenant, not Azure Government. [3], [5]
- Identity: A certificate-issuing PKI, an Entra user in
Employees, and a user certificate containing a field whose value exactly matches the Entra UPN—often Subject Alternative Name (SAN) RFC822. Do not assume email and UPN are equal. EAP-TLS also supports machine certificates, but Entra device-group lookup is not supported for this pattern. Cisco currently requires user and machine certificates to use the same selected identity attribute per CA, complicating mixed user/machine deployments. [1], [3] - Change boundary: Access Manager has a single rule list and Default Rule for the organization, not a distinct policy list per SSID. Use a lab organization or review every affected Access Manager network before changing it. Do not change a shared production default merely to reproduce a tutorial. [3]
Configure the pilot
1. Connect and synchronize Entra
In Access Manager → Configure → Users → + Create IdP (also available through Organization → Monitor → Users), set up the Entra integration. Cisco documents Graph permissions Group.Read.All and User.Read.All (application), User.Read (delegated), and Domain.Read.All (application, for the documented multi-tenant domain-matching case), plus administrator consent. Maintain the application's client secret and its expiration date. [2], [5]
Verify that the user's UPN, account-enabled state, and Employees membership have synchronized. Proactive Sync, when enabled, updates the cached data approximately every six hours; otherwise trigger a manual sync. The integration synchronizes all users and groups rather than filtering to one group, a scope worth reviewing with the identity team. Cisco documents Proactive Sync limits of 150,000 users and 100,000 groups and a separate Access Manager organization maximum of 200,000 Entra-synced users and 100,000 groups. Above the proactive-sync user threshold, use manual synchronization within the published organization limits and confirm capacity before deployment. [2], [3], [5]
2. Configure both certificate trust relationships
Access Manager trusting the client: Open Access Manager → Configure → Certificates → Upload CA certificate. Upload the complete issuing/intermediate/root CA chain in the documented combined .cer/.crt format. Set Status = Enabled, enable Trusted Anchor on at least one certificate in the chain, and select Identity = SAN RFC822 only if its value matches the Entra UPN exactly; otherwise choose the matching supported field. Inspect an actual issued user certificate before selecting the identity and issuer match. [1]
Client trusting Access Manager: On the same Certificates page, choose Download RADIUS CA certificates. Use Cisco's client configuration guidance to trust the documented IdenTrust Commercial Root CA 1, require EAP server-certificate validation, and restrict the accepted RADIUS server name to eap.meraki.com. Trusting a CA without validating the expected server name does not adequately identify the intended RADIUS server. Do not bypass certificate warnings. Configure the client to present the intended user certificate. [4]
A valid certificate does not prove device compliance: Cisco Access Manager does not currently evaluate UEM compliance status. [3]
3. Enable the pilot SSID
Go to Wireless → Configure → Access control, select AM-Pilot, and choose Enterprise with Access Manager under Security. Verify SSID VLAN/IP settings and save. Keep Extended Local Authentication disabled for the baseline so the test exercises the online policy path. [1]
4. Define the employee rule
Under Access Manager → Policies → Access Rules, create the enabled rule Pilot-Employees-EAPTLS with all these conditions: [1], [3]
| Attribute source | Condition |
|---|---|
| Network Access | Network = <pilot Meraki network> |
| Network Access | SSID = AM-Pilot |
| Network Access | EAP Protocol = EAP-TLS |
| Endpoint certificate | Issuer → Common Name matches your actual issuing CA (Cisco illustrates the contains operator; choose a sufficiently distinctive full issuer CN to avoid matching another trusted CA) |
| Your Entra ID domain | Account Enabled = True |
| Your Entra ID domain | Group = Match Any: Employees |
Set Authorization → Access permission = Allow restricted access, then assign VLAN 250 (or your real pilot VLAN). Plain Allow Access would retain the SSID/port's default authorization rather than demonstrate the intended VLAN override. [1], [2]
Place this rule ahead of broader rules, and inspect the entire rule list. Access Manager uses first-match-wins evaluation. Cisco also warns that rare external-dependency failures can cause user/client attributes to be skipped and evaluation to proceed. A subsequent certificate-only allow could grant access without the intended Entra checks. Do not rely on an earlier rule to protect an unsafe later rule. [3]
5. Make the non-match outcome explicit
Access Manager's Default Rule normally ships as Deny Access. Verify its existing authorization rather than assuming it is unchanged. In a lab organization with an already-denying default, an unmatched request reaches that rule and receives RADIUS Access-Reject. [3]
In an organization whose default must remain permissive, insert a pilot-specific, explicit denial immediately after Pilot-Employees-EAPTLS and before any broader allow rules:
| Rule | Conditions | Authorization |
|---|---|---|
Pilot-Deny |
Network = <pilot Meraki network> AND SSID = AM-Pilot |
Deny Access |
A nonmatching employee candidate then fails closed at Pilot-Deny without changing the organization-wide default. This depends on rule ordering: review any rules above the pilot rules that could match the same SSID, and any changes to the rule list. If the deployment cannot safely scope and order these rules, use an isolated test organization rather than risk production access. [3]
Verify identity, authorization, and enforcement
Open Access Manager → Monitor → Session Log. Click the Status of a request to inspect certificate attributes, mapped identity, matched rule and returned VLAN. Then independently confirm the client's effective VLAN and test allowed/denied network reachability; Success in a RADIUS log is not proof that network segmentation worked. [2], [7]
| Test | Expected result for this reviewed, fail-closed pilot |
|---|---|
Valid user cert, exact UPN mapping, enabled account, Employees member |
Success, Pilot-Employees-EAPTLS, VLAN 250 returned; verify VLAN enforcement separately |
Valid user cert, nonmember of Employees |
Rejected, Pilot-Deny when present; otherwise the denying Default Rule—provided no earlier rule matches |
| Invalid/expired/untrusted client certificate | Authentication Failed when processed/logged; inspect client EAP logs if the exchange aborts earlier |
| Remove group membership, complete manual sync, then force reauthentication | Rejected by Pilot-Deny (or denying Default Rule), assuming updated data and no earlier matching allow rule |
For an additional revocation test, revoke a test certificate at your CA and publish an updated CRL. Under Access Manager → Configure → Certificates, upload the updated .pem CRL or configure a CRL URL, enable revocation verification, and then attempt a new authentication. Cisco documents hourly CRL URL retrieval; detection can lag behind CA publication and subsequent retrieval. Cisco documents CRL management, but specific revocation test outcomes, cache timing, and CRL-unavailability behavior have not been lab-verified here. [2], [7]
A directory update is not an immediate session teardown: Access Manager does not currently support RADIUS Change of Authorization (CoA). New authorization requires updated synchronized attributes and reauthentication. [3]
The failure-mode distinction
| Online (our baseline) | Extended Local Authentication during cloud loss (optional) |
|---|---|
| Access Manager validates the certificate, checks its synchronized Entra user attributes, evaluates the rule, and returns the assigned VLAN. | The AP can perform local certificate authentication, but Access Manager rules are not evaluated. Cisco’s Access Manager guides state that the SSID-configured VLAN applies; Cisco’s linked general MR guide describes reusing previously cached RADIUS VLAN attributes and says SGTs are not cached. Actual VLAN and SGT behavior for this deployment requires lab verification. |
For Access Manager's Extended Local Authentication, Cisco requires enablement on both the CA configuration and SSID. The supplicant must also validate the relevant *.YOUR_ORG_ID.radius.meraki.direct server name. Cisco’s linked general MR Extended Local Authentication guide lists firmware versions MR31.1.8+ / MR31.2.6+ / MR32.1.4+; its illustrated configuration selects My RADIUS server, even though its introduction describes cloud RADIUS authentication. Verify firmware branch/model requirements and applicability to the Access Manager workflow rather than assuming every MR 30.7+ installation supports fallback. [1], [4], [6]
Cisco does not reconcile the SSID-VLAN statement in its Access Manager guidance with cached-VLAN reuse in the linked general MR guide, nor establish that they describe separate implementations. Do not make the SSID base VLAN a privileged employee segment on the assumption that the Entra rule will still apply during fallback. Leave fallback off for this initial pilot; if availability needs justify it later, configure a least-privilege VLAN and lab-test the actual VLAN, SGT, revocation, outage, and recovery behavior. [1], [6]
A wired pilot can instead use Switching → Configure → Access Policies with Access Manager and policy type 802.1X, applied to one test port. Avoid adding Hybrid/MAB fallback to a certificate-only test; wired failed/critical-auth VLAN features are distinct from wireless local auth. [2], [3]
Rollback and takeaway
Disable the dedicated SSID and both pilot rules. If a separate lab organization required a default-rule change, restore that change only through the approved change plan, accounting for other networks. Do not weaken certificate validation to resolve a failed pilot.
Documentation boundary: All verification-table results are expected, not observed. Extended Local Authentication VLAN selection, SGT handling, certificate revocation, and reconnection behavior require implementation-specific lab tests.
Takeaway: prove the certificate identity, the actual authorization decision, and the enforcement result separately. Network access marked Success is evidence of one stage—not a conclusion about the whole control.
References
- [1]Cisco, EAP-TLS Certificate-Based Authentication with Entra ID Lookup. Cisco documentation ↗
- [2]Cisco, Cisco Access Manager Deployment Guide. Cisco documentation ↗
- [3]Cisco, Access Manager (supported devices, policies, limitations). Cisco documentation ↗
- [4]Cisco, EAP-TLS Client Configuration. Cisco documentation ↗
- [5]Cisco, Integrating Microsoft EntraID as an External IdP on the Organization Users Page. Cisco documentation ↗
- [6]Cisco, Meraki Local Authentication — MR 802.1X (Extended Local Authentication). Cisco documentation ↗
- [7]Cisco, Cisco Access Manager Release Notes (certificate details and CRL UI). Cisco documentation ↗
- [8]Cisco, Cisco Access Manager Licensing and Ordering Guide. Cisco documentation ↗
Verification boundary: This article is grounded in Cisco documentation. The test results are expected behaviors, not observations from a completed lab. Verify the design on your own equipment before changing production access.
Leave a Reply