802.1X Port-Based Authentication — RADIUS Server, Host-Mode & Supplicant Verification

Plugging a device into a switch port has historically meant immediate network access — the device gets a DHCP address and starts communicating before any identity has been verified. In a campus with hundreds of switch ports across office floors, server rooms, and conference rooms, this creates a significant attack surface: a rogue laptop, an unauthorised visitor, or a compromised IoT device plugged into any accessible port gains full LAN access instantly. IEEE 802.1X port-based network access control (PNAC) closes this gap by making the switch port itself the enforcement point — no traffic is permitted until the connected device (the supplicant) presents valid credentials to an authentication server.

The 802.1X framework uses a three-party model. The supplicant is the end device (laptop, IP phone, printer) running an EAP client. The authenticator is the Cisco switch — it intercepts EAP messages from the supplicant, relays them to the authentication server using RADIUS, and enforces the access decision by opening or blocking the port. The authentication server is the RADIUS server (Cisco ISE, FreeRADIUS, or Microsoft NPS) — it validates credentials, applies policy, and returns an Access-Accept or Access-Reject. The switch has no knowledge of the credentials themselves — it only sees whether the server granted or denied access.

This lab configures 802.1X end-to-end: RADIUS server definition, global 802.1X enabling, per-port authentication, host-mode selection, fallback options (guest VLAN, auth-fail VLAN, critical VLAN), and complete verification. For the AAA framework that underpins 802.1X see AAA Configuration and AAA Overview. For VLAN infrastructure see VLANs and VLAN Creation & Management. For the storm protection that should accompany access port security see Storm Control & Traffic Shaping. For Control Plane Policing that protects the switch's own management plane see CoPP Configuration.

1. Core Concepts — 802.1X Framework, EAP, and Port States

The Three-Party 802.1X Model

  ┌──────────────┐   EAP over LAN (EAPOL)   ┌──────────────┐  RADIUS (UDP 1812/1813)  ┌────────────────┐
  │  SUPPLICANT  │ ◄──────────────────────► │AUTHENTICATOR │ ◄──────────────────────► │  AUTH SERVER   │
  │  (End Host)  │                           │  (Switch)    │                           │ (RADIUS/ISE)   │
  │              │                           │              │                           │                │
  │ 802.1X client│                           │ Gi0/1 port   │                           │ 10.0.0.100     │
  │ EAP method   │                           │ Controls     │                           │ User DB        │
  │ credentials  │                           │ port state   │                           │ Policy engine  │
  └──────────────┘                           └──────────────┘                           └────────────────┘

  FLOW SUMMARY:
  1. Device plugs in → Switch sends EAP-Request/Identity to supplicant
  2. Supplicant replies with EAP-Response/Identity (username)
  3. Switch encapsulates EAP in RADIUS Access-Request → sends to server
  4. Server challenges supplicant (e.g., sends EAP-TLS certificate request)
  5. Supplicant responds with credentials (password, certificate, etc.)
  6. Server validates → returns RADIUS Access-Accept or Access-Reject
  7. Switch opens port (Authorized) or keeps blocked (Unauthorized)
  8. (Optional) Server returns VLAN assignment in Access-Accept attributes

802.1X Port States

State	Traffic Permitted	When It Occurs
Unauthorized	EAPOL only (EAP authentication packets). All other traffic dropped.	Default state when device connects. Port remains here until authentication succeeds.
Authorized	All traffic permitted (subject to normal VLAN/ACL policy).	RADIUS returns Access-Accept. Port opens and may be assigned a specific VLAN.
Guest VLAN	Traffic on the configured Guest VLAN only.	No EAP response received from connected device (non-802.1X capable). Device gets limited network access.
Auth-Fail VLAN	Traffic on the configured Auth-Fail VLAN only.	Supplicant responded but authentication failed (wrong credentials). Restricted access — e.g., remediation network.
Critical VLAN	Traffic on the configured Critical (inaccessible auth bypass) VLAN.	All RADIUS servers are unreachable. Device gets access so work is not interrupted — used for servers and critical endpoints.

EAP Methods Comparison

EAP Method	Credentials Used	Server Certificate	Client Certificate	Security Level	Common Use Case
EAP-MD5	Username + password	No	No	Low — vulnerable to offline dictionary attacks	Legacy / lab only
PEAP (MSCHAPv2)	Username + password inside TLS tunnel	Yes (server)	No	High — password protected by TLS tunnel	Enterprise users with AD credentials
EAP-TLS	Digital certificates (mutual)	Yes (server)	Yes (client)	Highest — certificate-based, no password	Corporate devices, PKI environments
EAP-FAST	Password or certificate inside PAC tunnel	Optional	No	High	Cisco environments without full PKI
EAP-TTLS	Any inner method inside TLS tunnel	Yes (server)	No	High	Multi-vendor environments

Authentication Host-Mode Options

Host-Mode	Devices Allowed	Typical Use	Behaviour
single-host	1 authenticated device	Simple access port — one PC	First device authenticates; additional MACs on the port are blocked. Most restrictive.
multi-host	Multiple devices, but only 1 authentication	PC behind a hub or unmanaged switch	One device authenticates; all other devices on the same port get free access using the authenticated state. Least secure — once one device authenticates, others ride along.
multi-auth	Multiple devices, each individually authenticated	Multiple PCs on a hub, or IP phone + PC	Each MAC address must independently authenticate. Most granular control. Separate RADIUS sessions per device.
multi-domain	2 devices: 1 in data domain, 1 in voice domain	IP phone + PC on the same port	Dedicated support for IP phone + PC co-location. Phone authenticates in the voice domain (Voice VLAN), PC authenticates in the data domain. Each gets its own RADIUS session and VLAN assignment.

MAB — MAC Authentication Bypass: Not all devices support 802.1X supplicants — printers, IP cameras, and IoT sensors often cannot run EAP clients. MAB allows these devices to authenticate using their MAC address as both the username and password in a RADIUS request. The switch sends the device's MAC address to the RADIUS server, which checks it against a whitelist. MAB is significantly weaker than 802.1X (MAC addresses can be spoofed) but is the standard fallback for non-supplicant devices in enterprise 802.1X deployments. The switch tries 802.1X first, falls back to MAB after the timeout, and falls back further to the guest VLAN if MAB also fails. See also MAC Addresses and MAC Address Table.

2. Lab Topology

                        ┌──────────────────────────────────────────┐
                        │         NetsTuts_SW1 (Catalyst 3560)     │
                        │                                          │
                        │  Gi0/0 ── Uplink to Core (Trunk)        │
                        │                                          │
                        │  Gi0/1 ── PC-A       (802.1X - single-host)   │
                        │  Gi0/2 ── PC-B       (802.1X - multi-auth)    │
                        │  Gi0/3 ── IP Phone   (802.1X - multi-domain)  │
                        │  Gi0/4 ── Printer    (MAB - no supplicant)     │
                        │  Gi0/5 ── Lobby PC   (Guest VLAN fallback)     │
                        │  Gi0/6 ── Server     (Critical VLAN bypass)    │
                        │                                          │
                        │  Gi0/24 ── RADIUS server (10.0.0.100)  │
                        └──────────────────────────────────────────┘

  VLANs:
    VLAN 10 — Corporate Data (authenticated employees)
    VLAN 20 — Voice (IP phones)
    VLAN 30 — Guest (non-802.1X devices, unauthenticated)
    VLAN 40 — Remediation / Auth-Fail (failed auth)
    VLAN 50 — Critical (RADIUS server unreachable)
    VLAN 99 — Management

  RADIUS Server: 10.0.0.100
    Shared secret: NetsTuts-RADIUS-Key
    Auth port: 1812, Accounting port: 1813

3. Step 1 — AAA Framework and RADIUS Server Configuration

802.1X authentication on Cisco switches is built on top of the AAA (Authentication, Authorisation, Accounting) framework. Before any 802.1X commands will work, AAA must be enabled and a RADIUS server group must be defined. The switch uses AAA to determine which server to send RADIUS requests to and how to fall back if that server is unreachable. See AAA Overview, AAA Authentication Methods, and the detailed step-by-step AAA RADIUS Configuration lab for background. is unreachable.

Enable AAA and Define RADIUS Server

! ── Step 1: Enable AAA globally ──────────────────────────────────
NetsTuts_SW1(config)#aaa new-model
!                    ^^^^^^^^^^^
!    CRITICAL: Without this, no AAA methods work — 802.1X will not
!    authenticate against RADIUS. This command also disables any
!    default line-based authentication — ensure console access is
!    still secured (aaa authentication login default local) before
!    enabling in production.

! ── Step 2: Define the RADIUS server (modern IOS 15.x method) ────
NetsTuts_SW1(config)#radius server NETSTUTS-ISE
!                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    Named server configuration block

NetsTuts_SW1(config-radius-server)#address ipv4 10.0.0.100
!                                  ^^^^^^^^^^^^^^^^^^^^^^
!    RADIUS server IP address

NetsTuts_SW1(config-radius-server)#key NetsTuts-RADIUS-Key
!                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    Shared secret — must match EXACTLY on the RADIUS server
!    Case-sensitive; spaces allowed if quoted

NetsTuts_SW1(config-radius-server)#auth-port 1812
NetsTuts_SW1(config-radius-server)#acct-port 1813
!                                   ^^^^^^^^^ ^^^^
!    Standard RADIUS ports — 1812 auth, 1813 accounting
!    (Legacy: 1645 auth / 1646 accounting — avoid on new deployments)

NetsTuts_SW1(config-radius-server)#exit

! ── Step 3: Create a RADIUS server group ─────────────────────────
NetsTuts_SW1(config)#aaa group server radius NETSTUTS-RADIUS-GROUP
NetsTuts_SW1(config-sg-radius)#server name NETSTUTS-ISE
!                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    Add the named server to the group
NetsTuts_SW1(config-sg-radius)#exit

! ── Legacy method (older IOS — shown for reference) ──────────────
! NetsTuts_SW1(config)#radius-server host 10.0.0.100 key NetsTuts-RADIUS-Key
! ← Deprecated in IOS 15.x — use 'radius server' named blocks instead

! ── Step 4: Configure AAA authentication for 802.1X ──────────────
NetsTuts_SW1(config)#aaa authentication dot1x default group NETSTUTS-RADIUS-GROUP
!                                        ^^^^^^
!                                   Method list name 'default' applies to all
!                                   802.1X-enabled ports unless overridden

! ── Step 5: Configure AAA authorisation for network access ────────
NetsTuts_SW1(config)#aaa authorization network default group NETSTUTS-RADIUS-GROUP
!                                            ^^^^^^^
!                              Network authorisation — allows RADIUS to return
!                              VLAN, ACL, and session policy via CoA attributes

! ── Step 6: Configure AAA accounting (optional but recommended) ───
NetsTuts_SW1(config)#aaa accounting dot1x default start-stop group NETSTUTS-RADIUS-GROUP
!                                                  ^^^^^^^^^^
!                              start-stop: sends accounting record when
!                              session starts and when it ends
!                              Records: username, session duration, bytes in/out

! ── Verify RADIUS server reachability ────────────────────────────
NetsTuts_SW1#test aaa group NETSTUTS-RADIUS-GROUP testuser testpassword new-code
!                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^^^^^
!            Group name                             username  password
! Expected: Attempting authentication test to server-group NETSTUTS-RADIUS-GROUP
!           User authentication request sent ... User was successfully authenticated.

RADIUS Source Interface and Timeout Tuning

! ── Set source interface for RADIUS packets ───────────────────────
NetsTuts_SW1(config)#ip radius source-interface Vlan99
!                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    RADIUS requests originate from VLAN 99 management interface
!    Ensures consistent source IP regardless of routing changes
!    RADIUS server whitelist must include this IP

! ── Tune RADIUS timeouts and retransmit ──────────────────────────
NetsTuts_SW1(config)#radius-server timeout 5
!                    ^^^^^^^^^^^^^^^^^^^^^^^^
!    Wait 5 seconds for RADIUS response before retrying (default: 5)

NetsTuts_SW1(config)#radius-server retransmit 2
!                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    Retry RADIUS request 2 times before declaring server dead (default: 3)

NetsTuts_SW1(config)#radius-server deadtime 15
!                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    Mark server as dead for 15 minutes after repeated failures
!    During deadtime, switch does not send requests to this server
!    (prevents authentication delays when RADIUS is truly unreachable)

The source interface setting is critical in production. If the switch sends RADIUS packets from different source IPs (depending on which interface routes the packet), the RADIUS server may reject requests that don't match its client whitelist. Using a fixed management VLAN interface as the source ensures all RADIUS traffic originates from the same predictable IP. The RADIUS server's network device definition must include this management IP as an authorised NAS (Network Access Server) address. For NTP synchronisation (timestamps in RADIUS accounting records) see NTP Configuration. For monitoring RADIUS traffic see NetFlow Configuration and Syslog Configuration.

4. Step 2 — Global 802.1X System Configuration

After AAA is configured, 802.1X must be enabled globally on the switch before it can be applied to individual ports. The global command acts as the master switch — without it, per-port 802.1X configurations exist in the running config but are completely inactive.

! ── Enable 802.1X globally ───────────────────────────────────────
NetsTuts_SW1(config)#dot1x system-auth-control
!                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    THE master enable switch for 802.1X on the entire switch.
!    Without this, no port-level 802.1X configuration has any effect.
!    This is the #1 reason 802.1X appears configured but does nothing.

! ── Verify global 802.1X state ───────────────────────────────────
NetsTuts_SW1#show dot1x
 Sysauthcontrol                 Enabled    ← ✓ globally enabled
 Dot1x Protocol Version         3
 Critical Recovery Delay        100
 Critical EAPOL                 Disabled

! ── Configure global 802.1X timers (optional — tune for performance)
NetsTuts_SW1(config)#dot1x timeout quiet-period 30
!                                  ^^^^^^^^^^^^^
!    Time switch waits after auth failure before retrying (default: 60s)
!    Reducing to 30s speeds up retry after a wrong password attempt

NetsTuts_SW1(config)#dot1x timeout tx-period 10
!                                  ^^^^^^^^^
!    Interval between EAP-Request/Identity retransmissions (default: 30s)
!    Reducing to 10s means devices authenticate faster on connect

NetsTuts_SW1(config)#dot1x max-reauth-req 2
!                            ^^^^^^^^^^^^^
!    Max EAP retransmissions before declaring supplicant unresponsive
!    (default: 2 — keep at 2 for reasonable timeout behaviour)

! ── RADIUS CoA (Change of Authorization) — dynamic policy updates ─
NetsTuts_SW1(config)#aaa server radius dynamic-author
NetsTuts_SW1(config-locsvr-da-radius)#client 10.0.0.100 server-key NetsTuts-RADIUS-Key
!                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    Allow RADIUS server to push mid-session policy changes (CoA)
!    Examples: re-authenticate user, bounce port, change VLAN
!    Required for Cisco ISE posture assessment and profiling
NetsTuts_SW1(config-locsvr-da-radius)#exit

5. Step 3 — Per-Port 802.1X Configuration

Gi0/1 — Single-Host Mode (Standard Employee PC)

! ── Basic 802.1X on an access port — single device ───────────────
NetsTuts_SW1(config)#interface GigabitEthernet0/1
NetsTuts_SW1(config-if)#description PC-A-Employee-Single-Host
NetsTuts_SW1(config-if)#switchport mode access
NetsTuts_SW1(config-if)#switchport access vlan 10

! ── Enable port authentication ───────────────────────────────────
NetsTuts_SW1(config-if)#authentication port-control auto
!                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    auto:   Enable 802.1X — port starts in Unauthorized state,
!            authenticates supplicant, opens if accepted.
!    force-authorized:   Port always open — 802.1X bypassed (default).
!    force-unauthorized: Port always blocked — no traffic at all.

! ── Set host mode to single-host ─────────────────────────────────
NetsTuts_SW1(config-if)#authentication host-mode single-host
!                                                  ^^^^^^^^^^^
!    Only ONE device allowed — additional MACs blocked after auth

! ── Enable 802.1X on this port ───────────────────────────────────
NetsTuts_SW1(config-if)#dot1x pae authenticator
!                               ^^^^^^^^^^^^^^^^^^^
!    PAE = Port Access Entity
!    'authenticator' = this switch port acts as the 802.1X authenticator

! ── Configure Guest VLAN (non-dot1x devices get limited access) ──
NetsTuts_SW1(config-if)#authentication event no-response action authorize vlan 30
!                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    If no EAP response (non-supplicant device), move to Guest VLAN 30
!    The device gets network access WITHOUT authentication

! ── Configure Auth-Fail VLAN (wrong credentials) ─────────────────
NetsTuts_SW1(config-if)#authentication event fail action authorize vlan 40
!                                         ^^^^
!    If credentials are rejected by RADIUS, move to Remediation VLAN 40
!    Allows IT to push remediation software or display captive portal

! ── Per-port timer overrides ─────────────────────────────────────
NetsTuts_SW1(config-if)#authentication timer reauthenticate 3600
!                                             ^^^^^^^^^^^^^^^
!    Re-authenticate this supplicant every 3600 seconds (1 hour)
!    Overrides RADIUS-supplied session-timeout if set here

NetsTuts_SW1(config-if)#exit

Gi0/2 — Multi-Auth Mode (Multiple Devices on One Port)

! ── Multi-auth: each MAC address authenticates independently ──────
NetsTuts_SW1(config)#interface GigabitEthernet0/2
NetsTuts_SW1(config-if)#description PC-B-MultiAuth-Hub-Segment
NetsTuts_SW1(config-if)#switchport mode access
NetsTuts_SW1(config-if)#switchport access vlan 10
NetsTuts_SW1(config-if)#authentication port-control auto
NetsTuts_SW1(config-if)#authentication host-mode multi-auth
!                                                  ^^^^^^^^^^
!    Every MAC on this port must authenticate separately.
!    Each gets its own RADIUS session.
!    Each can be assigned a different VLAN by RADIUS.
!    If any device fails auth, only THAT device is blocked.
NetsTuts_SW1(config-if)#dot1x pae authenticator
NetsTuts_SW1(config-if)#authentication event no-response action authorize vlan 30
NetsTuts_SW1(config-if)#authentication event fail action authorize vlan 40
NetsTuts_SW1(config-if)#exit

Gi0/3 — Multi-Domain Mode (IP Phone + PC on Same Port)

! ── Multi-domain: separate data and voice domain authentication ───
! ── The most common enterprise access port configuration ──────────
NetsTuts_SW1(config)#interface GigabitEthernet0/3
NetsTuts_SW1(config-if)#description IPPhone-plus-PC-MultiDomain
NetsTuts_SW1(config-if)#switchport mode access
NetsTuts_SW1(config-if)#switchport access vlan 10      ! Data VLAN
NetsTuts_SW1(config-if)#switchport voice vlan 20       ! Voice VLAN
!                                        ^^^^^^^^^^
!    Voice VLAN enables CDP/LLDP-MED for phone discovery
!    See: voice-vlan-configuration.html for full voice VLAN setup

NetsTuts_SW1(config-if)#authentication port-control auto
NetsTuts_SW1(config-if)#authentication host-mode multi-domain
!                                                  ^^^^^^^^^^^^
!    data domain: PC authenticates via 802.1X → gets VLAN 10
!    voice domain: IP phone authenticates via 802.1X or CDP → gets VLAN 20
!    Each domain can only have ONE authenticated device.
!    Phone failure does not block PC and vice versa.

NetsTuts_SW1(config-if)#dot1x pae authenticator

! ── Enable MAB for voice domain (phones often can't run 802.1X) ──
NetsTuts_SW1(config-if)#mab
!                        ^^^
!    MAC Authentication Bypass — phone's MAC sent to RADIUS as credentials
!    RADIUS server has phone MACs in its whitelist
!    Phone authenticates via MAB; PC authenticates via 802.1X

! ── Auth order: try 802.1X first, then MAB ───────────────────────
NetsTuts_SW1(config-if)#authentication order dot1x mab
!                                          ^^^^^^^^^^^^^
!    Supplicant present: 802.1X wins.
!    No 802.1X response: switch falls back to MAB.

NetsTuts_SW1(config-if)#authentication priority dot1x mab
!                                              ^^^^^^^^^^
!    If a higher-priority method (dot1x) succeeds after MAB authenticated,
!    dot1x takes priority and replaces the MAB session.

NetsTuts_SW1(config-if)#authentication event no-response action authorize vlan 30
NetsTuts_SW1(config-if)#authentication event fail action authorize vlan 40
NetsTuts_SW1(config-if)#exit

Gi0/4 — MAB Only (Non-Supplicant Device: Printer)

! ── MAB-only port for devices with no 802.1X capability ──────────
NetsTuts_SW1(config)#interface GigabitEthernet0/4
NetsTuts_SW1(config-if)#description Printer-MAB-Only
NetsTuts_SW1(config-if)#switchport mode access
NetsTuts_SW1(config-if)#switchport access vlan 10
NetsTuts_SW1(config-if)#authentication port-control auto
NetsTuts_SW1(config-if)#authentication host-mode multi-auth
NetsTuts_SW1(config-if)#mab
!                        ^^^
!    Only MAB configured — no dot1x pae authenticator
!    Switch sends printer's MAC as username/password to RADIUS
!    RADIUS validates MAC against device whitelist

! ── Skip 802.1X wait — go straight to MAB ────────────────────────
NetsTuts_SW1(config-if)#authentication order mab
!                                          ^^^
!    Don't attempt 802.1X first — saves the tx-period wait time
!    Use when you KNOW the device is not 802.1X capable

NetsTuts_SW1(config-if)#authentication event fail action authorize vlan 40
NetsTuts_SW1(config-if)#exit

Gi0/5 — Guest VLAN Port (Lobby/Visitor Access)

! ── Lobby port: always falls to guest VLAN for non-supplicants ───
NetsTuts_SW1(config)#interface GigabitEthernet0/5
NetsTuts_SW1(config-if)#description Lobby-Guest-Fallback
NetsTuts_SW1(config-if)#switchport mode access
NetsTuts_SW1(config-if)#switchport access vlan 30
NetsTuts_SW1(config-if)#authentication port-control auto
NetsTuts_SW1(config-if)#authentication host-mode multi-auth
NetsTuts_SW1(config-if)#dot1x pae authenticator
NetsTuts_SW1(config-if)#mab

! ── Guest VLAN: non-supplicants get internet-only access ─────────
NetsTuts_SW1(config-if)#authentication event no-response action authorize vlan 30
!                                         ^^^^^^^^^^^^^
!    Triggers after tx-period expires with no EAP response
!    Device gets VLAN 30 (internet only, no corporate resources)

! ── Auth-fail VLAN: wrong credentials → remediation ──────────────
NetsTuts_SW1(config-if)#authentication event fail max-attempts 3 action authorize vlan 40
!                                             ^^^^^^^^^^^^^^^^^^
!    After 3 failed authentication attempts → move to VLAN 40
NetsTuts_SW1(config-if)#exit

Gi0/6 — Critical VLAN (Server with RADIUS Bypass)

! ── Critical VLAN: grant access when RADIUS is unreachable ────────
! ── Essential for servers that must not lose access during RADIUS
! ── outages. Also called "Inaccessible Authentication Bypass (IAB)"
NetsTuts_SW1(config)#interface GigabitEthernet0/6
NetsTuts_SW1(config-if)#description Server-Critical-Auth-Bypass
NetsTuts_SW1(config-if)#switchport mode access
NetsTuts_SW1(config-if)#switchport access vlan 10
NetsTuts_SW1(config-if)#authentication port-control auto
NetsTuts_SW1(config-if)#authentication host-mode single-host
NetsTuts_SW1(config-if)#dot1x pae authenticator
NetsTuts_SW1(config-if)#mab

! ── Critical VLAN: if RADIUS is unreachable → move to VLAN 50 ─────
NetsTuts_SW1(config-if)#authentication event server dead action authorize vlan 50
!                                         ^^^^^^^^^^^
!    Trigger: ALL configured RADIUS servers are unreachable
!    Action: place port in Critical VLAN 50 (full access)

! ── Reinitialize when RADIUS recovers ────────────────────────────
NetsTuts_SW1(config-if)#authentication event server alive action reinitialize
!                                         ^^^^^^^^^^^^^^
!    When a RADIUS server becomes reachable again, force re-auth
!    Ensures devices authenticate properly once RADIUS is back
NetsTuts_SW1(config-if)#exit

! ── Global critical auth configuration ───────────────────────────
NetsTuts_SW1(config)#dot1x critical eapol
!                            ^^^^^^^^^^^^^^
!    When port moves to critical VLAN, send EAP-Success to supplicant
!    so the 802.1X client doesn't keep retrying.

6. Step 4 — Dynamic RADIUS VLAN Assignment

One of the most powerful features of 802.1X with RADIUS is dynamic VLAN assignment. Instead of a port being statically configured for a single VLAN, the RADIUS server returns VLAN information in the Access-Accept response, and the switch places the authenticated device into that VLAN — regardless of what VLAN the port is statically configured for. This enables a single physical port to serve different users in different VLANs depending on their identity. For VLAN fundamentals see VLANs, VLAN Tagging (802.1Q), and VLAN Creation & Management. For trunk port configuration see Trunk Port Configuration.

RADIUS Attributes for Dynamic VLAN Assignment

  RADIUS ACCESS-ACCEPT must return these three attributes together:

  Attribute 64:  Tunnel-Type = VLAN (value 13)
  Attribute 65:  Tunnel-Medium-Type = IEEE 802 (value 6)
  Attribute 81:  Tunnel-Private-Group-ID = [VLAN ID or VLAN name]
                 e.g., "10" or "Corporate" (must match VLAN on switch)

  EXAMPLE (Cisco ISE policy result):
    User "jsmith" → member of "Employees" group
    RADIUS returns:
      Tunnel-Type = VLAN
      Tunnel-Medium-Type = IEEE 802
      Tunnel-Private-Group-ID = 10  ← places jsmith on VLAN 10

    User "contractor01" → member of "Contractors" group
    RADIUS returns:
      Tunnel-Private-Group-ID = 30  ← places contractor on VLAN 30

  SWITCH BEHAVIOUR:
    Static VLAN on port (configured): VLAN 10
    RADIUS returns VLAN 30 for contractor → port moves to VLAN 30
    When session ends, port returns to configured VLAN 10

Downloadable ACL (dACL) from RADIUS

! ── RADIUS can also return a per-session ACL (dACL) ──────────────
! ── This applies traffic filtering beyond VLAN-level control ──────

! ── Configure switch to accept dACL from RADIUS ───────────────────
NetsTuts_SW1(config)#aaa authorization network default group NETSTUTS-RADIUS-GROUP
! ← Already configured in Step 1 — required for dACL download

! ── ip device tracking: required for dACL on IOS ────────────────
NetsTuts_SW1(config)#ip device tracking
!                    ^^^^^^^^^^^^^^^^
!    Enables tracking of IP-to-MAC-to-port bindings
!    Required for RADIUS-assigned ACLs to bind to the correct session

! ── RADIUS sends Cisco-AV-Pair with ACL name ─────────────────────
! ── (configured on ISE/RADIUS server, not the switch) ────────────
! Example RADIUS AV-Pair attribute returned in Access-Accept:
!   cisco-av-pair = ip:inacl#1=permit ip 10.0.0.0 0.0.0.255 any
!   cisco-av-pair = ip:inacl#2=deny ip any any log
! The switch creates a per-session ACL and applies it to the port.
! This ACL is dynamically created and removed per authentication session.

7. Step 5 — Periodic Re-Authentication and Violation Actions

Periodic re-authentication forces connected devices to re-prove their identity at regular intervals, closing sessions that should no longer be active. Violation actions define the switch's response when an unexpected device appears on an already-authenticated port. For static MAC-based port protection without 802.1X see Port Security and Port Security & Sticky MAC. For PortFast and BPDU Guard interaction with err-disabled ports see PortFast & BPDU Guard.

Periodic Re-Authentication

! ── Enable periodic re-authentication globally ────────────────────
NetsTuts_SW1(config)#dot1x reauthentication
!                           ^^^^^^^^^^^^^^
!    Globally enables periodic re-authentication
!    (Can also be enabled per-port)

! ── Per-port: enable re-auth and set interval ─────────────────────
NetsTuts_SW1(config)#interface GigabitEthernet0/1
NetsTuts_SW1(config-if)#authentication periodic
!                        ^^^^^^^^^^^^^^^^^^^^^^^
!    Enable periodic re-authentication on this port

NetsTuts_SW1(config-if)#authentication timer reauthenticate server
!                                             ^^^^^^^^^^^^^^ ^^^^^^
!    Use session timeout returned by RADIUS server (Session-Timeout attr)
!    If RADIUS doesn't return timeout, falls back to local reauthenticate timer
!    Alternative: set a fixed interval (seconds):
!    authentication timer reauthenticate 7200  ← 2-hour fixed interval

! ── Trigger immediate re-authentication manually ─────────────────
NetsTuts_SW1#authentication sessionid re-authenticate interface GigabitEthernet0/1
! ← Forces a full re-auth cycle on all sessions on Gi0/1

! ── Verify re-authentication state ──────────────────────────────
NetsTuts_SW1#show dot1x interface GigabitEthernet0/1 detail
 Interface Info for GigabitEthernet0/1
 -------------------------------------------
 PAE                       = AUTHENTICATOR
 PortControl               = AUTO
 ControlDirection          = Both
 HostMode                  = SINGLE_HOST
 ReAuthentication          = Enabled             ← ✓ re-auth enabled
 ReAuthPeriod              = 3600 (Locally configured)
 ReAuthAction              = Reauthenticate
 ...

Port Violation Actions

! ── Define what happens when an unauthorised device appears ───────
! ── on a port that has already authenticated one device ───────────

NetsTuts_SW1(config)#interface GigabitEthernet0/1
NetsTuts_SW1(config-if)#authentication violation restrict
!                                           ^^^^^^^^^
!    restrict: Drop frames from the violating MAC, log a syslog message,
!              increment violation counter. Do NOT shut down the port.
!              (Least disruptive — recommended for multi-host environments)

! ── Alternative violation actions ────────────────────────────────
NetsTuts_SW1(config-if)#authentication violation shutdown
!                                           ^^^^^^^^
!    shutdown: Err-disable the port immediately. Most secure but disruptive.
!    Requires 'errdisable recovery cause dot1x' to auto-recover.

NetsTuts_SW1(config-if)#authentication violation protect
!                                           ^^^^^^^
!    protect: Drop frames silently — no syslog, no counter.
!    Use only when violation events are expected and logging is noisy.

NetsTuts_SW1(config-if)#authentication violation replace
!                                           ^^^^^^^
!    replace: Remove the existing authenticated session and
!    authenticate the new device instead. Useful in hot-desk environments.

NetsTuts_SW1(config-if)#exit

! ── Configure err-disable auto-recovery for 802.1X violations ─────
NetsTuts_SW1(config)#errdisable recovery cause dot1x
NetsTuts_SW1(config)#errdisable recovery interval 300
!                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    Auto-recover err-disabled ports after 300 seconds (5 minutes)
!    See also: portfast-bpdu-guard.html for other errdisable causes

8. Step 6 — Full Verification

show dot1x all — Master 802.1X Status View

NetsTuts_SW1#show dot1x all

 Sysauthcontrol                 Enabled
 Dot1x Protocol Version         3

                     Dot1x Info for GigabitEthernet0/1
 -------------------------------------------------------------------
 PAE                       = AUTHENTICATOR
 PortControl               = AUTO
 ControlDirection          = Both
 HostMode                  = SINGLE_HOST
 Violation Mode            = RESTRICT
 ReAuthentication          = Enabled
 QuietPeriod               = 30
 ServerTimeout             = 30
 SuppTimeout               = 30
 ReAuthPeriod              = 3600 (Locally configured)
 ReAuthAction              = Reauthenticate
 MaxReq                    = 2
 MaxAuthReq                = 10
 TxPeriod                  = 10
 RateLimitPeriod           = 0

                     Dot1x Authenticator Client List
 -------------------------------------------------------------------
 Supplicant                : 0011.2233.4455    ← PC-A's MAC address
    Session ID             : 0A0000640000000100123456
    Auth SM State          : AUTHENTICATED     ← ✓ authenticated
    Auth BEND SM State     : IDLE
    Port Status            : AUTHORIZED        ← ✓ port open
    Authentication Method  : Dot1x
    Authenticated By       : Authentication Server
    Vlan Policy            : 10               ← RADIUS-assigned VLAN
    ACS ACL                : Not downloaded
    URL Redirect           : Not configured

show authentication sessions — Session Detail

! ── show authentication sessions — comprehensive view ─────────────
NetsTuts_SW1#show authentication sessions
Interface  MAC Address     Method   Domain   Status         Fg  Session ID
Gi0/1      0011.2233.4455  dot1x    DATA     Auth               0A0000640000000100123456
Gi0/3      aabb.cc11.2233  mab      VOICE    Auth               0A0000640000000200234567
Gi0/3      0022.3344.5566  dot1x    DATA     Auth               0A0000640000000300345678
Gi0/4      aabb.cc44.5566  mab      DATA     Auth               0A0000640000000400456789
Gi0/5      0033.4455.6677  dot1x    DATA     Authz Failed       0A0000640000000500567890
!                                            ^^^^^^^^^^^^^
!                              Authentication failed — likely moved to auth-fail VLAN

! ── Detailed session for one port ─────────────────────────────────
NetsTuts_SW1#show authentication sessions interface GigabitEthernet0/1 detail
            Interface:  GigabitEthernet0/1
          MAC Address:  0011.2233.4455
         IPv6 Address:  Unknown
         IPv4 Address:  10.0.10.55
           User-Name:  NETSTUTS\jsmith           ← AD domain username
              Status:  Authorized
              Domain:  DATA
      Security Policy:  Should Secure
      Security Status:  Secured
       Oper host mode:  single-host
     Oper control dir:  both
      Authorized By:  Authentication Server
    Vlan Policy:  10                              ← RADIUS-assigned VLAN 10
        ACS ACL:  Not downloaded
   URL Redirect:  Not configured
Session timeout:  3600s (server), Remaining: 3234s
  Idle timeout:  N/A
Common Session ID:  0A0000640000000100123456
  Acct Session ID:  0x00000001
           Handle:  0xCC000001
   Current Policy:  POLICY_Gi0/1

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)

Server Policies:
              Vlan Group:  Vlan: 10

show dot1x interface — Per-Port Detail

NetsTuts_SW1#show dot1x interface GigabitEthernet0/3 detail

                  Dot1x Info for GigabitEthernet0/3
 -------------------------------------------------------------------
 PAE                       = AUTHENTICATOR
 PortControl               = AUTO
 ControlDirection          = Both
 HostMode                  = MULTI_DOMAIN              ← ✓ multi-domain
 Violation Mode            = RESTRICT
 ReAuthentication          = Enabled
 QuietPeriod               = 30
 TxPeriod                  = 10

                  Dot1x Authenticator Client List
 -------------------------------------------------------------------
 Supplicant                : 0022.3344.5566             ← PC MAC
    Auth SM State          : AUTHENTICATED
    Port Status            : AUTHORIZED
    Authentication Method  : Dot1x
    Domain                 : DATA                      ← data domain
    Vlan Policy            : 10

 MAB Client List
 -------------------------------------------------------------------
 Client                    : aabb.cc11.2233             ← Phone MAC
    Auth SM State          : AUTHENTICATED
    Port Status            : AUTHORIZED
    Authentication Method  : MAB
    Domain                 : VOICE                     ← voice domain
    Vlan Policy            : 20

show radius server-group and Debugging

! ── Verify RADIUS server status ──────────────────────────────────
NetsTuts_SW1#show radius server-group all
Server group NETSTUTS-RADIUS-GROUP
    Sharecount = 1  selector = 0  Server(s) :
    *  10.0.0.100:1812,1813
       State: current UP        ← ✓ RADIUS server reachable
       Single-Connect: OFF
       InOctets: 2048
       OutOctets: 1536
       Opens: 14  Closes: 0  Aborts: 0  Errors: 0
       Packets In: 24  Packets Out: 22

! ── Test RADIUS reachability ────────────────────────────────────
NetsTuts_SW1#test aaa group NETSTUTS-RADIUS-GROUP jsmith Password1! new-code
Attempting authentication test to server-group NETSTUTS-RADIUS-GROUP using radius
User authentication request sent for 'jsmith'
User was successfully authenticated.            ← ✓ RADIUS responding

! ── Debug 802.1X authentication in real time (use with caution) ──
NetsTuts_SW1#debug dot1x all
! Shows: EAP packet exchange, state machine transitions, RADIUS results
! WARNING: Very verbose — use only in lab or on a single port in production:
NetsTuts_SW1#debug dot1x interface GigabitEthernet0/1
! Limit debug to one port to reduce console impact

! ── Disable debug after testing ──────────────────────────────────
NetsTuts_SW1#undebug all

! ── Check RADIUS counters per server ─────────────────────────────
NetsTuts_SW1#show radius statistics
  Access Requests: 42    Access Accepts: 38     Access Rejects: 4
  Access Challenges: 12  Malformed Responses: 0 Authentication timeouts: 0

! ── Verify EAP packet counts on a specific port ──────────────────
NetsTuts_SW1#show dot1x statistics interface GigabitEthernet0/1
            Dot1x Authenticator Port Statistics for GigabitEthernet0/1
 ------------------------------------------------------------------
 RxStart                        = 1
 RxLogoff                       = 0
 RxResp                         = 6        ← EAP responses received from supplicant
 RxRespId                       = 1
 RxInvalid                      = 0
 RxLenErr                       = 0
 RxTotal                        = 8
 TxReq                          = 5
 TxReqId                        = 1        ← EAP-Request/Identity sent to supplicant
 TxTotal                        = 6
 RxVersion                      = 1
 LastRxSrcMac                   = 0011.2233.4455

Verification Command Summary

Command	What It Shows	Key Field
`show dot1x`	Global 802.1X state — system auth control enabled/disabled, version	Sysauthcontrol = Enabled (must be Enabled for any 802.1X to work)
`show dot1x all`	All 802.1X-enabled ports — PAE mode, host-mode, timers, client list, auth state	Auth SM State = AUTHENTICATED; Port Status = AUTHORIZED; Vlan Policy
`show dot1x interface [int] detail`	Detailed 802.1X info for one port — all clients, MAB clients, states, domains	Domain = DATA or VOICE; Authentication Method = Dot1x or MAB
`show authentication sessions`	All active auth sessions across all ports — method, domain, status, session ID	Status = Auth (success); Fg = flags; Method = dot1x/mab/webauth
`show authentication sessions interface [int] detail`	Full session details — username, IP, VLAN, ACL, timeout, policy	User-Name; Vlan Policy (RADIUS-assigned VLAN); Session timeout remaining
`show dot1x statistics interface [int]`	EAP packet counters — Rx/Tx per message type	RxResp = EAP responses received; TxReqId = EAP-Request/Identity sent
`show radius server-group all`	RADIUS server groups — server IPs, state (UP/DOWN), packet counters	State = current UP; Errors = 0 (non-zero indicates connectivity issue)
`show radius statistics`	Global RADIUS counters — accepts, rejects, timeouts	Authentication timeouts > 0 = RADIUS reachability issue
`test aaa group [group] [user] [pass] new-code`	Active RADIUS connectivity test — sends a real test auth request	Response = "User was successfully authenticated" = RADIUS working
`debug dot1x all`	Real-time 802.1X EAP exchange and state machine debug messages	Use only for targeted troubleshooting; disable with `undebug all`

For general interface verification alongside 802.1X see show interfaces, show ip interface brief, and show vlan. For MAC address table verification see show mac-address-table. For SNMP-based monitoring of authentication sessions see SNMP v2c/v3 Configuration.

9. Complete Configuration Reference & Key Points

Full 802.1X Switch Configuration

Copy the complete configuration below. Verify the full applied config at any time with show running-config. For saving and managing Cisco configurations see Saving & Managing Cisco Configurations.

! ════════════ NetsTuts_SW1 — Complete 802.1X Configuration ════════
!
! ─── AAA Foundation ──────────────────────────────────────────────
aaa new-model
!
radius server NETSTUTS-ISE
 address ipv4 10.0.0.100
 key NetsTuts-RADIUS-Key
 auth-port 1812
 acct-port 1813
!
aaa group server radius NETSTUTS-RADIUS-GROUP
 server name NETSTUTS-ISE
!
aaa authentication dot1x default group NETSTUTS-RADIUS-GROUP
aaa authorization network default group NETSTUTS-RADIUS-GROUP
aaa accounting dot1x default start-stop group NETSTUTS-RADIUS-GROUP
!
ip radius source-interface Vlan99
radius-server timeout 5
radius-server retransmit 2
radius-server deadtime 15
!
! ─── Global 802.1X ───────────────────────────────────────────────
dot1x system-auth-control
dot1x timeout quiet-period 30
dot1x timeout tx-period 10
dot1x max-reauth-req 2
dot1x critical eapol
!
ip device tracking
!
! ─── CoA Support ─────────────────────────────────────────────────
aaa server radius dynamic-author
 client 10.0.0.100 server-key NetsTuts-RADIUS-Key
!
! ─── Err-disable Recovery ────────────────────────────────────────
errdisable recovery cause dot1x
errdisable recovery interval 300
!
! ─── Gi0/1: Single-Host Employee Port ────────────────────────────
interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 10
 authentication port-control auto
 authentication host-mode single-host
 authentication periodic
 authentication timer reauthenticate server
 authentication violation restrict
 authentication event no-response action authorize vlan 30
 authentication event fail action authorize vlan 40
 dot1x pae authenticator
!
! ─── Gi0/3: Multi-Domain (Phone + PC) ────────────────────────────
interface GigabitEthernet0/3
 switchport mode access
 switchport access vlan 10
 switchport voice vlan 20
 authentication port-control auto
 authentication host-mode multi-domain
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication periodic
 authentication timer reauthenticate server
 authentication violation restrict
 authentication event no-response action authorize vlan 30
 authentication event fail action authorize vlan 40
 dot1x pae authenticator
 mab
!
! ─── Gi0/6: Critical Auth Bypass (Server) ────────────────────────
interface GigabitEthernet0/6
 switchport mode access
 switchport access vlan 10
 authentication port-control auto
 authentication host-mode single-host
 authentication event server dead action authorize vlan 50
 authentication event server alive action reinitialize
 dot1x pae authenticator
 mab

802.1X Command Reference

Command	Mode	Purpose
`aaa new-model`	Global config	Enable AAA framework. Required before any RADIUS or 802.1X commands function. See AAA Overview and AAA RADIUS Configuration.
`radius server [name]`	Global config	Create named RADIUS server block. Modern IOS 15.x method. Configure address, key, ports inside.
`aaa authentication dot1x default group [grp]`	Global config	Define which RADIUS group handles 802.1X authentication. Applied to all dot1x ports by default.
`aaa authorization network default group [grp]`	Global config	Enable RADIUS-based authorisation — required for dynamic VLAN and dACL assignment. See ACL Overview and Extended ACL Configuration for ACL background.
`dot1x system-auth-control`	Global config	Master enable for 802.1X. Without this, all per-port 802.1X config is inactive.
`authentication port-control auto`	Interface config	Enable 802.1X on port. Port starts Unauthorized; opens after successful auth. Alternatives: force-authorized, force-unauthorized.
`dot1x pae authenticator`	Interface config	Set port as 802.1X authenticator (the switch role). Required on every 802.1X-enabled port.
`authentication host-mode [mode]`	Interface config	Set how many devices and how they authenticate: single-host, multi-host, multi-auth, multi-domain.
`mab`	Interface config	Enable MAC Authentication Bypass. Allows non-supplicant devices to authenticate via MAC address sent to RADIUS. See MAC Addresses.
`authentication order dot1x mab`	Interface config	Set authentication method priority. Try 802.1X first; fall back to MAB if no EAP response.
`authentication event no-response action authorize vlan [n]`	Interface config	Guest VLAN: place non-supplicant devices into VLAN n when no EAP response is received.
`authentication event fail action authorize vlan [n]`	Interface config	Auth-Fail VLAN: place devices that fail authentication into restricted VLAN n.
`authentication event server dead action authorize vlan [n]`	Interface config	Critical VLAN: grant access on VLAN n when all RADIUS servers are unreachable.
`authentication violation [restrict\|shutdown\|protect\|replace]`	Interface config	Action when an additional unauthorised device appears on an already-authenticated port. See Violation Modes and Port Security.
`authentication periodic`	Interface config	Enable periodic re-authentication on this port.
`authentication timer reauthenticate server`	Interface config	Use RADIUS-supplied session timeout for re-authentication interval.

Key Points & Exam Tips

dot1x system-auth-control is the master enable — without it, nothing works. This is the most common reason an 802.1X configuration appears correct but has no effect. Every per-port command, every host-mode, every VLAN assignment is completely dormant until this global command is entered. Always verify it with show dot1x and confirm Sysauthcontrol = Enabled.
Both authentication port-control auto and dot1x pae authenticator are required on every 802.1X port. authentication port-control auto puts the port into 802.1X enforcement mode (Unauthorized by default, moves to Authorized on success). dot1x pae authenticator sets the switch's role as the authenticator in the EAP exchange. Both commands must be present. Missing either one means the port either stays permanently open (port-control not set) or doesn't participate in EAP exchanges (pae not set).
multi-domain is the correct host-mode for IP phone + PC combinations. Multi-domain creates two independent authentication domains per port — a data domain and a voice domain — each with its own RADIUS session and VLAN assignment. The IP phone authenticates (typically via MAB) in the voice domain and gets VLAN 20. The PC authenticates via 802.1X in the data domain and gets VLAN 10. Multi-host would be wrong here — it authenticates one device and lets everything else ride along, providing no per-device control. See Voice VLAN Configuration for the full IP phone setup.
Guest VLAN vs Auth-Fail VLAN — different triggers, different intent. Guest VLAN triggers when there is no EAP response at all — the device is not an 802.1X supplicant (e.g., a visitor's non-domain laptop, a printer). Auth-Fail VLAN triggers when a device IS a supplicant (it responds to EAP) but the credentials are rejected by RADIUS. These are different security situations: a guest VLAN device is unknown; an auth-fail device has an identity but failed validation. Configuring both allows granular handling of both scenarios.
MAB is weaker than 802.1X but necessary for non-supplicant devices. MAC addresses can be spoofed — an attacker who learns an authorised printer's MAC address can clone it and potentially get network access. MAB should be used only for devices that genuinely cannot run an 802.1X supplicant. Always combine MAB with RADIUS profiling (Cisco ISE profiles device type from DHCP, HTTP, CDP attributes) to validate that the device matches its expected type, not just its MAC address. Complement 802.1X with DHCP Snooping and Dynamic ARP Inspection for layered Layer 2 security.
Critical VLAN protects against RADIUS outages — but must be used carefully. When all RADIUS servers become unreachable, ports with Critical VLAN configured move their sessions to the critical VLAN without re-authentication. This ensures business continuity (servers stay online, employees keep working). However, this also means that an attacker who disrupts RADIUS connectivity can potentially gain network access via Critical VLAN bypass. Restrict Critical VLAN to ports connected to infrastructure devices whose access level is already established, and pair it with authentication event server alive action reinitialize so devices re-authenticate when RADIUS recovers.
Dynamic VLAN assignment requires all three RADIUS attributes (64, 65, 81) together. Attribute 64 (Tunnel-Type = VLAN), Attribute 65 (Tunnel-Medium-Type = IEEE 802), and Attribute 81 (Tunnel-Private-Group-ID = VLAN ID) must all be returned in the RADIUS Access-Accept. Missing any one of these three attributes means the switch ignores the VLAN assignment and uses the port's statically configured VLAN instead. This is the most common RADIUS VLAN troubleshooting point.
Use authentication order dot1x mab and authentication priority dot1x mab together. The order command defines the sequence in which methods are tried (802.1X first, MAB as fallback). The priority command defines which method takes precedence if both succeed simultaneously. Using both commands ensures that if a MAB session is already active and the user launches an 802.1X supplicant, the 802.1X session replaces the less-secure MAB session.
On the CCNP Security exam: know the three-party model (supplicant, authenticator, auth server), the five host-mode options and their use cases, the difference between Guest VLAN and Auth-Fail VLAN, the three RADIUS attributes required for dynamic VLAN assignment, the role of MAB as a fallback, and the verification commands (show dot1x all, show authentication sessions). Also be able to identify missing configuration elements (missing aaa new-model, missing dot1x system-auth-control, missing dot1x pae authenticator) from a show output. Review AAA Overview and 802.1X Overview for exam preparation.

Related Labs: 802.1X is built on top of the AAA framework — configure and understand AAA Configuration and AAA RADIUS Configuration before this lab. Port-based authentication works alongside VLAN infrastructure; see VLANs and VLAN Creation & Management for VLAN setup. For physical access port protection that complements 802.1X identity-based access control see Storm Control & Traffic Shaping, Port Security & Sticky MAC, and Private VLAN Configuration. For protecting the switch's own management plane alongside 802.1X data-plane access control see CoPP Configuration. For securing management access to the switch itself see SSH Configuration. For logging authentication events see Syslog Configuration. For wireless 802.1X see Wi-Fi Security.

TEST WHAT YOU LEARNED

1. An engineer configures `authentication port-control auto` and `dot1x pae authenticator` on Gi0/1, but devices connected to the port are never prompted for credentials and get immediate network access. What is the most likely cause?

A. The authentication host-mode command is missing — without it, 802.1X cannot determine how many devices to authenticate B. The RADIUS server is unreachable, so the switch falls back to open access by default C. dot1x system-auth-control is not configured globally. This is the master enable switch for 802.1X on the entire switch. Without it, all per-port authentication port-control auto and dot1x pae authenticator commands are present in the configuration but are completely inactive — the port behaves as if it is in force-authorized state and allows all traffic without any authentication challenge. Verify with show dot1x — if Sysauthcontrol = Disabled, 802.1X is not enforcing anything. D. The aaa authentication dot1x default method list is defined but uses the wrong server group name — the switch cannot find the RADIUS configuration

Correct answer is C. The dot1x system-auth-control command is the single most critical global command for 802.1X deployment, and its omission is the most common reason a fully configured 802.1X setup fails to enforce authentication. Think of it as the circuit breaker for the entire 802.1X subsystem — every interface-level command is wired behind it. When disabled (the default state), the switch's 802.1X logic is completely bypassed at the system level, regardless of what is configured on individual interfaces. The port's behaviour reverts to its default: force-authorized (all traffic permitted). This design prevents accidental lockouts — if you're building the 802.1X configuration incrementally, you can configure all the interfaces without accidentally blocking production traffic until you're ready to activate the system with this single command. The verification is immediate: show dot1x shows Sysauthcontrol = Disabled when the command is missing. Option B describes a different failure mode — when RADIUS is unreachable, the switch does NOT automatically fall back to open access. Instead, authentication fails (assuming no Critical VLAN is configured), and the port stays Unauthorized, blocking traffic. The switch does not default to open access on RADIUS failure.

2. A network port has `authentication host-mode multi-domain` configured with both 802.1X and MAB enabled. An IP phone connects but has no 802.1X supplicant. What authentication process occurs, and what happens to the PC that connects behind the phone?

A. The phone attempts 802.1X first. After the tx-period timeout with no EAP response, the switch falls back to MAB — it sends the phone's MAC address as both the username and password to the RADIUS server. If the RADIUS server has the phone's MAC in its whitelist, it returns an Access-Accept and the phone is placed in the voice domain, typically assigned VLAN 20. When the PC connects behind the phone, it triggers a completely independent 802.1X authentication in the data domain. The PC's 802.1X supplicant presents credentials; RADIUS authenticates and returns VLAN 10 for the data domain. Both devices are simultaneously authenticated on the same port, each in their respective domain, each with their own VLAN assignment. B. The phone authenticates first; then the PC gets free access without authentication because the port is already in Authorized state in multi-domain mode C. Multi-domain mode requires both devices to use the same authentication method — since the phone uses MAB, the PC must also use MAB D. The phone and PC cannot coexist on a multi-domain port unless both devices support 802.1X — MAB is not supported in multi-domain mode

Correct answer is A. Multi-domain authentication mode is specifically designed for the IP phone + PC co-location scenario and is the most common host-mode deployed on enterprise access ports. The key architectural insight is that multi-domain creates two completely independent authentication contexts on the same physical port: the voice domain (for the IP phone, identified via the Voice VLAN) and the data domain (for the PC, on the access VLAN). Each domain can use a different authentication method — in this case, MAB for the phone (which has no 802.1X supplicant) and 802.1X for the PC (which runs Windows/macOS with a supplicant). Each domain has its own RADIUS session, its own VLAN assignment, its own session timeout, and its own re-authentication timer. Failure in one domain does not affect the other — if the PC's credentials are wrong and it's placed in the auth-fail VLAN, the phone continues operating in the voice VLAN unaffected. The switch identifies the phone using CDP/LLDP device type detection or by the initial EAPOL timeout — after tx-period seconds with no EAP response from the device on the voice VLAN, MAB is triggered for that MAC. Understanding the auth order command is important here: authentication order dot1x mab tells the switch to try 802.1X first, wait for the tx-period, then try MAB. This adds some delay (typically 10-30 seconds) before MAB kicks in. If you know a device will never respond to EAP, using authentication order mab (MAB only) on that domain avoids the wait.

3. What is the difference between a Guest VLAN and an Auth-Fail VLAN in 802.1X? When does each trigger, and why does this distinction matter for security policy?

A. They are identical — both provide restricted network access and both trigger when a device fails to authenticate successfully B. Guest VLAN is for wireless clients; Auth-Fail VLAN is for wired clients — the distinction is about connection medium, not authentication outcome C. Guest VLAN triggers after 3 authentication failures; Auth-Fail VLAN triggers immediately on the first failure D. Guest VLAN triggers when no EAP response is received — the connected device is not an 802.1X supplicant at all (it cannot speak EAP). This indicates the device is genuinely unknown — possibly a visitor's personal laptop, a legacy printer, or a conference room device. The switch times out waiting for EAPOL and places the port in the Guest VLAN. Auth-Fail VLAN triggers when a device IS a supplicant (it responded to EAP and engaged in the authentication exchange) but the credentials were rejected by the RADIUS server. This indicates a known identity that failed validation — possibly wrong password, expired certificate, or an unmanaged corporate device. The security distinction matters: a Guest VLAN device is unknown and potentially external — it should get internet-only access with no corporate resource visibility. An Auth-Fail VLAN device is a known entity that failed authentication — it might need remediation (antivirus update, domain join, certificate renewal) and should reach a remediation server but nothing else.

Correct answer is D. The Guest VLAN and Auth-Fail VLAN distinction is subtle but security-critical, and it's a high-frequency exam topic. The trigger condition is the key differentiator: Guest VLAN = no EAP response (silent device). Auth-Fail VLAN = EAP exchange happened, RADIUS returned Access-Reject. Consider the practical scenarios: Guest VLAN — a visitor plugs their personal MacBook into a lobby port. The MacBook has 802.1X enabled but the supplicant cannot present valid corporate credentials, so it stays silent (actually, in this case it would try and fail — but a simpler example is a non-domain printer that has no EAP client). After tx-period seconds with no response, Guest VLAN triggers. The visitor gets internet access only. Auth-Fail VLAN — an employee's laptop has an expired domain certificate. The 802.1X supplicant runs, sends EAP-TLS with the expired cert, RADIUS rejects it (certificate validation fails), Access-Reject is returned. Auth-Fail VLAN triggers. The laptop is placed in the remediation VLAN where it can reach the certificate renewal server and nothing else. Why the distinction matters: if you used only a Guest VLAN for both scenarios, you'd be giving visitors and certificate-failure employees identical treatment. In many security policies, a device that actively tried to authenticate but failed is MORE suspicious than one that simply didn't respond — it should get even more restricted access or trigger an alert. The Auth-Fail VLAN allows this differentiated response. From a configuration standpoint: no-response action authorize vlan 30 = Guest VLAN. fail action authorize vlan 40 = Auth-Fail VLAN.

4. What three RADIUS attributes must be present in an Access-Accept response for dynamic VLAN assignment to work on a Cisco switch? What happens if only two of the three are returned?

A. Attributes 1 (User-Name), 2 (User-Password), and 81 (Tunnel-Private-Group-ID). Missing any one causes the switch to reject the Access-Accept entirely B. Attribute 64 (Tunnel-Type = VLAN, value 13), Attribute 65 (Tunnel-Medium-Type = IEEE 802, value 6), and Attribute 81 (Tunnel-Private-Group-ID = VLAN ID or name). All three must be present together. If any one is missing, the switch ignores the VLAN assignment entirely and places the session in the port's statically configured VLAN instead. The session is still authorized (Access-Accept is still accepted); only the dynamic VLAN assignment fails silently. The most common symptom: authenticated users all end up in the wrong VLAN (the statically configured one) despite RADIUS appearing to work correctly. C. Attribute 81 alone is sufficient — the switch automatically infers Tunnel-Type and Tunnel-Medium-Type from the presence of Attribute 81 D. The switch does not support dynamic VLAN assignment via RADIUS — VLANs must be configured statically on each port using switchport access vlan

Correct answer is B. Dynamic VLAN assignment is one of the most powerful 802.1X features and is central to identity-based network access in enterprise environments, but it has a strict three-attribute requirement that is frequently misconfigured. The three attributes work as a set: Attribute 64 (Tunnel-Type) tells the switch what kind of tunnel/segment the assignment is for — value 13 means VLAN. Without this, the switch doesn't know it's receiving a VLAN assignment. Attribute 65 (Tunnel-Medium-Type) specifies the transport medium — value 6 means IEEE 802 (Ethernet). This confirms the context is a wired Ethernet VLAN. Attribute 81 (Tunnel-Private-Group-ID) carries the actual VLAN identifier — either a numeric VLAN ID (e.g., "10") or a VLAN name (e.g., "Corporate") that must exactly match a VLAN defined on the switch. If only Attribute 81 is returned (just the VLAN ID, missing 64 and 65), the switch does not interpret it as a VLAN assignment — the attribute is present but its meaning is ambiguous without the tunnel type context. The result is silent failure: the authentication succeeds (the Access-Accept is processed), the session is authorized, but the device lands in the statically configured VLAN rather than the RADIUS-assigned VLAN. From a troubleshooting perspective, the symptom is that show authentication sessions interface [int] detail shows "Vlan Policy" either as the static VLAN or as empty/not assigned, even though the RADIUS server shows it sent the VLAN. The fix is to check the RADIUS server's policy configuration and verify all three attributes are included in the Access-Accept.

5. Compare `authentication host-mode multi-host` and `authentication host-mode multi-auth`. Which is more secure and why? In what scenario would multi-host still be appropriate?

A. They are equivalent — both require all devices to authenticate individually before getting network access B. Multi-auth is less secure — it creates multiple RADIUS sessions that can overwhelm the authentication server in large deployments C. Multi-auth is significantly more secure. In multi-host mode, only the first device needs to authenticate — once one device authenticates successfully, all other devices that connect to the same port (regardless of their identity) automatically get network access by riding on the first device's authorized session. An attacker can connect any device to the port after the legitimate device authenticates and get full network access. In multi-auth mode, every device's MAC address triggers an independent RADIUS authentication. Each device must present valid credentials. Failure of one device does not grant access to others. Multi-host is appropriate only in specific legacy scenarios: a PC connected to a port through an unmanaged hub where the PC's authentication should grant basic access to legacy devices (e.g., old industrial equipment with no 802.1X capability) that connect to the same hub. Even then, multi-auth with MAB for the legacy devices is a better alternative. D. Multi-host is more secure because it limits RADIUS authentication to one session per port, reducing the attack surface

Correct answer is C. The security difference between multi-host and multi-auth is fundamental and represents one of the most important design decisions in 802.1X deployment. Multi-host operates on a "first device authenticates, all others get free access" model. The moment one legitimate device (say, the employee's laptop) successfully authenticates on a port, the switch opens the port for ALL traffic from ANY MAC address. An attacker who connects a rogue device to that same port (via a hub or by briefly disconnecting and reconnecting) gets network access without any authentication. The authentication check is completely bypassed for all devices after the first. This is why multi-host is sometimes called "the lazy mode" — it provides the appearance of 802.1X enforcement while actually providing very little security benefit beyond the first device. Multi-auth is the correct choice for almost every scenario: each MAC address on the port triggers an independent RADIUS authentication session. Each device must have valid credentials (whether via 802.1X supplicant or MAB). The switch maintains separate session entries for each device, with separate VLAN assignments, separate timeouts, and separate access control. If device A's session fails or expires, only device A loses access — device B's session is unaffected. The legitimate use case for multi-host is extremely narrow: truly legacy environments where a device connected behind a hub genuinely cannot authenticate in any way (no 802.1X, no unique MAC for MAB) and must share the port's authorized state. In modern networks, this scenario is almost always better handled with RADIUS profiling and device-specific policies.

6. What is MAC Authentication Bypass (MAB), how does the authentication exchange work at the RADIUS protocol level, and what is the primary security limitation of MAB compared to 802.1X?

A. MAB uses the device's MAC as an encryption key to create a secure tunnel — it is equally secure to EAP-TLS B. MAB authenticates using the ARP table — the switch checks if the device's MAC is in the ARP cache before granting access C. MAB sends the MAC address to the RADIUS server encrypted with IPsec — the server decrypts and validates against a whitelist D. In MAB, the switch detects a device's MAC address from its Ethernet frames, then crafts a RADIUS Access-Request using that MAC address as both the username (in the User-Name attribute) and the password (in the User-Password attribute, hashed with the RADIUS shared secret). The RADIUS server checks this MAC against a device whitelist or database — if the MAC is authorised, it returns an Access-Accept (possibly with VLAN, ACL, and other policy attributes). The primary security limitation: MAC addresses can be spoofed. Any attacker who discovers an authorised device's MAC address (from network traffic capture, equipment labels, or IT documentation) can clone that MAC onto a rogue device and gain network access. The switch sends the spoofed MAC to RADIUS, RADIUS finds it in the whitelist, and grants access. There is no cryptographic proof of device identity — unlike EAP-TLS which uses a private key that cannot be extracted from the certificate. MAB should always be combined with device profiling (fingerprinting via DHCP options, HTTP user-agent, CDP/LLDP attributes) to detect MAC spoofing attempts.

Correct answer is D. MAB is a pragmatic workaround for the reality that many network-connected devices (IP cameras, printers, industrial sensors, medical devices, building automation systems) cannot run 802.1X supplicants. Understanding its RADIUS mechanics and limitations is essential for proper security design. The RADIUS exchange in MAB: the switch waits for the 802.1X tx-period timeout (typically 10-30 seconds). When no EAP response arrives, the switch enters MAB mode. It learns the device's MAC address from the source MAC of the first Ethernet frame. It constructs a RADIUS Access-Request: User-Name = MAC address (formatted as "aabb.cc11.2233" or "aa-bb-cc-11-22-33" depending on configuration). User-Password = same MAC address, hashed with the RADIUS shared secret (PAP-style). NAS-Port-Type = Ethernet. The RADIUS server receives this, strips the hashing, checks the MAC against its database. The spoofing vulnerability is inherent to the protocol — because the "credential" is the MAC address, and MAC addresses are visible in plaintext in every Ethernet frame, any device can copy and use an authorised MAC. Enterprise deployments mitigate this with RADIUS profiling on Cisco ISE: even if the MAC matches, ISE also checks that the device's DHCP fingerprint, HTTP user-agent, SNMP OID, and other characteristics match what's expected for a device of that type. A laptop pretending to be an IP camera would have the right MAC but wrong DHCP fingerprint, and ISE's profiling policy would detect and potentially block the impersonation.

7. An engineer wants the Critical VLAN to activate when the RADIUS server is unreachable, but also wants the port to force re-authentication as soon as RADIUS becomes available again. What two commands achieve this, and why is the second command important?

A. dot1x critical eapol and dot1x reauthentication — these two commands handle RADIUS failure and recovery respectively B. authentication event server dead action authorize vlan 50 and authentication event server alive action reinitialize. The first command moves sessions to VLAN 50 when RADIUS becomes unreachable, granting continued network access to connected devices without re-authentication. The second command is critical for security: when RADIUS recovers, reinitialize forces every session currently in the Critical VLAN to restart the full 802.1X authentication cycle. Without this command, devices stay permanently in the Critical VLAN even after RADIUS is back — they never re-authenticate, potentially bypassing policies (VLAN changes, ACL updates, posture assessments) that should apply after RADIUS recovery. C. authentication event server dead action authorize vlan 50 alone — the switch automatically re-authenticates when RADIUS recovers D. radius-server deadtime and radius-server retransmit — these control when RADIUS is declared dead and when the switch retries

Correct answer is B. The Critical VLAN feature (Inaccessible Authentication Bypass) addresses a genuine operational challenge: if RADIUS becomes unavailable, every 802.1X-authenticated session either expires or cannot re-authenticate. In a large office, this means every connected device loses network access simultaneously — a devastating outage caused by an authentication infrastructure failure rather than a network failure. The Critical VLAN provides the failsafe: devices keep access on a pre-defined VLAN when RADIUS is unavailable. The server alive action reinitialize command is the necessary counterpart. Without it: devices move to Critical VLAN when RADIUS fails. RADIUS recovers. Devices remain in Critical VLAN indefinitely — they never trigger re-authentication because their sessions are marked as authorized (via Critical VLAN bypass). The security problem: Critical VLAN may have different (possibly broader) access than the RADIUS-assigned VLAN. Devices should not stay in Critical VLAN longer than necessary. With reinitialize: when the switch detects that a RADIUS server is responding again (it periodically probes dead servers), it immediately forces all Critical VLAN sessions to re-initialize — the sessions drop, the ports restart the 802.1X/MAB authentication cycle, devices get their proper RADIUS-assigned VLAN back, and the security posture returns to normal. The operational impact of reinitialize is a brief network interruption (a few seconds) for affected devices when RADIUS recovers — acceptable since connectivity was already degraded during the outage.

8. RADIUS Change of Authorization (CoA) is enabled on a switch using `aaa server radius dynamic-author`. What operational scenarios does CoA enable that static 802.1X configuration cannot achieve?

A. CoA allows the switch to send VLAN assignments to the RADIUS server — it reverses the normal direction of policy communication B. CoA enables RADIUS redundancy — if the primary RADIUS server fails, CoA automatically activates the secondary C. CoA enables the RADIUS server (e.g., Cisco ISE) to push mid-session policy changes to the switch without waiting for the next re-authentication cycle. Real-world scenarios: (1) Posture assessment — ISE checks if the endpoint has current antivirus. If it fails, ISE sends a CoA to move the device from VLAN 10 to the remediation VLAN 40 immediately, mid-session. (2) Security incident response — a compromised device is detected; ISE sends a CoA to disconnect/bounce the port immediately. (3) Profiling update — ISE initially profiles a device as "unknown" and grants limited access; after collecting more fingerprint data it identifies it as an authorised asset and sends CoA to upgrade its VLAN assignment. (4) Session timeout — ISE sends a CoA Disconnect-Request to terminate an active session rather than waiting for it to time out. Without CoA, all policy changes take effect only at the next re-authentication — which could be hours away on a session with a long timeout. D. CoA is only used for accounting — it sends session updates (bytes transferred, connection duration) from the switch to the RADIUS server in real time

Correct answer is C. RADIUS CoA (RFC 5176) fundamentally changes the 802.1X policy model from a static "authenticate-once, apply-policy-at-auth-time" model to a dynamic "continuously evaluated, real-time policy enforcement" model. Without CoA, the security posture of a session is fixed at the moment of authentication: the VLAN and ACL assigned by RADIUS at login time remain until the session ends or re-authenticates. CoA reverses the communication direction: normally, the switch initiates RADIUS requests. With CoA, the RADIUS server initiates policy change messages to the switch (using UDP port 3799). The switch processes these messages and immediately updates the session state — changing VLANs, applying new ACLs, terminating sessions, or forcing re-authentication — without any action from the end device. The posture scenario is the most important for CCNP Security: Cisco ISE's posture assessment works by initially placing connecting devices in a quarantine VLAN (limited access to ISE redirect URL). A posture agent on the device checks compliance. If compliant, ISE sends a CoA to move the device to the production VLAN. If non-compliant, ISE sends a CoA to move it to remediation. This entire workflow is invisible to the end user — the VLAN change happens seamlessly without the user needing to re-authenticate. The aaa server radius dynamic-author configuration creates a listener on the switch for incoming CoA messages, and the client [radius-server-ip] server-key [key] sub-command authenticates the CoA messages (both the switch and RADIUS server must use the same shared secret for CoA).

9. A `show authentication sessions` output shows a port with Status "Authz Failed" for a connected device. What does this status mean, and what are the two most likely causes and their fixes?

A. "Authz Failed" means the authentication phase passed (RADIUS returned Access-Accept) but the authorisation phase failed — the switch could not apply the policy returned by RADIUS. The two most common causes: (1) RADIUS returned a VLAN assignment (via Attribute 81) but the VLAN does not exist on the switch or is not active. Fix: create the VLAN with vlan [n] and verify it is in the active state with show vlan brief. (2) RADIUS returned a downloadable ACL (dACL) name, but ip device tracking is not configured on the switch — without device tracking, the switch cannot bind the ACL to the session. Fix: configure ip device tracking globally. In both cases the device's 802.1X credentials were accepted, but the resulting policy could not be enforced, leaving the session in a partially authorised state. B. "Authz Failed" means the RADIUS server was unreachable — the switch could not contact the authentication server during the authorisation exchange C. "Authz Failed" is the same as "Auth Failed" — the device presented wrong credentials and was rejected by RADIUS D. "Authz Failed" means the device is in the auth-fail VLAN — the status is informational only and does not indicate a policy problem

Correct answer is A. The distinction between authentication failure and authorisation failure is important and frequently confused. Authentication = "who are you?" — validated by credential check. Authorisation = "what can you do?" — determined by policy applied after successful authentication. "Authz Failed" specifically indicates that authentication succeeded (the device's identity was verified and RADIUS returned Access-Accept) but applying the resulting policy failed. This is a switch-side configuration problem, not a credential problem. The VLAN-not-existing scenario is the most common: RADIUS returns Tunnel-Private-Group-ID = 25 (VLAN 25), but VLAN 25 doesn't exist on the switch (it was never created with vlan 25 under global config, or it's in a suspended state). The switch cannot place the session into a non-existent VLAN — the session enters "Authz Failed." Troubleshooting: show vlan brief — verify the RADIUS-assigned VLAN exists and is active. The dACL/ip device tracking scenario: ISE returns a per-session ACL in the Access-Accept. To bind a dACL to an IP address (required for IP-level ACL enforcement), the switch needs ip device tracking to know which IP address is associated with which session/MAC. Without this, the switch receives the ACL policy but cannot apply it, resulting in "Authz Failed." Troubleshooting: show running-config | include ip device tracking — if absent, add ip device tracking globally. A third less-common cause: the VLAN name (not ID) is returned in Attribute 81, but the name doesn't exactly match the VLAN name configured on the switch (case-sensitive comparison).

10. An engineer configures `authentication violation shutdown` on Gi0/1 (single-host mode). PC-A authenticates successfully. Later, PC-A's docking station is connected, presenting a second MAC (the docking station's NIC). What happens to the port, and how should the engineer restore it?

A. The port ignores the second MAC — single-host mode only tracks the first authenticated MAC and discards frames from others B. The port moves to the auth-fail VLAN for both devices until the second MAC authenticates successfully C. The second MAC triggers a new 802.1X authentication cycle and replaces the original session D. In single-host mode, only one MAC address is permitted per port after authentication. When the docking station introduces a second MAC, the switch detects a violation. With authentication violation shutdown, the switch immediately err-disables the port — all traffic stops for both PC-A and the docking station. The docking station's NIC appearing is treated as a security event (potential unauthorised device insertion). To restore: manually clear the err-disable state with shutdown followed by no shutdown on Gi0/1, or wait for the errdisable recovery timer if errdisable recovery cause dot1x is configured. Long-term fix: change the host-mode to multi-auth so the docking station's MAC also authenticates (via MAB or 802.1X), or change to multi-host if the docking station is always used with PC-A and a second authentication is undesirable. In production environments, authentication violation restrict is generally preferred over shutdown — restrict drops the violating frames and logs the event without disabling the port for the authenticated device.

Correct answer is D. This scenario describes a real-world operational problem that occurs frequently in enterprise environments — docking stations are extremely common and they introduce additional MACs (the dock's integrated NIC, sometimes a USB Ethernet adapter inside the dock). In single-host mode, the switch tracks exactly one MAC post-authentication: the one that triggered the successful 802.1X exchange. Any subsequent unique source MAC address on the same port is a violation event. With violation shutdown, the response is immediate and complete: the port enters err-disabled state. This is a binary, disruptive outcome — PC-A (the legitimate device) also loses network access because the entire port is shut down, not just traffic from the violating MAC. This is why violation shutdown is considered too aggressive for most environments. Violation restrict is more appropriate for a mixed environment: it drops frames from the violating MAC and generates a syslog message, but the authenticated session for PC-A's MAC continues unaffected. Violation replace actually swaps sessions — the new MAC's authentication replaces the old one, which can work in hot-desk scenarios but would cause PC-A to lose access. The best architectural solution for docking station environments is to change to multi-auth host-mode: the dock's integrated NIC triggers a separate RADIUS session (MAB if the dock's MAC is in the whitelist, or the user can authenticate via 802.1X on the dock's NIC). Each device on the port has its own independent session — legitimate devices are not affected by each other's authentication state.

Back to Home