Which transport protocol and port does a Mist AP use to send authentication traffic to the Access Assurance cloud?

Correct: b. Native Mist APs/switches wrap EAP into RadSec on TCP 2083 to radsec.nac.mist.com . UDP 1812/1813 only appears between a third-party device and a Mist Edge proxy.

You configured an EAP-TLS WLAN. New corporate laptops authenticate, but a fleet of Android tablets fails at server-certificate validation. What's the most likely fix?

Correct: a. Android validates the server cert strictly — it expects a SAN DNS name + TLS-web-server EKU and a Domain field that matches. There is no RADIUS shared secret in cloud NAC, and opening the SSID destroys security. Fix the server cert and the client Domain.

You want corporate users on VLAN 100, contractors on VLAN 250, and everything else blocked. How should you order the Auth Policy rules?

Correct: b. Rules are first-match-wins, so specific rules go on top and the deny-all sits at the bottom — like a firewall. A catch-all at the top would block everyone; a too-broad allow at the top would shadow your specific rules.

An EAP-TLS client's dashboard event shows the server cert presented, then nothing — no client cert, no reject, just an abandoned handshake. What's the root cause?

Correct: d. The handshake order is: server cert first → client validates it → only then does the client send its cert. If the client lacks the server CA, it aborts after step ③ and never sends a client cert — so you see no reject, just an incomplete handshake. Policy/VLAN failures happen later, after a client cert has been validated.

Your only rule is "EAP-TLS → Allow → VLAN 100". An employee leaves; HR disables her Entra ID account but her laptop cert is not revoked. She connects from home VPN-less on campus Wi-Fi. What happens?

Correct: a. A bare EAP-TLS rule only validates the certificate, which is still cryptographically good. To enforce off-boarding you must add an IdP account-state condition (so a disabled account fails) and/or revoke the cert at the CA. Certificate possession ≠ account still active.

A team proposes "skip certificates entirely — just use EAP-TTLS with IdP passwords for all 2,000 corporate laptops; it's faster to roll out." Evaluate.

Correct: b. EAP-TTLS (credentials via the IdP) is a legitimate fast path, especially for BYOD without a cert pipeline — but it inherits password-phishing risk. For managed corporate fleets, EAP-TLS certificates are the target; the Marvis NAC portal makes passwordless cert onboarding viable at scale. RadSec protects transport, not the user from phishing.

An auditor says "you have no on-prem NAC appliance, so you have no resilience if the internet link drops — that's worse than ISE." How do you respond accurately?

Correct: c. Honest trade-off: new authentications need internet + TCP 2083 reachability, so you mitigate with redundant WAN/egress and decide the fallback behaviour for an outage. In exchange you remove appliance patching/clustering and gain a geo-distributed, horizontally-scaled service. "Zero downtime" and "works offline" are both false; "no resilience" is also false — it's a different resilience model you design around the WAN.

Juniper Mist Access Assurance — Cloud NAC, 802.1X & Certificate-Based Auth

Q: By default, with no custom server certificate configured, what Common Name (CN) does the Mist server certificate present to clients?

Correct: a. Each Mist org has its own private CA, which issues a default Access Assurance server cert for auth.mist.com . Clients must trust that org CA (or you import your own server cert). For Android, the cert needs a SAN DNS entry + the TLS-web-server EKU or validation fails.

Q: Two Auth Policy rules can both match a contractor's EAP-TLS session. Rule A (VLAN 100) is listed above Rule B (VLAN 250). Which VLAN does the contractor get?

Correct: a. Auth Policies are top-down, first-match-wins — exactly like a firewall ruleset. There is no "most specific" preference. If a broad rule sits above a specific one, the broad rule shadows it. Reorder so specific rules come first.

Q: A third-party access switch (non-Mist) needs to authenticate clients via Access Assurance. What sits in the middle, and on which ports?

Correct: c. Third-party gear that only speaks classic RADIUS hits a Mist Edge running the Auth Proxy on UDP 1812 (auth) / 1813 (accounting). The Mist Edge wraps it into a RadSec tunnel on TCP 2083 to radsec.nac.mist.com . Native Mist APs/switches skip the middleman.

Why a "cloud NAC" is a big deal

Old-school NAC means a server (Cisco ISE, Aruba ClearPass) sitting in your data centre, fed by clustered appliances, patched by you, and licensed per endpoint. Juniper Mist Access Assurance moves that brain into the Mist cloud. No appliance, no patching, no RADIUS box — the access points and switches you already own talk to a geo-distributed cloud service that authenticates every user and device.

🧒 ELI5: Think of NAC as the security guard at an office gate. The old way put a guard (a big server) in every building. Mist puts one giant, always-awake guard in the cloud, and every door (AP/switch) phones him to ask "should I let this person in, and which floor?"

🏛 Architect lens: Access Assurance is a microservices NAC with geo-affinity — each AP/switch auto-connects to the nearest cloud auth point of presence, so latency-sensitive 802.1X stays regional. There is no single appliance to size for peak EAP load; the cloud scales horizontally. Your design effort shifts from cluster sizing to identity sources, certificate lifecycle, and policy authoring.

The packet path is the headline. Your AP or EX switch is the authenticator. Instead of speaking RADIUS (UDP) to a box on your LAN, it wraps all authentication into a RadSec tunnel and ships it over the internet to radsec.nac.mist.com on TCP 2083. The cloud is the RADIUS server now.

Big picture: the client and the AP/switch are on-prem; the RADIUS server is now a cloud service reached over RadSec.

Priya at Infosys Priya runs Wi-Fi for an Infosys campus. Her ageing on-prem NAC cluster needs a forklift upgrade. With Access Assurance she points her existing Mist APs at the cloud, imports her CA, writes three Auth Policy rules, and retires two rack units of RADIUS hardware. The auth brain is now someone else's uptime problem.

The vocabulary you must own

🛂

802.1X

tap to flip

Port-based access control. The client (supplicant) proves identity to the authenticator (AP/switch), which relays it to the auth server. No identity = no network.

🎫

EAP-TLS

tap to flip

Certificate-based 802.1X. Both sides present a certificate. No passwords to phish — the gold standard for corporate devices.

🔐

RadSec

tap to flip

RADIUS over TLS, on TCP 2083. Encrypts auth traffic so it can safely cross the internet to radsec.nac.mist.com.

🏷

Auth Policy

tap to flip

A first-match rule list. Match on auth type, cert attribute or IdP group → assign a VLAN/role and Allow or Block.

Cheat-sheet: match the method to the device. Certs for managed fleets, credentials for fast BYOD, MAB only for things that can't do better.

Warm-up · before we dig in

In Mist Access Assurance, where does the RADIUS authentication actually happen?

a) On an appliance you rack in your data centre b) In the Mist cloud — your AP/switch tunnels auth to it over RadSec c) On the client device itself d) On your DNS server

Correct: b. The whole point of cloud NAC: the auth server is a Mist cloud service. The AP/switch stays an authenticator and forwards 802.1X over a RadSec (TCP 2083) tunnel.

Warm-up · gut check

EAP-TLS authentication is described as "mutual". What does that mean?

a) Two clients authenticate each other b) Only the client proves identity, with a password c) The client validates the server's certificate AND the server validates the client's certificate d) The user authenticates twice for extra security

Correct: c. EAP-TLS verifies certificates at both ends. The client checks the server cert against its trusted-CA list; the server checks the client cert against the CAs you imported. Both must pass.

Warm-up · last one

A device with no 802.1X supplicant (e.g. a printer) needs network access. Which method does Access Assurance use?

a) EAP-TLS with a forced certificate b) MAC Authentication Bypass (MAB) — identify by MAC address c) It blocks all non-802.1X devices d) It asks the user to type a password

Correct: b. MAB is the fallback for things that can't do 802.1X. Access Assurance also fingerprints these clients (MAC, DHCP, etc.) so you can still write a sane policy for printers and IoT.

① The EAP-TLS handshake — the mutual-certificate dance

EAP-TLS is the headline auth method because there is no password to steal. Identity is a certificate. The client trusts the server because the server cert is signed by a CA the client holds; the server trusts the client because the client cert is signed by a CA you imported into Mist. Let's watch it.

🧒 ELI5: Both people show ID cards issued by an office both of them trust. The laptop shows the cloud its ID, the cloud shows the laptop its own ID, and they each check "is this signed by someone I trust?" Only then does the door open.

▶ Watch an EAP-TLS authentication

Click Play. Each stage of the mutual-certificate handshake lights up in order.

① ASSOCIATE Sneha's laptop 10.20.10.55 joins SSID Corp-Secure on a Mist AP

Security type = Enterprise (802.1X) + WPA3. Auth server = "Mist Auth".

▼

② RADSEC UP AP wraps EAP into RadSec → radsec.nac.mist.com : TCP 2083

▼

③ SERVER CERT Cloud presents its server certificate (default CN auth.mist.com)

Laptop checks it against the trusted CA in its Wi-Fi profile.

▼

④ CLIENT CERT Laptop sends its client certificate (CN sneha@infosys-corp) up to the cloud

▼

⑤ VALIDATE Cloud checks the client cert against the Trusted CAs you imported under Org > Access > Certificates

▼

⑥ POLICY Auth Policy rule matches on the cert CN / OU → assigns VLAN 100, role employee

▼

⑦ ACCESS Cloud returns Access-Accept + VLAN 100; AP drops Sneha onto the employee VLAN

Press Play to step through the full EAP-TLS handshake. Each Next advances one stage.

The two trust checks. Break either one and the client never gets on — usually silently.

Pause & Predict

A Windows laptop's Wi-Fi profile has "Verify the server's identity by validating the certificate" ticked, but you never gave it the Mist server CA. EAP-TLS fails. At which stage of the handshake does it die?

Stage ③ — server-certificate validation. The client receives the server cert, looks in its trusted-CA list, finds nothing that signed it, and refuses to continue. It never even sends its own client cert. To the cloud it looks like the client just walked away — so the dashboard shows an incomplete handshake, not a clean reject. Fix: push the Mist server CA (or the org CA) to the client, or untick blind validation in lab only.

Configure it — the click path

The config is genuinely short because there is no RADIUS server to define. Three clicks-worth of work:

Mist dashboard — EAP-TLS in 3 steps

1. Organization > Access > Certificates
     → Add Certificate Authority  (paste your root + intermediate CA PEM)

2. Organization > Access > Auth Policies
     → Add Rule
        Name           : Employee-EAP-TLS
        Match Criteria : EAP-TLS
        Assigned Policy: Allowed  →  Network Access Allowed
        (optional) Label: AAA attribute → VLAN 100

3. Organization > Wireless > WLAN Templates > Add WLAN
        SSID           : Corp-Secure
        Security Type  : Enterprise (802.1X) + WPA3
        Auth Server    : MIST Auth
        VLAN           : 100  (or Dynamic / Named via site variable)

Expected result — dashboard > Monitor > Insights > client

Client     : sneha-laptop (10.20.10.55)
Auth Type  : EAP-TLS
Auth Rule  : Employee-EAP-TLS        <- the matched rule is shown
Identity   : CN=sneha@infosys-corp
Result     : Access-Allowed  ·  VLAN 100  ·  role employee

No RADIUS server to configure

On the WLAN, the Authentication Server is literally MIST Auth — you do not type any RADIUS server IP, shared secret or port. That field disappears versus a traditional NAC. If a colleague asks "where's the RADIUS box?", the answer is "it's the cloud, reached over RadSec on TCP 2083."

Quick check · inline

By default, with no custom server certificate configured, what Common Name (CN) does the Mist server certificate present to clients?

a) auth.mist.com, signed by your org's private Mist CA b) The IP address of the nearest AP c) radius.local d) There is no server certificate in EAP-TLS

Correct: a. Each Mist org has its own private CA, which issues a default Access Assurance server cert for auth.mist.com. Clients must trust that org CA (or you import your own server cert). For Android, the cert needs a SAN DNS entry + the TLS-web-server EKU or validation fails.

② Auth Policies — the rule engine that decides everything

Authentication proves who you are. Authorization — what VLAN, what role, allow or block — is the Auth Policy. You build it under Organization > Access > Auth Policies as an ordered list of rules. Rules are evaluated top-down, first-match-wins, and within a rule all the match criteria must be true for it to hit.

🏛 Architect lens: Treat the policy list like a firewall ruleset — most-specific rules at the top, a broad catch-all at the bottom. Match criteria can combine auth type (EAP-TLS / EAP-TTLS / MAB), certificate attributes (CN, OU, issuer), and IdP signals (group membership, account state, MDM compliance). Assigned policies attach a VLAN, a group-based-policy role, and Allowed/Blocked. Keep a deny-all at the bottom so unknown devices land nowhere, not on VLAN 1.

▶ Watch an Auth Policy evaluate (first-match)

A contractor's laptop authenticates. Follow the rule list top-down until one rule hits.

① INPUT Authenticated identity: EAP-TLS, cert CN ravi@contractor-co, IdP group Contractors

▼

② RULE 1 Match: auth=EAP-TLS AND IdP group = Employees → no match (group is Contractors)

▼

③ RULE 2 Match: auth=EAP-TLS AND IdP group = Contractors → MATCH ✓

▼

④ ASSIGN Assigned policy: Allowed · VLAN 250 (contractor) · role limited

▼

⑤ STOP First match wins — Rule 3 (catch-all Block) is never evaluated

▼

⑥ RESULT Access-Accept → contractor lands on VLAN 250, segmented from employees

Press Play to watch the rule list resolve. Notice the system records WHICH rule matched.

Read it like a firewall ruleset: top-down, first match wins, deny-all at the bottom.

Rahul at TCS Rahul imports his org CA fine, but his contractors keep landing on the employee VLAN. The cause: his "EAP-TLS → Allow → VLAN 100" rule sits above the contractor rule with no group condition, so every EAP-TLS client matches it first. He adds the IdP group condition to Rule 1 and reorders. Contractors now fall through to VLAN 250. Lesson: a too-broad rule near the top shadows everything below it.

Pause & Predict

You have only one rule: "EAP-TLS → Allow → VLAN 100". A device authenticates fine with EAP-TLS but its cert was issued to a person who left the company (IdP account disabled). What happens, and is that what you want?

It gets allowed onto VLAN 100 — which is almost certainly NOT what you want. Your single rule only checks the auth type. The certificate is still cryptographically valid; the cloud has no reason to reject it. To revoke an ex-employee you must either add an IdP-account-state condition (so a disabled account fails the rule), revoke the cert at your CA so it no longer chains, or both. This is exactly why EAP-TLS pairs so well with an IdP — the certificate proves possession, the IdP proves the account is still alive.

The #1 Okta / Entra integration trap

Symptom: you add an Identity Provider, every IdP-group rule fails to match, and the dashboard error is vague. Cause (very common): the OAuth Tenant ID field was filled with the full domain like yourco.okta.com instead of just the tenant ID. The field wants the ID, not the URL. Strip the .okta.com and the group claims start flowing. Same class of mistake on Entra ID — copy the Tenant ID GUID, not the login URL.

Quick check · inline

Two Auth Policy rules can both match a contractor's EAP-TLS session. Rule A (VLAN 100) is listed above Rule B (VLAN 250). Which VLAN does the contractor get?

a) VLAN 100 — first match in the list wins; Rule B is never evaluated b) VLAN 250 — the most specific rule always wins regardless of order c) Both — the client gets two VLANs d) Neither — a conflict blocks the client

Correct: a. Auth Policies are top-down, first-match-wins — exactly like a firewall ruleset. There is no "most specific" preference. If a broad rule sits above a specific one, the broad rule shadows it. Reorder so specific rules come first.

③ RadSec, MAB & the troubleshooting ladder

Two more pieces complete the picture: how third-party gear joins, and how to debug "it won't connect".

Third-party gear → Mist Edge auth proxy

Mist APs and EX switches speak RadSec natively. But a third-party switch that only speaks classic RADIUS can't reach the cloud directly. The answer is a Mist Edge running the Auth Proxy: the third-party device sends RADIUS to the Mist Edge on UDP 1812 (auth) and 1813 (accounting); the Mist Edge wraps it into RadSec and forwards to radsec.nac.mist.com : 2083. Devices with no supplicant fall back to MAB.

🏛 Architect lens: Open outbound TCP 2083 from your APs/switches (or the Mist Edge) to radsec.nac.mist.com in the firewall. That single egress rule is the whole transport dependency. For third-party authenticators, the Mist Edge OOBM IP listens on RADIUS 1812/1813 inward and dials RadSec 2083 outward — size the Mist Edge for your peak auth rate, not your client count.

▶ "Client won't connect" — the 5-step ladder

Run this top-down. Each step rules out one failure layer.

① TRANSPORT Is outbound TCP 2083 to radsec.nac.mist.com open? No RadSec tunnel = nothing authenticates.

▼

② SERVER TRUST Does the client trust the Mist server cert? Missing CA on the client = handshake dies at stage ③, looks like "client gave up".

▼

③ CLIENT CERT Is the client cert chained to a CA you imported? Wrong CA → Access-Reject, often shown as wrong/no role.

▼

④ POLICY Did any Auth Policy rule match? Check the Auth Rule field in client Insights. "No rule" = it hit the deny-all.

▼

⑤ VLAN Did the returned VLAN actually get plumbed on the switch/AP? A VLAN the trunk doesn't carry = authenticated but no DHCP.

Press Play to walk the ladder. Mist's dynamic packet captures show you exactly which step failed.

Sneha at HCL Sneha's freshly-imaged Android tablets fail EAP-TLS while Windows laptops work. The cause is classic: Android is strict — it needs the server certificate to carry a SAN DNS entry and the TLS web-server authentication EKU, plus the matching Domain filled in the Wi-Fi config. She reissues the server cert with the SAN, sets the Domain on the tablets, and Android stops bailing out at server-trust.

Android EAP-TLS Wi-Fi config — the fields that matter

EAP method        : TLS
CA certificate    : <your imported server CA>
Domain            : auth.mist.com        # must match server cert SAN/CN
User certificate  : sneha-tablet-client
Identity          : sneha@infosys-corp   # the cert CN/email

Expected — dashboard client event timeline

10.20.30.41  android-tablet
  → 802.1X start
  → server cert presented (auth.mist.com)   OK trusted
  → client cert validated (CN=sneha@infosys-corp)  OK
  → Auth Rule: Employee-EAP-TLS  →  Allow  VLAN 100

Passwordless onboarding is now native

Recent Mist updates let users self-onboard through a custom NAC portal using the Marvis Client app: after an SSO sign-in, the device is auto-provisioned with the right Wi-Fi profile and a personal certificate — so EAP-TLS works with zero password and zero IT ticket. Great for BYOD at scale; pair it with an IdP-group rule so the issued cert lands on the right VLAN.

Pause & Predict

A client authenticates successfully — the dashboard shows Access-Allowed and the matched Auth Rule — but the user still can't get an IP address or reach anything. Where do you look next?

Step ⑤ — the VLAN plumbing, not the auth. Authentication and authorization both passed; the cloud returned (say) VLAN 100. If the switchport trunk or the AP's WLAN VLAN list doesn't actually carry VLAN 100, the client is "authenticated to nowhere" — no DHCP, no gateway. Verify the returned VLAN exists on the trunk and has a DHCP scope. NAC can place a client in a VLAN, but it can't create the VLAN on your fabric for you.

EAP-TTLS vs EAP-TLS — pick deliberately

Symptom: you wanted "no passwords" but users still type credentials. Cause: the SSID or rule is using EAP-TTLS (credential-based, validated against your IdP via the ROPC API) instead of EAP-TLS (certificate-based). TTLS is fine for quick rollout and BYOD without a cert pipeline, but it is phishable. For corporate laptops, EAP-TLS with machine/user certs is the target state. Decide per WLAN, and label your rules so the next engineer can tell them apart.

Quick check · inline

A third-party access switch (non-Mist) needs to authenticate clients via Access Assurance. What sits in the middle, and on which ports?

a) Nothing — third-party switches speak RadSec to the cloud directly b) A DNS server forwarding on UDP 53 c) A Mist Edge Auth Proxy — RADIUS UDP 1812/1813 inward, RadSec TCP 2083 outward to the cloud d) A second Mist AP acting as a relay

Correct: c. Third-party gear that only speaks classic RADIUS hits a Mist Edge running the Auth Proxy on UDP 1812 (auth) / 1813 (accounting). The Mist Edge wraps it into a RadSec tunnel on TCP 2083 to radsec.nac.mist.com. Native Mist APs/switches skip the middleman.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from Mist Access Assurance docs + field practice. For a live issue, open Monitor > Insights on the client and read the auth event timeline.

🧠 Lock it in — explain it back

In one or two sentences, explain to a teammate why an EAP-TLS client can be cryptographically valid yet still be the wrong person to let on the network. Teaching it is the fastest way to remember it.

✓ We'll nudge you. Saved locally.

📖 Glossary — say these like an L3

NAC: Network Access Control — decide who/what is allowed on, then assign VLAN/role.
802.1X: Port-based access control: supplicant → authenticator → auth server.
EAP-TLS: Certificate-based 802.1X with mutual (client + server) cert validation. No passwords.
EAP-TTLS: Credential-based 802.1X; user/password checked against your IdP. Phishable.
MAB: MAC Authentication Bypass — fallback for devices with no 802.1X supplicant.
RadSec: RADIUS over TLS on TCP 2083 to radsec.nac.mist.com; encrypts auth across the internet.
Mist Edge: Appliance/VM running the Auth Proxy: RADIUS 1812/1813 in, RadSec 2083 out, for third-party gear.
Auth Policy: First-match rule list: match criteria → assigned policy (Allow/Block + VLAN/role).
Server certificate: The cloud's cert (default CN auth.mist.com); the client must trust its CA.
IdP: Identity Provider — Entra ID / Okta / Google; supplies group, account-state and MDM signals.

📚 Sources

Juniper Networks Docs — Mist Access Assurance Overview: cloud microservices NAC, geo-affinity, 802.1X + MAB, IdP integration. juniper.net/documentation
Juniper Networks Docs — Configure Certificate-Based (EAP-TLS) Authentication: Org > Access > Certificates / Auth Policies, mutual cert flow, MIST Auth server, no RADIUS config. juniper.net/documentation
Juniper Networks Docs + RADIUSaaS — RadSec / Mist Edge Auth Proxy: TCP 2083 to radsec.nac.mist.com, third-party RADIUS UDP 1812/1813. juniper.net/documentation · docs.radiusaas.com
Mist Documentation — Access Assurance Server Certificate: default org-CA cert for auth.mist.com, SAN DNS + TLS-web-server EKU for Android validation. mist.com/documentation
artofrf.com — Mist Access Assurance — Mist Cloud NAC Configuration (practitioner field write-up): Okta Tenant-ID gotcha, server-cert CN confusion, wrong-CA → wrong-group, ~4-hour deploy, matched-rule visibility. artofrf.com
Juniper Mist Product Updates (2025) — NAC portal onboarding via the Marvis Client app: passwordless SSO + auto-provisioned personal certificate. juniper.net/documentation
Juniper Certification — Mist AI, Associate (JNCIA-MistAI / JN0-252) blueprint: WLAN + Mist AI fundamentals, access/security operations. juniper.net/training/certification

What's next?

You can now authenticate and authorize every device. Next we hand the keys to the AI: Marvis, the Mist Virtual Network Assistant — conversational root-cause analysis, "why is this client failing 802.1X?" in plain English, and AIOps actions that fix problems before users open a ticket.

Next · Juniper Marvis Virtual Network Assistant & AIOps → ← All lessons

Juniper Mist Access Assurance — Cloud NAC, 802.1X & Certificate-Based Auth

Pick where to start

Cloud NAC, no box

EAP-TLS handshake

Auth Policies

Troubleshoot

Why a "cloud NAC" is a big deal

The vocabulary you must own

① The EAP-TLS handshake — the mutual-certificate dance

▶ Watch an EAP-TLS authentication

Configure it — the click path

② Auth Policies — the rule engine that decides everything

▶ Watch an Auth Policy evaluate (first-match)

③ RadSec, MAB & the troubleshooting ladder

Third-party gear → Mist Edge auth proxy

▶ "Client won't connect" — the 5-step ladder

🤖 Ask the AI Tutor

📝 Wrap-up — seven more

🧠 Lock it in — explain it back

📖 Glossary — say these like an L3

📚 Sources

What's next?