DEV Community

Gerus Lab
Gerus Lab

Posted on

We Ditched Cisco ISE for a Docker-Based NAC — Here's What Happened

We Ditched Cisco ISE for a Docker-Based NAC — Here's What Happened

For years, Network Access Control meant one thing: Cisco ISE. It was the industry standard, the safe choice, the tool every enterprise security team knew by heart. But "safe" doesn't mean "cheap", and it definitely doesn't mean "easy to maintain".

At Gerus-lab, we build custom infrastructure for clients ranging from SaaS startups to enterprise networks. Over the past year, we've been experimenting with container-based alternatives to traditional NAC solutions — and the results surprised us.

This is an honest write-up of that journey: why we reconsidered Cisco ISE, what we found, and the practical lessons from running a Docker-based NAC in a real lab environment.


The Problem With "Enterprise" NAC

If you've ever deployed Cisco ISE, you know the drill:

  • Licensing costs that make your CFO cry
  • Heavyweight VM requirements (8 vCPUs, 300GB disk minimum for a basic deployment)
  • Complex upgrade paths that require maintenance windows and careful planning
  • Steep learning curve — the ISE UI feels like it was designed by committee in 2009

For large enterprises with dedicated network security teams, ISE makes sense. But for mid-market companies or projects where infrastructure agility matters, it's often overkill.

So we started asking: what does a modern, cloud-native NAC look like?


Enter the Container-Based NAC

The architecture we tested was built around a microservices approach — multiple Docker containers, each handling a specific function:

┌─────────────────────────────────────────────────────┐
│                  NAC Platform                       │
├─────────────┬──────────────┬────────────────────────┤
│  Core API   │  RADIUS/EAP  │  Web GUI               │
│  (Central   │  (Auth       │  (Admin                │
│  Management)│  Engine)     │  Interface)            │
├─────────────┴──────────────┴────────────────────────┤
│  DHCP Probe  │  Profiling   │  PostgreSQL DB         │
│  Collector   │  Engine      │                        │
└─────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Each component is independently restartable, updatable via a single command (docker pull + docker-compose up -d), and the whole stack runs on a modest VM — 4 vCPUs and 8GB RAM is sufficient for lab/SMB use.

Compare that to ISE's minimum specs and you're looking at a 10x reduction in resource overhead.


Setting It Up: Honest Assessment

Installation

The deployment experience was surprisingly smooth. OVA image → import → boot → pseudographic console for basic network setup (IP, timezone, DNS, NTP). First login brings you to a web dashboard.

Initial container startup takes a few minutes, but once it's running, the management console at port 8000 gives you:

  • Container status and restart controls
  • Backup/restore for the PostgreSQL database
  • TLS certificate management
  • Session TTL configuration

One thing we missed from ISE: no built-in CSR generation. You still need to openssl req -new -key ... the old-fashioned way. Minor annoyance, but worth noting.

Integrating with Active Directory

# The NAC connects to AD using a pre-created computer account
# This is different from ISE which uses service accounts
# Make sure the computer object exists in AD before configuring

# Test connectivity before saving:
ping dc.yourdomain.local
nslookup yourdomain.local
Enter fullscreen mode Exit fullscreen mode

The AD integration worked cleanly once we remembered the gotcha: the system authenticates via a machine account (not a service account like ISE does). The computer object must exist in AD before you configure the integration. Documentation covers this, but it's easy to miss.

RADIUS and 802.1X

This is where things got interesting. We set up a test lab with:

  • 1x managed access switch
  • 1x Wi-Fi controller + AP
  • Windows and Linux endpoints

The 802.1X flow for corporate devices:

Client → [RADIUS Request] → NAC
NAC → [LDAP Query] → Active Directory  
NAC → [Access-Accept + VLAN assignment] → Switch
Switch → [Port configured to VLAN 10] → Client gets network access
Enter fullscreen mode Exit fullscreen mode

MAC Authentication Bypass (MAB) for devices that don't support 802.1X (printers, IoT, etc.) worked as expected. The profiling engine collects DHCP fingerprints to identify device types automatically — similar to ISE's profiling but lighter weight.

Dynamic VLAN Assignment

The policy engine lets you assign VLANs based on:

  • User group membership (from AD)
  • Device type (from profiling)
  • Authentication method (802.1X vs MAB)
  • Time of day / location tags
// Example policy logic (simplified)
{
  "condition": {
    "user_group": "Domain Admins",
    "auth_method": "802.1X",
    "device_type": "workstation"
  },
  "action": {
    "vlan": 10,
    "acl": "full-access"
  }
}
Enter fullscreen mode Exit fullscreen mode

This covers 80% of real-world NAC use cases.


TACACS+ for Network Device Administration

This deserves its own section because it's often overlooked. While RADIUS handles endpoint authentication, TACACS+ handles network device administration — controlling who can SSH into your switches and what commands they can run.

We found a small gotcha here too: TACACS+ support is disabled in device profiles by default. You need to enable it manually in the profile settings before you can configure credentials on individual devices. Not a blocker, just a "read the docs" moment.

Once configured:

# SSH to managed switch
ssh admin@switch.local

# TACACS+ authentication chain:
# Switch → NAC → AD → response
# Full command logging enabled
Enter fullscreen mode Exit fullscreen mode

Command authorization and accounting both worked cleanly.


Where It Falls Short (Honest Takes)

We're not going to pretend this is a 1:1 Cisco ISE replacement for Fortune 500 environments. Here's what's genuinely missing or immature:

1. Certificate management UX — TLS cert configuration lives in a separate admin console instead of the main interface. It works, but it's clearly a temporary architectural decision the team acknowledges they'll fix.

2. Posture assessment — ISE's posture module checks endpoint compliance (antivirus status, patch level, disk encryption). The container-based alternative doesn't have this yet. If you need posture checks, this is a deal-breaker.

3. Scale testing — Our lab had <50 devices. We haven't stress-tested this at enterprise scale (10,000+ endpoints). If you're at that scale, validate thoroughly before production deployment.

4. Ecosystem maturity — ISE has 15 years of integrations, playbooks, and community knowledge. A newer solution has a fraction of that. You're more likely to hit undocumented edge cases.


The Economics

Let's talk numbers (rough estimates for a 500-device deployment):

Cisco ISE Container NAC
Licensing $15,000–$50,000/yr $0–$5,000/yr
Hardware/VM High-spec dedicated servers Standard VM (4 vCPU, 8GB)
Implementation 40–80 hours 10–20 hours
Ops overhead High (complex upgrades) Low (one-command updates)

For the right environment, the TCO difference is significant.


Our Recommendation

Choose a container-based NAC if:

  • You're an SMB or mid-market company (up to a few hundred devices)
  • Infrastructure-as-code and container-native tooling are already in your stack
  • Budget is a real constraint
  • You need to get something running fast
  • You don't need advanced posture assessment

Stick with ISE (or similar) if:

  • You're at enterprise scale (1000+ devices)
  • Compliance requirements demand ISE-certified integrations
  • You need mature posture assessment
  • You have an existing ISE investment and team expertise

What We're Building

At Gerus-lab, we've started incorporating container-based NAC as an option in our infrastructure projects — particularly for clients who are modernizing legacy networks or building greenfield environments.

The shift toward microservices-based security tooling is real. ISE isn't going anywhere, but the assumption that "enterprise security" requires "enterprise-priced monoliths" is being challenged from multiple directions.

If you're evaluating NAC options or rethinking your network security architecture, we'd love to talk. We document our experiments and share the honest results — both wins and failures.

→ Check out our infrastructure work at gerus-lab.com

→ See our security and DevOps projects: gerus-lab.com

→ Reach out if you're navigating a similar challenge: gerus-lab.com


TL;DR

  • Cisco ISE is powerful but expensive, heavy, and operationally complex
  • Container-based NAC platforms offer a credible alternative for SMB/mid-market
  • Docker architecture means one-command updates, low resource overhead, and clean separation of concerns
  • Main gaps: no posture assessment, less ecosystem maturity, unproven at large scale
  • For the right environment, TCO savings are substantial

Have you migrated away from traditional NAC? What did you use? Drop it in the comments — we're always comparing notes.

Top comments (0)