Which ClearPass pillar issues a per-device TLS client certificate for EAP-TLS authentication?

Correct: b — Onboard. Onboard provisions Windows/macOS/iOS/Android devices with a TLS client cert from its built-in CA, which becomes the EAP-TLS network identity. Guest is web-portal access; Device Insight is profiling; Insight is reporting/dashboards.

Sneha needs day-visitors to authenticate once and not see the portal again until tomorrow. Which feature does she configure, and to what lifetime?

Correct: a. MAC caching remembers the guest's MAC after the first portal login; reconnects use MAC-auth and bypass the portal until the cached-role lifetime expires. An ~8–10h lifetime matches a working day. Certificates (b) are for employee BYOD, not visitors.

Rahul's Android phone fails the Onboard wizard at the very first step while his colleague's iPhone works fine on the same SSID. What's the most likely fix?

Correct: b. Android devices need pre-provisioning via the QuickConnect app before the configuration step; iOS/macOS handle the profile natively. Re-imaging is overkill, and dropping Android to Guest (c) defeats the point of BYOD with certificates.

Priya enables Onboard AND Device Insight. She notices onboarded laptops appear in Device Insight with rich attributes she never configured a collector for. Why?

Correct: c. When a deployment uses Onboard, the device information gathered during onboarding is fed into Device Insight, so onboarded devices arrive pre-enriched. That tight integration is a selling point — identity (Onboard) and visibility (Device Insight) reinforce each other.

An auditor proposes: "Drop Onboard certificates and just use a single strong WPA2-Personal passphrase for all BYOD — it's simpler and we rotate it yearly." Evaluate this against the per-device certificate model.

Correct: b. A shared PSK is all-or-nothing: it can't be revoked for one device, it spreads to every personal phone, and it carries no identity (you can't tell who connected). Onboard certificates give unique, revocable, password-less identities — the exact reason ClearPass exists. Option d misses the bigger structural flaw (no per-device control), not just the cipher.

Aruba ClearPass Guest, Onboard & Device Insight — BYOD, Certificates & Profiling

Q: In a sponsored-guest workflow, what happens immediately after a visitor submits the self-registration form?

Correct: b. In sponsor-approval mode the guest sits in a holding role until the host employee clicks Confirm in the sponsorship-confirmation email. Only then does ClearPass change the role and allow WLAN access. Certificates (c) are Onboard's job, not Guest.

Q: During Onboard, at which point does the user actually type a password?

Correct: c. The password is used a single time, during provisioning, to prove the user is allowed to onboard and to stamp their identity into the cert's CN. From then on EAP-TLS presents the certificate — no password on the wire, which is exactly why EAP-TLS resists credential phishing.

Q: Which protocol does ClearPass Onboard use to let the device request its certificate from the built-in CA?

Correct: a. SCEP is the workhorse for device certificate enrollment; ClearPass Onboard also supports EST (RFC 7030) and can act as a CA for third-party MDMs that use SCEP. Revocation status is then checked with OCSP. SNMP and DHCP are profiling inputs, not enrollment protocols.

Q: The ClearPass Collector service forwards consolidated device events to the Device Insight Analyzer. Which port does the Collector listen on?

Correct: a. The Collector listens on TCP 6180 to receive profile requests from Policy Manager services and forward them to the Analyzer. UDP 1812 is RADIUS auth, UDP 3799 is RADIUS CoA — both important elsewhere, but not the Collector port.

Q: In Access Tracker, an onboarded device shows OCSP: REVOKED → REJECT . The help desk says "but the user's AD password still works on the VPN". What's going on?

Correct: d. Certificate identity and password identity are separate. Revoking the Onboard cert kills EAP-TLS for that one device; the AD account can still log in elsewhere unless you also disable it. This separation is a feature — you can lock a lost phone without touching the user's account.

Start here — the assumption that breaks every BYOD rollout

Most L1 engineers think one thing: "BYOD is just a Wi-Fi password the employee types on their phone." So they hand out a PSK, the phone connects, everyone's happy — for a week. Then the employee leaves, the PSK is still on their phone, and you can't revoke one person without rotating the key for all 600 devices.

ClearPass flips that model. A personal device should carry a certificate, not a shared secret. BYOD done right means each device earns a unique EAP-TLS identity that you can revoke on its own. That is exactly what ClearPass Onboard automates. Get this one idea and the rest of the lesson clicks into place.

Device / supplicant ClearPass service Decision / risk Granted / success Certificate / identity

Figure 1 — Three pillars, one brain. Guest handles visitors, Onboard issues BYOD certificates, Device Insight profiles everything else; all three feed one access decision.

Quick warm-up — predict before you read

Warm-up · 1 of 3

A visitor walks into the Infosys reception and needs Wi-Fi for two hours. Which ClearPass pillar handles them?

a) ClearPass Guest — captive portal with a time-limited account b) ClearPass Onboard — issue them a certificate c) Device Insight — profile their phone first d) OnGuard posture agent

Correct: a. Temporary visitors belong on Guest. You never want to issue a long-lived certificate to someone who is here for two hours — that is what Onboard is for (employee BYOD). Device Insight and OnGuard are about visibility and posture, not visitor onboarding.

Warm-up · 2 of 3

Why is a per-device certificate better than a shared Wi-Fi password for employee phones?

a) Certificates are faster to type b) You can revoke ONE device's certificate without affecting the other 599 devices c) Certificates don't expire d) Passwords aren't supported on phones

Correct: b. Per-device revocation is the whole point. A shared PSK is all-or-nothing — lose one phone and you must re-key everyone. A certificate is a unique identity; revoke it via OCSP/CRL and that one device is locked out instantly while everyone else keeps working.

Warm-up · 3 of 3

A new wireless security camera connects but ClearPass shows it as "Unknown". Which pillar's job is it to figure out what that device actually is?

a) Guest — give it a portal b) Onboard — issue it a certificate c) Device Insight — fingerprint and classify it d) RADIUS accounting

Correct: c. A headless IoT camera can't fill in a portal and can't run an Onboard wizard. Device Insight profiles it from its DHCP fingerprint, traffic patterns and behaviour, then classifies it as "IP Camera — Brand X" so policy can quarantine it to an IoT VLAN.

The four words you must own first

🎟

Guest

tap to flip

Web-based, temporary access for visitors. Self-registration or sponsor approval, a captive portal, and MAC caching so they don't re-login every reconnect.

📜

Onboard

tap to flip

Provisions BYOD with a TLS client certificate from the built-in CA. The device then uses EAP-TLS — no password, fully revocable per device.

🔬

Device Insight

tap to flip

Cloud AI that fingerprints and clusters every device using active scans + passive telemetry + machine learning. Turns "Unknown" into "Brand-X IP Camera".

🪪

SCEP

tap to flip

Simple Certificate Enrollment Protocol — how the device asks the CA for a cert during Onboard. ClearPass also speaks EST (RFC 7030) and checks revocation via OCSP.

① Guest Access — let visitors in without letting them roam

Reception desk pe ek visitor aata hai. He's not your employee. He just needs internet for a meeting. You do not want to put him on the corporate VLAN, and you do not want to hand-create an account every time. ClearPass Guest solves this with a captive portal.

Explain like I'm:

Think of it like a cinema ticket counter. The visitor walks up (connects to the open SSID), gets sent to the ticket window (the portal), shows ID or asks an employee to vouch for them (sponsor approval), and gets a ticket valid for two hours (guest account). Next time they walk in the same day, the usher recognises their face (MAC caching) and waves them through — no second ticket.

Two ClearPass services collaborate: a MAC Authentication service and a RADIUS web-login (captive portal) enforcement service. On first connect the MAC is unknown → user is redirected to the portal → on success ClearPass writes an Endpoint record and caches the MAC. Reconnects hit the MAC-auth service first and skip the portal until the cached-role lifetime (set per role: Contractor, Guest, Employee) expires. The portal certificate must be publicly signed with a CN matching the portal URL — and that CN must not have an A-record in DNS.

Sneha at Infosys sets up a sponsored-guest portal. A visitor self-registers, an email goes to their host employee, who clicks "Confirm" — only then is the guest moved from the holding role to the Guest role and allowed onto the WLAN. No employee approval, no internet.

▶ Watch a sponsored guest log in (then skip the portal)

Click Play. Each stage lights up as the visitor's device moves through ClearPass Guest.

① CONNECT Visitor phone MAC a4:83:e7:11:22:33 joins open SSID Techclick-Guest

MAC is unknown to ClearPass — no Endpoint record yet.

▼

② MAC-AUTH MAC Authentication service runs first → no cached MAC → returns the "redirect to portal" role

▼

③ PORTAL Controller redirects to https://guest.techclick.in/register → visitor self-registers

▼

④ SPONSOR Email to host employee → host clicks Confirm → guest role activated for 8 hours

▼

⑤ CACHE MAC ClearPass writes Endpoint a4:83:e7:11:22:33 = Guest with lifetime 8h

▼

⑥ RECONNECT Phone reconnects after lunch → MAC-auth finds the cache → skips the portal, straight onto Guest VLAN

Press Play to step through the first login and the cached reconnect. Each press of Next advances one stage.

Pause & Predict

A guest complains the portal pops up every single time they reconnect, even within the same hour. Before you read on — what is the single most likely cause?

MAC caching isn't taking effect. Either the Guest MAC Caching service template was never deployed, the cached-role lifetime is set far too short, or the MAC-auth service is ordered below the web-login service so it never runs first. Check that Endpoint records are actually being written after the first login.

Quick check · Q1 of 10

In a sponsored-guest workflow, what happens immediately after a visitor submits the self-registration form?

a) The guest is instantly placed on the corporate VLAN b) An email/notification goes to the sponsor, who must Confirm before the guest gets the Guest role c) ClearPass issues an EAP-TLS certificate to the device d) The device is rebooted to apply the new profile

Correct: b. In sponsor-approval mode the guest sits in a holding role until the host employee clicks Confirm in the sponsorship-confirmation email. Only then does ClearPass change the role and allow WLAN access. Certificates (c) are Onboard's job, not Guest.

② Onboard — how a BYOD phone earns a certificate

Onboard is the employee equivalent of Guest, but instead of a temporary web ticket the device gets a permanent, revocable identity: a TLS client certificate. ClearPass Onboard supports Windows, macOS, iOS and Android. The certificate identifies both the device and the user who provisioned it, and becomes the device's network identity during EAP-TLS.

Figure 2 — The Onboard journey. A throwaway provisioning SSID delivers the certificate; the device then graduates to the secure SSID for life.

Rahul at TCS onboards his Android phone. He joins Onboard-Provision, but the wizard fails until he installs QuickConnect first — Android requires pre-provisioning that iOS does not. Once the SCEP request completes, his phone holds a cert and jumps to the secure SSID automatically.

▶ Watch a device go from "unknown" to "EAP-TLS trusted"

A BYOD laptop earns a certificate, then authenticates with no password at all.

① PROVISION SSID Laptop 172.16.40.25 joins Onboard-Provision (PEAP / web-auth to verify the user)

▼

② USER AUTH User logs in with AD credentials once → ClearPass confirms they're allowed to onboard

▼

③ SCEP REQUEST Device sends a SCEP CSR to the built-in CA at onboard.techclick.in

▼

④ CERT ISSUED CA issues a TLS client cert (CN = device + user) → profile installs the cert + secure-SSID config

▼

⑤ SWITCH SSID Device auto-joins Techclick-Secure and presents the certificate (no password)

▼

⑥ EAP-TLS ClearPass validates the cert chain + checks OCSP → not revoked → grants the Employee role + VLAN

Notice the password is only used ONCE (stage 2) to authorise onboarding. After that the certificate is the identity.

ClearPass Onboard — certificate authority settings (Onboard > Certificate Authorities)

CA Name:          Techclick-Onboard-CA
CA Type:          Local Certificate Authority
Key Type:         RSA 2048-bit
Cert Validity:    365 days (device certs)
SCEP Enabled:     Yes   (challenge: per-request)
EST Enabled:      Yes   (RFC 7030)
Revocation:       OCSP + CRL  (publish CRL every 4h)

Expected — Onboard > Management > Device repository

Device: Rahul-Pixel-8         Status: Provisioned
  Serial:  3F:A1:09:...        Cert CN: rahul@techclick.in
  Issued:  2026-05-31          Expires: 2027-05-31
  User:    rahul               OS: Android 15
  [ Revoke ]  [ Delete ]  ← one click locks out THIS device only

Pause & Predict

Rahul leaves the company. IT clicks Revoke on his device in the Onboard repository. Predict: what stops his phone from connecting tonight, and what makes it instant?

EAP-TLS fails at the revocation check. When his phone presents its cert, ClearPass queries OCSP (or the CRL), sees the cert is revoked, and rejects authentication. OCSP is near-instant; CRL depends on publish interval (we set 4h above). Either way, only Rahul's device dies — every other employee keeps working because their certs are untouched.

Quick check · Q2 of 10

During Onboard, at which point does the user actually type a password?

a) Every time they connect to the secure SSID b) Never — Onboard is fully passwordless from the start c) Once during provisioning to authorise the certificate request; afterwards EAP-TLS uses the cert, not the password d) Only when the certificate expires

Correct: c. The password is used a single time, during provisioning, to prove the user is allowed to onboard and to stamp their identity into the cert's CN. From then on EAP-TLS presents the certificate — no password on the wire, which is exactly why EAP-TLS resists credential phishing.

Quick check · Q3 of 10

Which protocol does ClearPass Onboard use to let the device request its certificate from the built-in CA?

a) SCEP (Simple Certificate Enrollment Protocol), with EST as an alternative b) SNMP c) RADIUS accounting d) DHCP option 43

Correct: a. SCEP is the workhorse for device certificate enrollment; ClearPass Onboard also supports EST (RFC 7030) and can act as a CA for third-party MDMs that use SCEP. Revocation status is then checked with OCSP. SNMP and DHCP are profiling inputs, not enrollment protocols.

③ Device Insight — AI that names every device on the wire

Guest handles people. Onboard handles employee phones. But what about the wireless printer, the smart TV in the boardroom, the badge reader, the security camera? They can't fill in a portal and can't run a wizard. ClearPass Device Insight is the cloud-hosted AI engine that discovers, profiles and classifies them — then tags them so policy can act.

It uses three signal types: active scans (it probes the device), passive telemetry (DHCP fingerprints, HTTP user-agent, deep-packet inspection), and machine learning that clusters devices with similar behaviour and builds new fingerprints over time. Crucially, when you run Onboard, the attributes Onboard collects during provisioning are handed straight to Device Insight.

Figure 3 — Device Insight pipeline. Many weak signals → one Collector → cloud ML → a tag → enforcement. The tag is the bridge between "what is it" and "what can it do".

Priya at HCL sees 40 "Unknown" devices flood the wireless. Device Insight clusters them by behaviour and identifies them as a fresh shipment of new IP cameras. She creates a tag "Brand-X-Camera", and her enforcement policy auto-drops anything with that tag onto an isolated IoT VLAN with no lateral access.

Pause & Predict

Priya tries to apply her "Brand-X-Camera" tag but it won't stick to 6 of the 40 devices. Predict why those 6 are the odd ones out.

Tags can only be applied to CLASSIFIED devices. Those 6 are still "Unknown/Unclassified" because the ML hasn't gathered enough behavioural signal yet (maybe they only just powered on, or sit quietly). Once Device Insight collects enough telemetry and classifies them, the tag — or an auto-tag rule — will apply. Don't force-tag unclassified endpoints.

Quick check · Q4 of 10

The ClearPass Collector service forwards consolidated device events to the Device Insight Analyzer. Which port does the Collector listen on?

a) TCP 6180 b) UDP 1812 c) TCP 443 only d) UDP 3799

Correct: a. The Collector listens on TCP 6180 to receive profile requests from Policy Manager services and forward them to the Analyzer. UDP 1812 is RADIUS auth, UDP 3799 is RADIUS CoA — both important elsewhere, but not the Collector port.

④ Troubleshoot — "BYOD won't connect" playbook

You onboarded a device, it got a cert, but EAP-TLS still fails. Here's the 4-step ladder that finds the cause in under two minutes — every step uses Access Tracker.

Figure 4 — The EAP-TLS fault ladder. Cert installed? Right service? Cert valid? Enforcement assigns a role? Each "No" maps to exactly one fix.

Access Tracker — what a healthy EAP-TLS hit looks like

Request  : 10.20.30.41  (Rahul-Pixel-8)
Service  : Techclick Secure 802.1X — EAP-TLS
Auth     : EAP-TLS  →  cert CN rahul@techclick.in  →  OCSP: good
Roles    : [Employee] [Onboarded-Device]
Enforce  : Employee-VLAN-30  (Allow)
Result   : ACCEPT

Expected — a REVOKED device looks like this

Request  : 10.20.30.41  (Rahul-Pixel-8)
Service  : Techclick Secure 802.1X — EAP-TLS
Auth     : EAP-TLS  →  cert CN rahul@techclick.in  →  OCSP: REVOKED
Result   : REJECT  (Reason: certificate revoked)
           ↳ exactly what you want after offboarding.

Common mistake — the symptom you'll actually see

Symptom: a newly-onboarded laptop connects to your test SSID but real users get "couldn't join network". Cause: the ClearPass server's RADIUS/EAP server certificate isn't trusted by the clients' supplicant. Devices you provisioned via Onboard trust it (the profile installed the chain); manually-configured devices don't. Fix: push the issuing CA into the device trust store, or always onboard through the wizard.

Common mistake — guest portal certificate

Symptom: visitors get a scary "connection not private" warning on the captive portal. Cause: a self-signed or wildcard cert on the portal. Fix: use a publicly-signed certificate whose CN matches the portal URL exactly — and that CN must not resolve to any A record in public DNS. Wildcards are not supported here.

Pro tips that save real outages

1. Set the Onboard device-cert validity sensibly (e.g. 365 days) and publish CRLs frequently or enable OCSP — stale revocation = a fired employee still online. 2. Scope Device Insight auto-tag rules tightly so a mis-classified laptop doesn't land on the IoT VLAN. 3. Keep MAC-caching lifetimes aligned to the visit type — 8h for day visitors, longer for contractors.

Security — patch ClearPass now (2025 advisories)

CVE-2025-23058 (broken access control → privilege escalation), CVE-2025-23059 / CVE-2025-23060 (info disclosure enabling man-in-the-middle) affect ClearPass Policy Manager 6.12.x ≤ 6.12.3 and 6.11.x ≤ 6.11.9. Upgrade to 6.12.4 or 6.11.10, put the management plane on a dedicated VLAN, and restrict admin access with firewall policy. Onboard is your network's certificate authority — it must run on a patched train.

Quick check · Q5 of 10

In Access Tracker, an onboarded device shows OCSP: REVOKED → REJECT. The help desk says "but the user's AD password still works on the VPN". What's going on?

a) ClearPass is broken — AD and Wi-Fi should always match b) OCSP only applies to guests c) The device needs a reboot d) The device certificate was revoked (so EAP-TLS fails), but that's independent of the AD password — revoking a cert doesn't disable the account

Correct: d. Certificate identity and password identity are separate. Revoking the Onboard cert kills EAP-TLS for that one device; the AD account can still log in elsewhere unless you also disable it. This separation is a feature — you can lock a lost phone without touching the user's account.

🤖 Ask the AI Tutor

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

Pre-curated from HPE Aruba TechDocs + Airheads community Q&A. For complex prod issues, paste your Access Tracker reject reason + Onboard CA settings into chat.techclick.in.

Figure 5 — Print this. Three pillars, four rows: who, how they authenticate, the key tech, and how you take access away.

🧠 Lock it in — explain it back

Self-explanation: in two sentences, write why a per-device certificate beats a shared Wi-Fi password for BYOD. (Typing it forces recall — this box is local-only, nothing is sent.)

Teach a friend: message a teammate one line — "ClearPass = Guest for visitors, Onboard for our phones (certs!), Device Insight to spot the IoT junk." If you can say it simply, you own it.

⏰ Remember this in 7 days

Want a one-question spaced-recall nudge in a week so this sticks? Drop your email — we'll send a single ClearPass refresher MCQ, nothing else.

📖 Glossary

BYOD: Bring Your Own Device — personal phones/laptops used on the corporate network.
EAP-TLS: Certificate-based 802.1X. Both client and server prove identity with X.509 certs inside a TLS tunnel — no password on the wire.
SCEP / EST: Simple Certificate Enrollment Protocol / Enrollment over Secure Transport (RFC 7030) — how a device asks a CA for a certificate during Onboard.
OCSP / CRL: Online Certificate Status Protocol / Certificate Revocation List — how ClearPass checks whether a presented cert has been revoked.
MAC caching: Remembering a guest's MAC after first portal login so reconnects skip the portal until the cached-role lifetime expires.
Captive portal: A forced web page where users log in or self-register before getting internet access.
Device Insight: Cloud-hosted AI engine that fingerprints, clusters and tags devices using active + passive signals and machine learning.

📚 Sources

HPE Aruba Networking TechDocs — The ClearPass Onboard Process & Editing Certificate Authority Settings. arubanetworking.hpe.com/techdocs
HPE Aruba Networking TechDocs — EAP-TLS (Policy Manager User Guide) & Guest Authentication with MAC Caching Service Template.
HPE Aruba Networking TechDocs — About Device Insight & ClearPass Profile Tech Note (Collector on TCP 6180, ML clustering, tags).
Airheads Community — How do I configure EAP-TLS (802.1x with Cert) on ClearPass; Flomain & Sonny Singh Brar — sponsored-guest self-registration walkthroughs.
HPE Security Bulletin — ClearPass Policy Manager CVE-2025-23058 / 23059 / 23060 (fixed in 6.12.4 / 6.11.10); SentinelOne CVE-2025-23060 advisory.
HPE Aruba Certification — Aruba Certified ClearPass Professional (ACCP) & ClearPass Associate (ACCA) blueprints + Study Guide.

What's next?

You can now get the right device onto the network with the right identity. Next we make it observable: Aruba Central Insights, the UXI sensor's synthetic tests, and live packet capture — so when "the Wi-Fi is slow" lands on your desk, you have evidence, not guesses.

Next · Aruba Troubleshooting & AIOps — Central Insights, UXI & Packet Capture → ← Recap ClearPass Policy Manager

ClearPass Guest, Onboard & Device Insight — BYOD, Certificates & Profiling, Watched Live

By the end you will be able to

Pick your path — jump straight to it

Guest Access

Onboard + Certs

Device Insight

Troubleshoot

Start here — the assumption that breaks every BYOD rollout

Quick warm-up — predict before you read

The four words you must own first

① Guest Access — let visitors in without letting them roam

▶ Watch a sponsored guest log in (then skip the portal)

② Onboard — how a BYOD phone earns a certificate

▶ Watch a device go from "unknown" to "EAP-TLS trusted"

③ Device Insight — AI that names every device on the wire

④ Troubleshoot — "BYOD won't connect" playbook

🤖 Ask the AI Tutor

📝 Wrap-up — five more

🧠 Lock it in — explain it back

⏰ Remember this in 7 days

📖 Glossary

📚 Sources

What's next?