Architecture and operating model
802.1X establishes supplicant and RADIUS-based authentication when a wired or wireless session starts. EAP-TLS provides strong device or user identity with certificates, and the result can map to authorization attributes such as a VLAN, ACL or role. The operating model includes certificate lifecycle, RADIUS availability and authorization policy, not authentication alone.
MAC Authentication Bypass (MAB) uses a MAC address as a weaker identity exception for printers, phones or OT devices that cannot run an 802.1X supplicant. MAC addresses are observable and spoofable, so bind every MAB record to an owner, switch port, device profile, restricted segment and expiry date.
A guest or restricted VLAN is the safe default for failed authentication; it must not become a silent path to production. Distinguish temporary RADIUS unavailability from rejected unknown credentials. Measure critical-auth behavior, voice devices, multidomain ports and reauthentication timers in a pilot.
- 1Link and 802.1X attempt
- 2RADIUS identity and policy decision
- 3Apply role, VLAN or ACL
- 4Session telemetry and reauthentication
Design parameters
- Identity strength
- Choose EAP-TLS for managed clients and time-bound, segmented MAB exceptions only for devices without a supplicant.
- RADIUS resilience
- Design at least two servers, explicit timeout/retry per network device and a controlled server-dead policy.
- Authorization result
- Prefer roles or downloadable ACLs where practical; keep rejected and unknown devices separate.
- Reauthentication
- Session timeout and CoA behavior determine how quickly certificate revocation or device changes take effect.
Worked example
For 600 access ports with 420 managed computers, 80 phones, 70 printers/IoT devices and 30 guests, start with 20 computers, five phones and five printers. Justify MAB for the 70 devices that lack supplicants, not all 150 non-PC devices, and assign a least-privilege ACL to each device class.
With a three-second RADIUS timeout and two retries against two servers, connection delay can exceed 12 seconds depending on the device’s retry order. Measure voice boot and DHCP timing before carrying those values into production.
Example commands: replace lab values and confirm permissions and software versions before use.
# Observe EAPOL and DHCP on a controlled Linux test port
sudo tcpdump -ni eth0 -e 'ether proto 0x888e or port 67 or port 68'
# Validate FreeRADIUS configuration and a lab request
sudo radiusd -XC
sudo radtest lab-user 'REDACTED' 127.0.0.1 0 'REDACTED'Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Client receives no DHCP address | The authorization VLAN/ACL may be wrong or block DHCP. | Inspect RADIUS Access-Accept attributes, the switch session and the DHCP path in the assigned VLAN. |
| Phone works but the attached PC fails | Multidomain host mode or the second identity session may be incorrect. | Inspect voice and data sessions, the LLDP-MED result and port host mode separately. |
| All ports open during RADIUS failure | The critical-auth policy may be overly broad. | Lab-test server-dead versus credential-reject events and record the applied role. |
Acceptance checks
- Classify devices as EAP-TLS, MAB exception or guest.
- Test loss of each RADIUS server independently.
- Confirm that an unknown MAC cannot reach production.
- Restrict DNS, DHCP and application access in each resulting VLAN/ACL.
- Verify that CoA or reauthentication removes a revoked identity.
- Separate success, reject, timeout and fallback events in central logs.
Related concepts
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
Layer 2 and Layer 3 boundaries
A VLAN creates a separate broadcast domain; routing and access policies govern communication between VLANs. Review trunk allowed lists, access-port assignment and gateway placement together. A network diagram should show where packets are routed and filtered, not merely which cables connect devices. Sharing a switch does not require sharing privileges. When access fails, confirm VLAN and addressing first, then gateway, route and policy matching.
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Policy lifecycle
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.