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, and confirm an authentication lands on the dashboard.

Taranac is administered entirely through its web admin UI — a single-page application served by the frontend container that talks to the API over HTTPS. 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 environment you set during install:

Open the frontend URL and sign in with the username and password. If you did not set a password explicitly, retrieve the generated one from the backend log:

./taranac logs api | grep -i admin

After login you land on the Dashboard (/dashboard), the default route for any authenticated session.

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 at least one permit path.

The dashboard is a read-only operational overview. You do not configure anything here — it is where you confirm that traffic is flowing and services are healthy.

The dashboard: infrastructure counts, system health, AAA service status, recent authentication activity, and the alert queue.

The widgets you will lean on most:

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 and status.

Go to Infrastructure → Network → Devices (/network/devices) and create a new device. The form is split into identity on the left and protocols/secrets on the right.

Left column — identity:

Right column — protocol support. Three toggles (TACACS+, RADIUS, NAC) are all on by default 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.

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.

Set the Enabled toggle on (a disabled device is excluded from all AAA/NAC processing — no config is generated for it) and save. The device count on the dashboard ticks up immediately.

You now have a device but a deny-all default policy, so a real login attempt would still be rejected until you add a permit rule. Two ways to validate, from safest to live:

1. Policy tester (no live traffic). Open AAA → Policies → Tester (/aaa/policies/tester). Enter a username, the device you just created, and the request type; Taranac evaluates the rule table and shows you exactly which rule matches and what it returns. Use this to confirm your rules before pointing real gear at the platform.

2. Live request from the device. Configure the network device’s AAA settings to point at Taranac’s TACACS+ port (49 in production) or RADIUS auth port (1812) with the matching shared secret, then attempt a login. Whatever the outcome, it is recorded.

AAA → Policies: the ordered rule table, evaluated top-down with a deny-all default at the bottom.

Check the result under Logging → AAA → Authentication (/logging/aaa/authentication):

The authentication log: every accept and reject with the matched user, device, and reason.

A rejected attempt also surfaces in the dashboard’s Top Failed Auth widget within the polling window. If you see your attempt land — accepted or rejected — the request path is wired correctly end to end. From here, add a permit rule above the default to actually authorize the access you intend.

• Installation — stand the platform up first.
• Architecture — how the API, TACACS+, RADIUS and NAC containers fit together.
• Network devices — the full device model, groups, and shared-secret inheritance.
• AAA policy — building the rule table and using the tester.
• Users & groups and RBAC — managing admins beyond the seeded account.
• Project repository — the deployment bundle and product documentation.