Chapter 7: Switch Security: Authentication, Access Control, and Port Security

A campus switch is the front door of the enterprise network. Every printer, kiosk, IP phone, laptop, contractor tablet, and IoT camera plugs into it, and once a frame is forwarded the rest of the network has to trust the sender. The HPE Aruba Networking Switching Associate (HPE7-A01) exam expects you to treat that front door like a security checkpoint: authenticate the user or device, hand it a role that says what it is allowed to do, enforce that role with ACLs and Classifier policies, and finally lock the management plane so no attacker can simply log into the switch and erase the rules.

Think of the switch as the lobby of a corporate building. The 802.1X handshake is the security guard checking your badge. The user role is the visitor sticker that says which floors you can ride to. The ACL is the elevator's card reader that enforces it. And the management plane hardening is the locked supply closet behind reception where the building blueprints live.

Port-based authentication means the switch refuses to forward user traffic on an access port until the connecting device proves who it is. AOS-CX implements this with the port-access framework, which unifies 802.1X, MAC authentication, and captive portal under a single authenticator state machine.

7.1.1 The 802.1X EAP Flow

802.1X is an IEEE standard that wraps the Extensible Authentication Protocol (EAP) inside Layer-2 frames called EAPOL (EAP over LAN). Three actors are involved:

• Supplicant — the client, typically the OS-native 802.1X service on a laptop or phone.
• Authenticator — the AOS-CX switch port. It is the gatekeeper: it relays EAP between the supplicant and the RADIUS server but does not itself decide whether the user is allowed in.
• Authentication Server — the RADIUS server, almost always Aruba ClearPass Policy Manager in HPE designs.

The handshake follows a strict sequence. The supplicant or the switch sends an EAPOL-Start. The switch replies with an EAP-Request/Identity. The supplicant returns its identity, which the switch encapsulates inside RADIUS Access-Request and forwards to ClearPass. ClearPass and the supplicant then negotiate an inner EAP method — EAP-TLS (certificates), PEAP-MSCHAPv2 (AD password inside a TLS tunnel), or EAP-TTLS. When ClearPass is satisfied it returns a RADIUS Access-Accept that may include vendor-specific attributes (VSAs) such as the Aruba user role or a VLAN ID, and the switch finally moves the port from the unauthenticated to the authorized state.

A minimal AOS-CX configuration:

radius-server host 10.10.0.105 key plaintext aruba123 vrf mgmt
aaa authentication port-access dot1x authenticator
vlan 10
port-access role LUR
   vlan access 10
interface 1/1/1
   no shutdown
   no routing
   vlan access 1
   aaa authentication port-access dot1x authenticator
      enable

The vrf mgmt qualifier sends authentication traffic out the dedicated out-of-band management VRF. The port-access role LUR block defines a Local User Role pinned to VLAN 10. When ClearPass returns its own role via the Aruba VSA, the local role is overridden and the CLI suffixes the role name with an asterisk (e.g., test_LUR*) to flag the RADIUS override.

7.1.2 MAC Authentication as Fallback

Devices without supplicants — printers, badge readers, IP cameras — can authenticate via MAC-Auth (also called MAB). The switch sends the MAC as both username and password to RADIUS. Production deployments combine 802.1X and MAC-Auth on the same port: dot1x first, then MAC-Auth on timeout/failure.

7.1.3 Multi-Domain and Multi-Host Modes

7.1.4 Captive Portal Integration

For guests, AOS-CX integrates with ClearPass Guest via a redirect role. The unknown MAC is MAC-Auth'd, ClearPass returns a "guest-redirect" role (limited reachability + redirect URL), the user registers/logs in via the portal, then ClearPass issues a Change-of-Authorization (CoA) over RADIUS dynamic authorization to upgrade the session to a "guest-authorized" role. CoA requires radius dyn-authorization enable on the switch.

Authentication tells the switch who connected. Authorization tells it what they can do. AOS-CX expresses authorization with roles — named policies bundling VLAN, ACLs, QoS, captive-portal redirect, session timeout, and reauthentication interval.

7.2.1 Local User Roles (LUR)

A Local User Role lives in the switch's running configuration. It is defined once with port-access role <name> and referenced either by local fallback config or by the name returned in a RADIUS VSA.

port-access role employee-data
   vlan access 100
   reauth-period 3600
   session-timeout 28800
   auth-mode client-mode

LURs are perfect for small deployments and as fallback when ClearPass is unreachable. The drawback is sprawl: every change touches every switch.

7.2.2 Downloadable User Roles (DUR)

A DUR is defined entirely in ClearPass and pulled to the switch on demand over HTTPS/REST after authentication. The switch caches it in volatile memory; reboot or policy update clears it. Three switch-side prerequisites:

1. Trust Anchor (TA) profile for ClearPass HTTPS — the switch validates ClearPass's certificate before downloading any role.
2. A read-only ClearPass admin account dedicated to DUR (configured via radius-server clearpass username/password).
3. HTTPS reachability from the switch's source VRF to ClearPass on TCP/443.

7.2.3 Device Profiles via LLDP

A device profile watches LLDP TLVs and applies a pre-built role when a match is found, before any authentication is attempted. This solves the chicken-and-egg problem of provisioning APs and IoT gateways on locked-down ports.

port-access lldp-group aruba-ap
   match sys-desc Aruba

port-access device-profile aps
   associate role ap-role
   associate lldp-group aruba-ap
   enable

Roles describe intent; ACLs and classifier policies enforce it in hardware. AOS-CX ACLs are stateless: each packet is evaluated independently against the ACE list, top-down, first-match-wins, with an implicit deny any at the end of every list. ACLs are programmed into TCAM and run at wire speed; the trade-off is no payload inspection or app-layer filtering.

7.3.1 Standard vs Extended ACLs

AOS-CX collapses the standard/extended distinction: every ACL is a named list whose ACE syntax matches any L3/L4 fields.

access-list ip BLOCK-RFC1918
   10 deny ip 10.0.0.0/8 any
   20 deny ip 172.16.0.0/12 any
   30 deny ip 192.168.0.0/16 any
   40 permit ip any any

7.3.2 Stateless First-Match-Wins Evaluation

Return traffic must be permitted explicitly (e.g. permit tcp any eq 443 any established). The "first-match-wins" rule rewards careful ordering: a permissive permit ip any any placed too early will silently bypass every later deny.

7.3.3 Classifier Policies (class-map + policy-map)

A classifier policy can do more than permit/deny — it can mark DSCP, rate-limit, mirror, or redirect.

class ip web-traffic
   10 match tcp any any eq 80
   20 match tcp any any eq 443

policy CAMPUS-QOS
   10 class ip voice-traffic action dscp ef
   20 class ip web-traffic action dscp af31
   30 class ip any action dscp default

7.3.4 Where to Apply ACLs

7.3.5 Hit-Count Verification

The single most useful troubleshooting command for "is my ACL even matching?" is:

show access-list hit-counts ip BLOCK-RFC1918

A line that should be matching but shows zero hits is an instant flag — either the traffic is not arriving where you think it is, or an earlier ACE is catching it.

An attacker who reaches the management plane does not need to evade ACLs — they can simply rewrite them. Hardening the management plane is therefore a security multiplier for everything else in this chapter.

7.4.1 SSH Key-Based Authentication

ssh server vrf mgmt
ssh password-authentication disable
user admin authorized-key "ssh-ed25519 AAAAC3Nz...comment"

Restrict the management VRF and bind SSH to it. The data VRF (default) should not run an SSH listener unless a deliberate exception is documented.

7.4.2 HTTPS Certificates

Replace the self-signed cert with one signed by your enterprise CA. A typical workflow uses crypto pki ta-profile to trust your enterprise root, generates a CSR from the switch, has your CA sign it, and installs the signed cert as the HTTPS server certificate.

7.4.3 AAA TACACS+ for Admin Login

tacacs-server host 10.10.0.110 key plaintext tacacs123 vrf mgmt
aaa authentication login default group tacacs local
aaa authorization commands default group tacacs local
aaa accounting all default start-stop group tacacs

The local fallback is critical: if the TACACS+ server is unreachable, the switch falls back to local authentication. Without it, a TACACS+ outage locks every administrator out of every switch — exactly when you most need to log in.

7.4.4 Audit Logging

logging 10.10.0.120 vrf mgmt severity info
logging 10.10.0.120 vrf mgmt include-auditable-events

include-auditable-events captures CLI commands, login attempts (success and failure), AAA decisions, and configuration changes. Combined with TACACS+ accounting (which records every command typed), this gives a tamper-evident trail.

Figure 7.4: Management Plane Hardening Layers

Switch security on AOS-CX is a layered story that follows the packet from the edge inward. At the access port, 802.1X authenticates the user via EAP between supplicant, authenticator (the switch), and ClearPass; MAC authentication handles supplicant-less devices as a fallback; multi-domain mode lets a single port serve a phone and a PC under independent identities. Once authenticated, the client receives a role — a Local User Role stored on the switch, a Downloadable User Role pulled from ClearPass on demand, or a device profile matched on LLDP — that pins the session to a VLAN with associated ACLs and session timers. ACLs and classifier policies enforce the role's intent in TCAM at wire speed. Above all of this sits the management plane, hardened with SSH key auth, signed HTTPS certs, TACACS+ with per-command authorization and local fallback, and centralized syslog with auditable-event capture.

The exam expects you to recognize the CLI shape of each piece, know which command goes in which context, and understand which mechanism solves which problem — 802.1X for who, role for what, ACL for enforcement, TACACS+ for admin accountability.