LIVE atabany.net

// PRESALES & SECURITY ENGINEERING CASE STUDY

NAC & Security Operations Proof

Production vendor deployment and self-built security automation for iNetwork Solutions' corporate network. Not a lab exercise: real RADIUS chains, real domain accounts, and a real outage root-caused and fixed along the way. Infrastructure details are described generically here; internal IPs and domain names are intentionally omitted since this runs a live employer network.

PacketFence Aruba RADIUS · 802.1X Active Directory / NPS FreeRADIUS · daloRADIUS Wazuh Shuffle SOAR FortiGate PKI / EAP-TLS

// 01 · NAC ARCHITECTURE

PacketFence + Aruba, End to End

PacketFence sits as a RADIUS broker in front of Aruba Instant wireless infrastructure. When a device authenticates to an SSID, Aruba forwards the RADIUS request to PacketFence, which decides identity, policy, and VLAN role before any traffic flows. Windows AD/NPS is the primary backend; a FreeRADIUS/daloRADIUS tier handles accounts that don't live in AD, so the whole SSID fleet isn't a single point of failure on one directory.

The interesting part is the VLAN assignment: PacketFence doesn't rely on static per-SSID VLAN configuration. It pushes a role-based VLAN back via RADIUS attributes at authentication time: staff, mobile, admin/IT, and guest all resolve to the correct VLAN dynamically, even though the SSIDs themselves are configured generically on the Aruba side.

NAC authentication and dynamic VLAN assignment flow Client device through Aruba wireless controller to PacketFence, chaining AD/NPS and FreeRADIUS backends, with dynamic VLAN assignment returned via RADIUS NAC AUTHENTICATION // DEVICE TO DYNAMIC VLAN CLIENT DEVICE 802.1X / EAP-TLS or PEAP connects to an SSID ARUBA WIRELESS CONTROLLER Auth request forwarded staff · mobile · admin-IT · guest SSIDs PACKETFENCE RADIUS broker + built-in PKI/SCEP policy decision + VLAN role assignment WINDOWS AD / NPS Primary backend Network Policies gated by AD group FREERADIUS + DALORADIUS Fallback backend accounts outside AD dynamic VLAN attribute (RADIUS) // PacketFence assigns VLAN dynamically at authentication time, overriding static per-SSID VLAN settings via RADIUS attributes // RADIUS Accounting is wired end to end for live session state and IP-to-MAC visibility, without touching DHCP on any production VLAN
Diagram 1 of 2: client device through Aruba and PacketFence to the AD/NPS and FreeRADIUS backends, with the dynamic VLAN decision fed back via RADIUS.

// 02 · SECURITY OBSERVABILITY & SOAR

From Telemetry to Automated Response

On top of the NAC layer, a self-hosted security-observability stack correlates telemetry from three independent systems: FortiGate (DHCP leases, UTM device classification, NetFlow), Aruba (EAP auth-trace, roaming events), and PacketFence (its own identity registry) into one normalized device and identity cache. That matters because no single system's data is complete on its own: a device with no AD login still gets fingerprinted from FortiGate/Aruba evidence instead of sitting in an "unidentified" bucket.

Wazuh (SIEM/EDR) generates the alerts; Shuffle is the SOAR layer that turns a critical-severity alert into an automated workflow. The playbook currently ships with a manual-approval gate before any FortiGate block action (a deliberate choice, since an unattended block could outlive the threat it targeted).

Security observability and SOAR automation flow Cross-referenced identity from FortiGate, Aruba, and PacketFence feeding Grafana, and a Wazuh-triggered Shuffle SOAR playbook with a manual-approval gate SECURITY OBSERVABILITY & SOAR // TELEMETRY TO AUTOMATED RESPONSE // 01 CROSS-REFERENCED IDENTITY FortiGate DHCP leases · UTM devtype · NetFlow Aruba EAP auth-trace · roaming events PacketFence identity registry (node ownership) Custom Python exporters cross-referenced identity + device-category cache Prometheus / Loki / Grafana device inventory, per-user traffic, WAN bandwidth // 02 AUTOMATED RESPONSE (SOAR) Wazuh alert critical severity (level ≥ 12) Shuffle webhook SOAR workflow executes Manual-approval gate deliberate: no unattended block by default FortiGate action blocklist entry (next: auto-expiry) // Identity is cross-referenced from three independent sources so inventory doesn't depend on any one system being fully populated // The approval gate is deliberate: an unattended block could outlive the threat it targeted
Diagram 2 of 2: cross-referenced identity feeding Grafana observability (top), and the Wazuh → Shuffle → approval-gate → FortiGate SOAR playbook (bottom).

// 03 · DESIGN DECISIONS

Why Each Choice Was Made

DECISION WHY TRADEOFF ACCEPTED
Layered RADIUS backends AD/NPS covers the domain-joined majority; FreeRADIUS/daloRADIUS covers accounts that will never live in AD (contractors, service accounts). Chaining both means no account type is a second-class citizen on the network. Two backends to keep in sync instead of one; more moving parts during troubleshooting.
Dynamic VLAN via RADIUS, not per-SSID static config Role changes (staff/mobile/admin/guest) happen centrally in PacketFence policy, not by editing every SSID on the controller whenever a role's access needs change. All VLAN logic now depends on PacketFence being reachable and correctly configured; it's a more critical single point than a static SSID setting.
Cross-referenced identity from three sources FortiGate, Aruba, and PacketFence each see a different slice of the truth. Merging them correctly classifies servers, workstations, laptops, and mobile devices without relying on hostnames alone, and gives device-only entries (no login) a real identity instead of dropping them. More integration surface area: three APIs to poll, normalize, and keep in sync instead of trusting one system's view.
Manual-approval gate on the SOAR playbook A Wazuh critical alert can be a false positive. Requiring a human to approve the FortiGate block action before it fires means a bad rule can't silently take a real user or device offline. Slower response than full automation; the tradeoff is intentional until the playbook has proven itself over time.
Certificate-based EAP-TLS via built-in PKI/SCEP PacketFence's own PKI issues short-lived certs for guest self-registration and persistent certs for staff, instead of relying on shared PSKs that can't be revoked per device. Certificate lifecycle (issuance, renewal, revocation) becomes infrastructure that has to be operated correctly, not a one-time setup.

// 04 · INCIDENT CASE STUDY

Root-Causing a Domain-Wide Authentication Outage

A colleague reported being rejected on PacketFence despite valid Active Directory group membership. The obvious suspects (group membership, PacketFence policy, RADIUS config) were all fine. A full system audit (run specifically because a single symptom rarely means a single cause) traced it to the Windows Certificate Authority backing NPS: its server certificate's private key was completely missing, with no recoverable backup anywhere. Confirmed independently with eapol_test run directly against NPS, bypassing PacketFence and Aruba entirely, to prove the certificate itself was the problem before touching anything.

The fix wasn't just "reissue a cert." Rebuilding the CA surfaced two latent misconfigurations that predated the incident and would have caused it to recur: the wrong certificate template was published (non-autoenrollable), and the Autoenroll permission was missing even though "Enroll" looked fine at a glance (they're separate permissions). A disabled Group Policy for certificate autoenrollment domain-wide turned out to be the true root cause underneath both. Fixed all three, then verified the fix the same way it was diagnosed: eapol_test against NPS, confirming a valid certificate before declaring it done.

The same audit also found Default Domain Policy and Default Domain Controllers Policy fully disabled network-wide, unrelated to the certificate issue but sitting there undetected. Checked for policy inheritance conflicts before re-enabling either, confirmed there were none, then verified the fix and ran a clean policy refresh.

// 05 · WHAT THIS DEMONSTRATES

Presales Credibility Backed by Real Delivery

This is proprietary employer infrastructure, so unlike the homelab proof page there's no public repo or live dashboard to click through here. What it demonstrates instead: I don't just propose a vendor architecture and hand it off: I build, operate, and troubleshoot it, across Aruba, FortiGate, Windows AD/NPS, and a self-hosted SIEM/SOAR stack, on infrastructure real people rely on every day. The certificate incident above is the clearest evidence of that: it required reading past the first symptom, verifying each hypothesis independently before acting, and fixing root causes instead of the immediate complaint.