Roadmap
Taranac has been moving in one direction the whole time: taking control of network access away from scattered device configs and giving it to a single policy core. First the commands people run on devices, then the way devices get onto the network at all, then the identities behind both — and now the devices themselves, as things the platform knows rather than just talks to.
This page is that line, drawn out. Above the marker is what has shipped; below it are the directions we’re building toward.
TacacsGUI
Before Taranac there was TacacsGUI — a free web interface for TACACS+ that ended up running in thousands of networks. It solved a real problem, and in solving it, it showed where the ceiling was: a front end wrapped around one daemon can make that daemon easier to configure, but it can’t decide anything. Policy, identity and device knowledge stayed scattered across config files.
The old site is still online as a frozen archive.
Taranac — a new concept
Not a new version of the old thing — a new one. New concept: the platform owns identity, devices and policy, and the protocol engines answer from that core instead of each keeping its own truth. New architecture: separate engines for TACACS+, RADIUS and 802.1X, one shared store, one policy table. New modules built around that core rather than bolted onto a daemon. And a new approach to shipping — containers, versioned releases, an upgrade path.
The name changed with the scope: TACACS+ was no longer the whole story.
config rendered to a shared volume · in-memory caches refresh ~30s
The base platform
The first public release, and already a full platform rather than a preview:
- Core — users and groups, role-based access, settings, audit trail, SMTP and syslog, LDAP / Active Directory as an identity source.
- TACACS+ device administration — built on Marc Huber’s
tac_plus-ng, driven by Taranac policy: per-command authorization, vendor profiles, full session logging. - RADIUS AAA — FreeRADIUS with a Taranac policy module, so both protocols answer from the same rules. Ports 1812 / 1813.
- 802.1X NAC — its own FreeRADIUS instance, in its own container on ports 1814 / 1815, so network access and device administration never contend for the same daemon: endpoints, MAB, dynamic VLAN assignment.
- Captive portal and PKI — guest onboarding, an internal CA, EAP-TLS certificates.
- MFA — including Taranac’s own push app, with TOTP that keeps working offline.
High availability
Authentication is the kind of service where an outage is measured in people who can’t work. So Taranac learned to run as a cluster: PostgreSQL managed by Patroni with automatic leader election and failover, and a lightweight etcd witness so a two-node partition can’t split-brain.
Each node answers AAA from its own local replica, which is the part that matters — TACACS+, RADIUS and 802.1X keep serving straight through a primary crash, and writes resume on the new primary. An existing single node converts into a cluster in place.
Configuration Tracker
The platform started knowing what devices are, not just what they let people do. Point a tracked config at a device, pick a recipe of commands, and Taranac captures versioned snapshots on a schedule — with scrub sets masking secrets before anything is stored, content-hash dedup, side-by-side diffs and baseline tags.
Two pieces arrived underneath it that matter more than the feature itself. Collectors: the built-in one for a flat network, and standalone collectors that dial out to the core for segmented or remote sites — no inbound path to open. And a credentials vault that mints just-in-time logins for a single privileged run, so the long-lived secret never leaves it.
- hostname
- network10.20.0.201/24
- timezone
- password
Virtual appliance
One file instead of an afternoon. The OVA / qcow2 appliance imports into any hypervisor, asks four questions on first boot — hostname, network, timezone, admin password — and brings the whole stack up offline, from images already baked into the disk.
No registry is contacted at any point, which is what makes it usable in closed
segments. Underneath it is the same bundle as a manual install, so the same
./taranac commands and the same upgrade path apply afterwards.
Reports
Taranac has always held the data worth reporting on — sessions, endpoints, devices, authentication logs, configuration history. Reporting is what gets it out of the screens and into something you can send to someone.
The model is preset-first. A report is assembled from ready-made sections over a time range and a filter, and comes out as a branded PDF — or CSV / XLSX for the raw tables. You can shape a raw table into a bar, line or pie and reorder pages, but that flexibility isn’t the point: the value is that the presets sit on top of data no one else has in one place — identity, device, configuration and session, already joined. Scheduling and delivery reuse the platform’s existing scheduler and mail machinery.
The reports people ask for first tend to be evidence: access reviews, MFA coverage, configuration drift.
SNMP collector
A new capability on the collector that already ships — not another thing to deploy. The same agent that collects configurations learns to walk devices over SNMP and turn what it finds into facts: vendor and model, hardware serials and their lifecycle dates, port and VLAN inventory, and the neighbour tables that make topology fall out for free.
The same walk enriches endpoints too — forwarding and ARP tables show hosts that never authenticated through us and would otherwise be invisible. Values fill fields that are empty and never overwrite what an operator typed, and every field carries a note of where it came from. Traps arrive as alerts, so the picture updates on events rather than only on the next poll.
Network map
Two layers that complete each other. The NAC layer is already queryable today: every session records which endpoint sat on which device, on which port, in which VLAN — so the map of who is connected where can be drawn from data Taranac has been writing all along. The SNMP layer adds the part AAA can’t see: the backbone, the stacks, the devices that never authenticate to anything.
What makes it ours isn’t the topology. It’s that every node and link carries an authorization verdict — authenticated and by what method, MAB bypass, rejected, never seen — so the map is coloured by trust. Click a node and you get its configuration history, its sessions and its neighbours in one place. A topology tool can’t do that; it has no idea who anyone is.
Network scanner
Collectors already live inside the L2 segments, which is the hard part of scanning. The scanner uses that position to sweep a segment — across VLANs, at layer 2 — and compare what is actually there against what has authenticated. Its job is one question: trusted or not?
The case it exists for is the quiet one. A port where 802.1X was never switched on, in a VLAN that everything else in it has earned, with a device on the end that nobody vouched for. Nothing is broken, no alarm fires, and no report shows it — because the device never talked to us at all. The scanner sees it because it looks at what is present, not at what authenticated, and every host it finds lands in one of three buckets: authorized, seen but never authenticated, or untrusted.
It reports; it doesn’t enforce. What you do about a finding stays a decision for a person and for policy. And because these segments can contain industrial equipment that aggressive probing knocks over, passive discovery is the default — active scanning is opt-in per subnet, with windows, rate limits and exclusions, configured on the collector where that decision belongs. The same fingerprints feed device profiling, which is what turns “this is a printer” into the VLAN a printer gets.