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

Source: https://ai.techclick.in/blog_mist_access_assurance_nac
Markdown: https://ai.techclick.in/blog_mist_access_assurance_nac.md
Publisher: Techclick Infosec Pvt Ltd

Juniper Mist Access Assurance explained the AI-era way — watch an EAP-TLS handshake authenticate a laptop live, see how RadSec carries 802.1X to the cloud, build an Auth Policy, and dodge the certificate-trust traps in 11 minutes instead of an afternoon.

Juniper Mist Access Assurance — Cloud NAC, 802.1X & Certificate-Based Auth student learning map
                     A visual study map for Juniper Mist Access Assurance — Cloud NAC, 802.1X & Certificate-Based Auth showing learning path, evidence, traps, and practice sequence.

                     TECHCLICK STUDY MAP
                     Juniper Mist Access Assurance — Cloud NAC, 802.1X...
                     Juniper Mist · learn the flow, prove with evidence, avoid unsafe shortcuts

   1. Start
   Pick where to start

   2. Understand
   Why a "cloud NAC" is a big deal

   3. Prove
   ① The EAP-TLS handshake — the...

   4. Practice
   ② Auth Policies — the rule engine...

                     How to use this page
                     First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself.
                     Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456

             Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail.

## 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.

                 A client device connects to a Mist AP or EX switch (the authenticator), which wraps 802.1X EAP into a RadSec TCP 2083 tunnel to the Mist cloud NAC, which checks trusted CAs and an identity provider, then returns an allow plus VLAN.

                 No on-prem RADIUS — the auth brain lives in the Mist cloud

                 Client device
                 Laptop / phone / IoT
                 supplicant + client cert

                 Mist AP / EX switch
                 the authenticator (802.1X)

                 wraps EAP → RadSec

                 Mist Access Assurance
                 cloud NAC (RADIUS server)
                  Trusted CAs
                  Auth Policy

                 Identity Provider
                 Entra ID · Okta · Google

- 802.1X TCP 2083 RadSec Allow + VLAN 100 No RADIUS server to deploy or patch · geo-affinity routes each device to the nearest cloud auth PoP 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. client / forward path RadSec / encrypted transport allowed / success caution / fallback ### 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. A three-column comparison of the auth methods Access Assurance supports: EAP-TLS uses client and server certificates and is phishing-resistant for corporate devices; EAP-TTLS uses IdP credentials and suits quick BYOD but is phishable; MAB identifies by MAC address for non-802.1X IoT and is the weakest. Three ways in — pick the right method per device EAP-TLS Certificate (mutual) Client cert + server cert No password to phish Best for: corp laptops Marvis portal = easy certs ★★★ Strongest Phishing-resistant EAP-TTLS Credentials via IdP User/password (ROPC API) Server cert only Best for: quick BYOD No cert pipeline needed ★★ Tactical Phishable — not end state MAB MAC address only No 802.1X supplicant + device fingerprinting Best for: printers, IoT Segment on tight VLAN ★ Weakest MAC is spoofable 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. ▶ Play Next ▶ ↺ Reset Two trust checks: the client validates the server certificate against its trusted CA list, and the cloud validates the client certificate against the CAs imported into Mist. Both checks must pass before access is granted. EAP-TLS = two trust checks, both must pass CLIENT (supplicant) Trusted CA list in Wi-Fi profile Client certificate CN=sneha@corp MIST CLOUD NAC Server certificate CN=auth.mist.com Imported Trusted CAs Org > Access > Certs ① server cert → client checks it ② client cert → cloud checks it If the client doesn't trust the server cert → it never sends its own cert → silent drop. If the cloud can't chain the client cert to an imported CA → Access-Reject. No password is ever exchanged. 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? Reveal answer 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   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. ▶ Play Next ▶ ↺ Reset A decision flow showing an authenticated identity entering a top-down rule list. EAP-TLS employees go to VLAN 100, EAP-TLS contractors to VLAN 250, MAB IoT devices to VLAN 30, and everything unmatched is blocked. Auth Policy = first-match-wins decision tree Authenticated identity auth type + cert + IdP group Rule 1 — EAP-TLS & group=Employees? match → Allow · VLAN 100 · role employee VLAN 100 no match ↓ Rule 2 — EAP-TLS & group=Contractors? match → Allow · VLAN 250 · role limited VLAN 250 no match ↓ Rule 3 — MAB & fingerprint=Printer? match → Allow · VLAN 30 · role iot VLAN 30 no match ↓ Rule 4 — catch-all (any) match → BLOCK · no network BLOCKED Order matters: a broad rule above a specific one shadows it. Put specific rules first, deny-all last. 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? Reveal answer 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. ▶ Play Next ▶ ↺ Reset 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 :   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? Reveal answer 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. EAP-TLS vs EAP-TTLS — which should I use? What exactly is RadSec and why TCP 2083? Why does my client trust (or not trust) the server cert? How do I revoke an ex-employee's access? When do I need a Mist Edge? How do printers and IoT get on without 802.1X? 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. ## 📝 Wrap-up — seven more You've already answered 3 inline. Seven final make 10. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q4 · Remember Which transport protocol and port does a Mist AP use to send authentication traffic to the Access Assurance cloud? a) RADIUS over UDP 1812 b) RadSec (RADIUS over TLS) on TCP 2083 to radsec.nac.mist.com c) HTTPS on TCP 443 to the dashboard d) TACACS+ on TCP 49 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. Q5 · Apply 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? a) Reissue the server certificate with a SAN DNS entry + TLS web-server EKU, and set the matching Domain on the tablets b) Switch the whole SSID to an open network c) Reboot the access points d) Increase the RADIUS shared secret length 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. Q6 · Apply You want corporate users on VLAN 100, contractors on VLAN 250, and everything else blocked. How should you order the Auth Policy rules? a) Catch-all Block first, then the specific employee/contractor rules b) Specific rules first (employee, contractor), catch-all Block last c) Order doesn't matter — most-specific rule always wins d) Put a single "EAP-TLS → Allow" rule and let VLANs sort themselves 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. Q7 · Analyze 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? a) The Auth Policy has no matching rule b) The returned VLAN isn't on the trunk c) The MAB fingerprint database is empty d) The client doesn't trust the server certificate, so it refuses to send its own cert and walks away 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. Q8 · Analyze 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? a) She is allowed onto VLAN 100 — the cert is still valid and the rule never checks account state b) She is blocked automatically because Entra disabled the account c) The AP refuses because the password expired d) She gets VLAN 1 by default 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. Q9 · Evaluate 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. a) Perfect — EAP-TTLS is always more secure than EAP-TLS b) Faster to deploy, but EAP-TTLS is credential-based and phishable; corporate laptops should target EAP-TLS with machine/user certs (now easy via the Marvis NAC portal). Use TTLS tactically, not as the end state c) Impossible — Access Assurance only supports EAP-TLS d) Fine, because passwords can't be stolen over RadSec 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. Q10 · Evaluate 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? a) Agree fully — cloud NAC is strictly less resilient and should be avoided b) Claim the cloud guarantees zero downtime so the question is irrelevant c) New auths to the cloud do depend on internet + RadSec reachability, so the real design control is WAN/egress redundancy and a defined fallback behaviour; in return you drop appliance patching, clustering and the geo-distributed service gives auth-PoP resilience the single appliance lacked d) Say RadSec works without any internet connection 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. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again". ### 🧠 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. Remind me ✓ 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

             📩  Quiz me on this in 7 days.  Opt in and we'll email you 3 micro-questions from this lesson at Day 1, Day 7 and Day 30 — spaced repetition is how it sticks. Un-tick any time.

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt