Quick start

This walkthrough assumes the platform is already up (see Installation). In about fifteen minutes you will log in as the initial administrator, get oriented with the objects Taranac ships pre-populated, register your first network device, authorize one login, and watch that authentication land in the log.

Taranac is administered entirely through its web admin UI — a single-page application the browser reaches over HTTPS on the edge reverse proxy (ports 80/443). The frontend container renders the SPA internally and publishes no port of its own. There is no separate CLI for day-to-day work; everything below is done in the browser.

On first start the backend seeds exactly one account if the user table is empty: the initial admin. Its credentials come from the .env values written during install:

Open https://<your-domain>/ and sign in. If you walked away from the installer’s completion screen, read the password back from the bundle directory — and if it has already been changed and lost, reset it from the console:

grep '^INITIAL_ADMIN_PASSWORD=' .env    # what the installer generated
./taranac reset-password admin          # forgotten, or already changed
./taranac unlock admin                  # locked out by failed attempts

After login you land on the Dashboard (/dashboard) — the landing route for every authenticated session, and never permission-gated. An account without the dashboard:view permission still lands there and gets a welcome splash instead of the widgets.

Taranac is usable out of the box because the backend seeds a working baseline on first start. These objects are visible and editable in the admin UI from the moment you log in. Knowing they exist saves you from rebuilding things by hand.

The default AAA policy denies everything, and the default NAC policy rejects everything not matched by a more specific rule. This is deliberate: nothing is authorized until you say so. Your job in the next steps is to add a device and one permit path.

The dashboard is a widget canvas, not a fixed overview. It is where you confirm that traffic is flowing and services are healthy — and you can rearrange it to say what you care about.

The dashboard: system and service health, the alert queue, resource meters, infrastructure counts and AAA activity — every card a widget you can move, resize or hide.

There are 21 widgets in the catalogue and all of them are on by default, each at the narrow (S) width, so the first thing you see is a uniform compact grid. Press Customize in the page header to enter edit mode: drag a card by its handle to reorder, click its width button to cycle S → M → L, hide the ones you do not want, re-show them from the Hidden widgets tray, then Save. The layout is stored per user (with Reset to default to start over), and a widget you have no permission for is dropped from the canvas entirely rather than shown empty.

The ones you will lean on first:

A device in Taranac is one network access server — a switch, router, firewall, VPN concentrator, or access point — that sends TACACS+ or RADIUS requests. The device record holds the shared secret(s) the daemon uses and declares which protocols it speaks. Until a device exists with a matching IP and secret, the daemons reject its requests.

Infrastructure → Network → Devices: the device inventory with protocol badges, group membership and status.

Go to Infrastructure → Network → Devices (/network/devices), press Add Device, and fill the form. It is split into identity on the left and protocols/secrets on the right.

Left column — identity:

Group membership is editable from this form as well as from the group’s own members panel — you do not have to open the device group to add a device to it.

Right column — protocol support. Three toggles (TACACS+, RADIUS, NAC) are all on for a new device and decide which secret fields appear:

• TACACS+ → a TACACS+ Key field plus a Single Connection toggle (reuse one TCP session for all requests from this device).
• RADIUS or NAC → a RADIUS Secret field (NAC rides on RADIUS).
• NAC → a CoA block: CoA Secret, CoA Port (typically 3799 per RFC 5176, or 1700 on legacy Cisco), and an optional Vendor Dictionary selector that pins how CoA actions are encoded for this device.
• TACACS+ also carries a collapsed Login Banners block — a per-device Welcome Banner and MOTD Banner. Leave both empty and the device inherits them, from a device group first and then the global TACACS+ setting. Banners are set here and at group/global scope, not on a TACACS+ profile.

For each secret field you can type a value, click the eye icon to reveal a stored one, or use the key icon to generate a strong secret.

Press Create Device. The device count on the dashboard’s Infrastructure widget ticks up on its next refresh.

You now have a device, but the only policy rule is the deny-all default — a real login would be rejected. Give yourself exactly one permit path.

AAA → Policies → Policy Table: the ordered rule table, evaluated top-down, first match wins, with the deny-all default pinned at the bottom.

Open AAA → Policies → Policy Table (/aaa/policies) and press Add Rule. A new rule is always created above the default, which stays at order 9999 and can be edited but never deleted or moved. Fill in:

Press Create Rule. Nothing else is needed for the shell to work: a TACACS+ profile’s command default is permit — on the seeded profiles and on any new profile you create — so commands are allowed unless a command set says otherwise. Attach the seeded read-only command set later, when you want to restrict what may be typed.

Two ways to validate, from safest to live:

1. Policy tester (no live traffic). Open AAA → Policies → Policy Tester (/aaa/policies/tester). Choose the protocol (TACACS+ or RADIUS), enter the username — it must be a user that exists, or the tester answers User not found — the NAS IP of the device you just created, optionally a source IP, and for TACACS+ the access type (remote or console). You can also simulate a time. Taranac evaluates the real rule table and answers with Rule #N matched or No rule matched, the resolved context, and exactly what the match returns. The tester never touches the daemon.

2. Live request from the device. Configure the network device’s AAA settings to point at Taranac’s TACACS+ port (49, or 6049 for TACACS+ over TLS, which is enabled by default) or the RADIUS auth port (1812) with the matching shared secret, then attempt a login. See Device configuration for the vendor CLI side. Whatever the outcome, it is recorded.

Check the result under Logging & Reports → AAA Logs → Authentication Log (/logging/aaa/authentication):

The authentication log, with separate TACACS+ and RADIUS tabs: every accept and reject with the user, device, network object, remote address, action and node.

A rejected attempt also surfaces in the dashboard’s Top failed auth (24h) widget. If you see your attempt land — accepted or rejected — the request path is wired correctly end to end.

• Installation — stand the platform up first.
• Architecture — how the eleven containers fit together, and which ports they listen on.
• Network devices — the full device model, groups, banners and shared-secret inheritance.
• AAA policy — building the rule table and using the tester.
• TACACS+ — templates, profiles, command sets and the command default.
• Device configuration — what to type on the switch so it talks to Taranac.
• Users & groups and RBAC — managing admins beyond the seeded account.
• Project repository — the deployment bundle and product documentation.