10.3 MAC Authentication and Captive Portal Onboarding

MAC Authentication and Captive Portal Onboarding

Quick Summary: Enterprise campus networks must accommodate thousands of devices that cannot run an 802.1X supplicant. MAC Authentication (MAC-Auth) addresses headless Internet of Things (IoT) devices—printers, IP cameras, medical sensors, and badge readers—by having the switch act as a proxy, querying ClearPass using the client's Layer 2 MAC address. Because MAC addresses lack cryptographic integrity and can be spoofed, ClearPass augments MAC-Auth with device profiling (DHCP fingerprinting, LLDP/CDP, and HTTP telemetry). For human guests and unmanaged contractor laptops, Captive Portal intercepts web traffic, presents an onboarding portal for self-registration or employee sponsorship, and dynamically upgrades network privileges using RADIUS Change of Authorization (CoA).

---

The Headless Device Challenge in Enterprise Networks

While corporate laptops and smartphones natively execute 802.1X supplicant software, modern campus facilities host vast fleets of embedded, specialized endpoints:

• Building Automation: Smart LED lighting controllers, HVAC thermostats, badge readers, physical door locks.
• Surveillance and Media: IP security cameras, digital signage displays, conference room audio/video bars.
• Enterprise Peripherals: Networked multi-function printers, label makers, desktop VoIP phones.
• Healthcare and Industrial: Patient telemetry pumps, barcode scanners, PLC controllers.

These endpoints lack interactive graphical user interfaces, full operating systems, or 802.1X client stacks. Disabling switch port security to accommodate them compromises campus integrity. MAC Authentication (MAC-Auth)—known broadly in the networking industry as MAC Authentication Bypass (MAB)—provides a transparent admission mechanism.

---

MAC Authentication Operational Mechanics

In MAC-Auth, the client endpoint performs no authentication signaling whatsoever. It simply powers up, establishes physical link, and transmits standard Ethernet frames (such as a DHCP Discover or ARP request). The AOS-CX switch acts as an authentication proxy:

+---------------------------------------------------------------------------------------------------------+
|                                      MAC AUTHENTICATION TRANSACTION FLOW                                |
|                                                                                                         |
|     [ Headless Device ]            [ AOS-CX Switch (Proxy) ]              [ ClearPass Policy Manager ]   |
|        (IP Camera)                          |                                          |                |
|             | --- Standard Traffic (ARP) --> |                                          |                |
|             |     (Src: 00:09:b0:12:34:56)   |                                          |                |
|             |                                | --- RADIUS Access-Request -------------> |                |
|             |                                |     User-Name: 0009b0123456              |                |
|             |                                |     User-Password: 0009b0123456          |                |
|             |                                |     Calling-Station-Id: 0009b0123456     |                |
|             |                                |                                          |                |
|             |                                |                                          +-- Checks DB    |
|             |                                |                                          +-- Evaluates    |
|             |                                | <--- RADIUS Access-Accept -------------+     Profiling    |
|             |                                |      Aruba-User-Role: CAMERAS_ROLE       |                |
|             |                                |                                          |                |
|             |                                +-- Applies Role & VLAN to Port 1/1/5      |                |
|             | <=== Permitted Data Traffic == |                                          |                |
+---------------------------------------------------------------------------------------------------------+

Step-by-Step MAC-Auth Execution

1. Link Detection and Frame Ingress: The headless endpoint connects to port 1/1/5. The switch detects link-up and listens for the initial Layer 2 frame. It extracts the client's 48-bit source MAC address (00:09:B0:12:34:56).
2. RADIUS Proxy Generation: The switch formats a standard RADIUS Access-Request packet:
   • User-Name = Client MAC address (configurable format: lowercase, uppercase, with or without colons/hyphens; e.g., 0009b0123456).
   • User-Password = Client MAC address (hashed with the RADIUS shared secret).
   • Service-Type = Call-Check (Attribute 6, value 10), alerting ClearPass that this is an automated MAC authentication check rather than a human interactive login.
   • Calling-Station-Id = 00-09-B0-12-34-56 (Client MAC).
   • NAS-Port-Id = Physical port string (1/1/5).
3. ClearPass Policy Evaluation: ClearPass receives the request and searches its local identity stores:
   • Endpoints Repository: Database of known, profiled MAC addresses.
   • Guest Device Database: Devices pre-registered by guests or employees through the ClearPass Guest portal.
   • Static Host Lists: Manually maintained lists of approved hardware MAC addresses.
4. Enforcement and Policy Response: If the MAC address is recognized and authorized, ClearPass returns a RADIUS Access-Accept containing the Aruba-User-Role (e.g., CAMERAS_ROLE). The switch applies the role and opens the controlled port.

---

MAC Spoofing Risks and ClearPass Profiling Defenses

MAC Authentication possesses a severe, inherent vulnerability: MAC addresses are entirely unencrypted and easily forged.

The Spoofing Threat

Ethernet frames broadcast source MAC addresses across the local LAN in cleartext. A malicious actor with a laptop can disconnect an authorized multi-function printer, run a packet analyzer or read the MAC address printed on the physical asset tag, and use standard operating system commands to clone that MAC address onto their own network interface card (macchanger -m 00:09:B0:12:34:56 eth0). When the attacker plugs into the switch port, the switch initiates MAC-Auth, ClearPass sees the authorized printer MAC, and the attacker is granted admission to the corporate network.

+---------------------------------------------------------------------------------------------------------+
|                                 CLEARPASS MULTI-FACTOR DEVICE PROFILING                                 |
|                                                                                                         |
|     [ Ingress Device ]                                                                                  |
|     (Asserts Printer MAC)                                                                               |
|             |                                                                                           |
|             +---> 1. DHCP SNOOPING TELEMETRY ----> Option 55 (Parameter Request List) & Option 60       |
|             |                                      (Reveals underlying OS fingerprint)                  |
|             +---> 2. LLDP / CDP NEIGHBOR DATA ---> System Description: "Axis M3045 Network Camera"     |
|             |                                      (Contradicts printer MAC assertion!)                 |
|             +---> 3. HTTP USER-AGENT SNOOPING ---> Web Client Header: "Mozilla/5.0 (Windows NT 10.0)"   |
|             |                                      (Identifies attacker's true OS)                      |
|             v                                                                                           |
|     [ ClearPass Profiler Engine ] ========> MISMATCH DETECTED!                                          |
|                                            MAC = Printer, but OS = Windows 10 Laptop!                   |
|                                            ACTION: CoA Disconnect / Quarantine Port!                    |
+---------------------------------------------------------------------------------------------------------+

Multi-Factor Profiling Telemetry

To defeat MAC spoofing, enterprise architectures combine MAC-Auth with Aruba ClearPass Device Profiling. ClearPass ingests multiple contextual data feeds to construct a multidimensional fingerprint of the connected device:

• DHCP Fingerprinting: When an endpoint requests an IP address, the access switch snoops the DHCP Discover/Request and relays telemetry to ClearPass. ClearPass evaluates DHCP Option 55 (Parameter Request List) and Option 60 (Vendor Class Identifier). A genuine Hewlett Packard LaserJet printer requests vastly different DHCP options in a different sequence than a Windows 10 laptop or Linux workstation.
• LLDP and CDP Snooping: Managed endpoints advertise capabilities via Link Layer Discovery Protocol (LLDP). The switch collects LLDP TLVs (such as System Description and System Capabilities) and relays them to ClearPass via RADIUS accounting or streaming APIs.
• HTTP User-Agent Snooping: When the device initiates outbound web traffic, web proxy or switch telemetry captures the User-Agent string, confirming the exact browser or embedded client runtime.
• Automated Quarantine via CoA: If a device authenticates with an approved printer MAC address, but its DHCP fingerprint reveals a Linux kernel or Windows desktop, ClearPass detects the anomaly. It immediately fires an automated RADIUS Change of Authorization (CoA) packet to the switch, terminating the session or pushing a quarantine role.

---

Authentication Sequencing: Fallback vs. Concurrent

Because campus switch ports serve diverse devices, network engineers must configure ports to handle both 802.1X-capable laptops and headless IoT devices. AOS-CX switches support two operational paradigms:

+---------------------------------------------------------------------------------------------------------+
|                                   SEQUENTIAL FALLBACK VS. CONCURRENT AUTH                               |
|                                                                                                         |
|     [ SEQUENTIAL FALLBACK ] (Legacy / Default)                                                          |
|     Port Link Up ----> 802.1X Starts ----> Waits for Timeout (30s) ----> Falls back to MAC-Auth         |
|                        (Printers and cameras endure a 30-second connectivity delay!)                    |
|                                                                                                         |
|     [ CONCURRENT AUTHENTICATION ] (High-Performance Modern Enterprise)                                  |
|     Port Link Up ----+---> 802.1X Starts (EAPOL-Request) -----------------------------------------------+|
|                      +---> MAC-Auth Starts (RADIUS Access-Request) -----------------------------+||     |
|                      (Printers authenticate in milliseconds; Laptops prioritize 802.1X roles!)   vv     |
+---------------------------------------------------------------------------------------------------------+

1. Sequential Fallback (802.1X with MAC-Auth Fallback)

Under sequential fallback, the switch prioritizes 802.1X. Upon physical link-up, the switch transmits EAP-Request/Identity frames, repeating them every discovery-period up to max-eapol-requests. If no EAPOL response arrives, the switch concludes the device lacks a supplicant, times out 802.1X, and initiates MAC-Auth. While secure, this creates an operational penalty: headless IoT devices experience a 20-to-30 second onboarding delay before network communication begins.

2. Concurrent Onboarding (port-access onboarding-method concurrent enable)

AOS-CX switches overcome this delay with concurrent onboarding. When a device connects, the switch starts 802.1X and MAC-Auth at the same time (AOS-CX 10.14 CLI Guide). The client sits in the pre-auth role until one method succeeds or all fail; if all fail, the reject or critical role is applied based on the 802.1X failure reason:

• For a printer: The switch transmits an EAPOL request while simultaneously dispatching a RADIUS MAC-Auth request. The printer ignores EAPOL, but the MAC-Auth transaction completes in under 200 milliseconds, granting instant access.
• For a corporate laptop: Both methods trigger. The default priority is 802.1X, then MAC-Auth, then device profile, so the 802.1X result takes precedence when it completes.
• Caution: some RADIUS servers block a client that sends two requests at once. If that happens, use aaa authentication port-access auth-precedence with auth-priority instead of concurrent onboarding.

---

Captive Portal and Web-Based Onboarding

For visitor guests, vendors, and unmanaged contractor laptops, neither 802.1X corporate credentials nor pre-registered MAC addresses are available. Captive Portal onboarding provides a browser-based admission workflow:

+---------------------------------------------------------------------------------------------------------+
|                                     CAPTIVE PORTAL ONBOARDING WORKFLOW                                  |
|                                                                                                         |
|     [ Guest Client ]                  [ AOS-CX Switch ]                 [ ClearPass Guest Portal ]      |
|            |                                  |                                      |                  |
|            | --- 1. Connects to Port --------> |                                      |                  |
|            |                                  +-- Assigns "GUEST_LOGON" Role         |                  |
|            |                                      (Permits DNS/DHCP; Redirects HTTP) |                  |
|            |                                  |                                      |                  |
|            | --- 2. HTTP Request (cnn.com) -> |                                      |                  |
|            | <== 3. HTTP 302 Redirect ========+ (Location: https://cppm.corp/guest)  |                  |
|            |                                                                         |                  |
|            | --- 4. Opens Browser to Portal ---------------------------------------> |                  |
|            | <== 5. Renders Self-Registration / Sponsor Form ======================= |                  |
|            |                                                                         |                  |
|            | --- 6. Submits Registration / Guest Accepts Terms --------------------> |                  |
|            |                                                                         +-- Approves Guest |
|            |                                  | <--- 7. RADIUS CoA (RFC 3576) -------+                  |
|            |                                  |      Switch transitions client to                       |
|            |                                  |      "GUEST_INTERNET" Role                              |
|            | <=== 8. Unrestricted Internet == |                                                         |
+---------------------------------------------------------------------------------------------------------+

The Redirection Lifecycle and Dynamic Role Transitions

1. Initial Unauthenticated State: The guest connects. MAC-Auth triggers and fails (or assigns a default initial role: GUEST_LOGON).
2. The Redirection ACL: The GUEST_LOGON role contains a captive portal profile and ACL rules:
   • Permitted Traffic: UDP port 67/68 (DHCP) and UDP port 53 (DNS). If DNS is blocked, the client cannot resolve domain names, and redirection completely fails!
   • Intercepted Traffic: TCP port 80 (HTTP) and TCP port 443 (HTTPS). When the guest browser attempts to reach an external website, the switch intercepts the TCP handshake and responds with an HTTP 302 Temporary Redirect pointing to the ClearPass Guest portal URL.
3. Portal Interaction and Sponsorship: The guest browser navigates to ClearPass Guest. Options include:
   • Self-Registration: Guest enters name, email, and mobile number. ClearPass generates temporary credentials delivered via SMS.
   • Sponsor Approval: Guest enters the email of an internal employee. ClearPass emails the employee an approval link. Internet access remains suspended until the sponsor clicks "Approve".
4. RADIUS Change of Authorization (CoA): Once authenticated, ClearPass must update the client's state without requiring the user to unplug the Ethernet cable or bounce the switch port. ClearPass transmits an asynchronous RADIUS CoA message (RFC 3576 / 5176) to the switch:
   • The CoA instructs the switch to transition the client from GUEST_LOGON to GUEST_INTERNET.
   • The switch updates hardware forwarding tables, removing redirection ACLs and applying outbound Internet routing policies.

---

AOS-CX Configuration Commands and Verification

The following configuration demonstrates configuring MAC-Auth, enabling concurrent authentication, and establishing a captive portal redirect profile:

switch# configure terminal

! Step 1: Configure RADIUS Server and Enable Dynamic Authorization (CoA)
switch(config)# radius-server host 10.10.100.50 key plaintext SecretRadiusKey123
switch(config)# radius dyn-authorization enable
switch(config)# radius dyn-authorization client 10.10.100.50 secret-key plaintext SecretRadiusKey123

! Step 2: Define Captive Portal Redirect Profile
switch(config)# aaa authentication port-access captive-portal-profile CPPM_GUEST_PORTAL
switch(config-captive-portal)# url https://clearpass.corp.example.com/guest/guest_login.php
switch(config-captive-portal)# exit

! Step 3: Define Roles for Initial Logon and Post-Auth Internet
switch(config)# port-access role GUEST_LOGON_ROLE
switch(config-pa-role)# captive-portal-profile CPPM_GUEST_PORTAL
switch(config-pa-role)# vlan access 100
switch(config-pa-role)# exit

switch(config)# port-access role GUEST_AUTH_ROLE
switch(config-pa-role)# vlan access 100
switch(config-pa-role)# exit

! Step 4: Configure Port 1/1/2 for concurrent 802.1X and MAC-Auth
switch(config)# aaa authentication port-access mac-auth enable
switch(config)# interface 1/1/2
switch(config-if)# no routing
switch(config-if)# vlan access 1
switch(config-if)# aaa authentication port-access client-limit 4
switch(config-if)# aaa authentication port-access dot1x authenticator enable
switch(config-if)# aaa authentication port-access mac-auth enable
switch(config-if)# port-access onboarding-method concurrent enable
switch(config-if)# exit

Essential Verification Commands

---

Common Exam Traps

• MAC-Auth Security Assumption: An exam question might suggest MAC-Auth provides strong identity verification for IoT devices. MAC-Auth provides no cryptographic verification; it is purely an identity check based on cleartext Layer 2 addresses and requires ClearPass profiling to mitigate spoofing.
• Blocking DNS in Captive Portal: If a captive portal redirection ACL blocks UDP port 53 (DNS), the client will be unable to resolve the hostname of the ClearPass portal (or initial destination websites), completely breaking redirection.
• Forgetting dynamic authorization: If radius dyn-authorization enable and a matching radius dyn-authorization client are missing, the switch will not accept RADIUS CoA messages from ClearPass, so guests stay in the onboarding role after a successful login.