Network devices

A network device in Taranac represents a single network access server (NAS) — a switch, router, firewall, VPN concentrator, or access point — that sends TACACS+ or RADIUS requests to the platform. A device record tells Taranac three things: where the NAS lives on the network (its IP), which secret to use when talking to it, and which protocols it participates in (TACACS+, RADIUS, NAC, or any combination).

Devices are also one half of the WHERE dimension in AAA and NAC policy: a policy rule can match on an individual device or on a device group, so you decide which administrators can do what on which equipment. This page covers registering devices, organising them into groups, the network objects that anchor their addresses, and — most importantly — how shared secrets and login banners are inherited along the device → group → global chain.

You manage all of this under Infrastructure → Network in the admin UI.

Open Network → Devices and click Add Device. The form is split into an identity column and a protocol/secrets column.

The Devices list: name, network object, vendor/platform, enabled protocols, location, status, group count, and a Used by badge showing what references the device.

Identity fields

Protocol support. Three toggles — TACACS+, RADIUS, and NAC — declare which protocols this device speaks. All three are on by default. They gate which secret fields appear:

• TACACS+ on → shows the TACACS+ Key field and the Single Connection toggle.
• RADIUS or NAC on → shows the RADIUS Secret field (NAC rides on the RADIUS protocol, so it reuses the RADIUS secret).
• NAC on → shows a CoA Settings block with CoA Secret, CoA Port, and an optional Vendor Dictionary selector.

A device with a protocol disabled is left out of that protocol’s generated daemon config entirely.

Single Connection (TACACS+ only): when enabled, the device reuses one TCP session for all authentication, authorization, and accounting exchanges.

Enabled toggle: a disabled device is excluded from all AAA/NAC processing — no config is generated for it and no daemon reload references it.

The TACACS+ Key, RADIUS Secret, and CoA Secret fields all behave the same way and are stored encrypted at rest:

• Leaving a secret empty means “inherit” — the device falls back to its group, then to the global default (see below). The device’s Details card names the level each inheritable field actually resolved from: the device itself, a named group, the global setting, or nothing set anywhere.
• On an existing device, a stored secret displays as a placeholder (••••••••). Submitting it unchanged keeps the current value; clearing it to empty removes the override (falling back to inheritance); typing a new value replaces it.
• The reveal (eye) action decrypts and shows a secret in plain text. This is audit-logged — every reveal records who looked and when.
• The generate action opens a generator to create a strong random secret.
• Secrets may contain letters, digits, and most punctuation, but not spaces, single/double quotes, backticks, backslashes, ?, or $.

When NAC is enabled, the CoA block configures how Taranac pushes Change-of-Authorization or disconnect packets to the device:

• CoA Secret — encrypted; inherits like any other secret if left empty.
• CoA Port — an integer 1–65535. Typical values are 3799 (RFC 5176) or 1700 (Cisco legacy). Leaving it empty inherits the group/global value, and if nothing is set anywhere Taranac uses 3799 as the built-in default.
• Vendor Dictionary (CoA) — selects how CoA attributes are encoded. Leave it empty to auto-detect from the device’s vendor.

Open Network → Device Groups to create a group, then attach devices to it. A group has a name, optional description, its own TACACS+ Key / RADIUS Secret / CoA Secret / CoA Port, its own Welcome and MOTD banners, and tags. Members are managed on the group’s edit page (add or remove devices); membership changes are saved together with the rest of the form.

Membership can also be written from the device side: the device form carries a Device Groups picker, so linking a device no longer means leaving it and opening the group. Both directions produce the same audit trail.

Groups serve two purposes:

1. Shared defaults. Set a secret once on the group and every member device that has no per-device override inherits it.
2. Policy granularity. A policy rule can reference a whole group instead of listing devices one by one.

A device can belong to multiple groups. Deleting a group does not delete its member devices — it only removes the membership links. A group that is named by an AAA or NAC policy rule cannot be deleted at all until the rule stops referring to it (see References and deletion below).

Every secret (TACACS+ key, RADIUS secret, CoA secret, and CoA port) — and each login banner — resolves along a fixed three-level chain. The first level that has a value wins:

Device  →  Device group  →  Global default

• Device level — a value set directly on the device always takes precedence.
• Group level — if the device has no own value, Taranac walks the device’s groups oldest group first (ordered deterministically by creation time) and uses the first group that has a value.
• Global level — if neither the device nor any group supplies a value, the global system setting is used.

The global defaults live in system settings:

CoA port and CoA secret are resolved independently along the same chain — a device can pick up its secret from a group while still taking the global (or default 3799) port if no level sets one.

TACACS+ can put two pieces of text in front of an operator logging in to a device, and they are separate settings because they ride in different packets and therefore reach different people:

• Welcome Banner — prepended to the first login prompt, so anyone who can reach the port sees it before entering a credential. A legal notice belongs here.
• MOTD Banner — carried in the reply that grants the login, so only someone who authenticated sees it. Relaying it is the device’s choice: Cisco IOS prints it, Arista EOS discards it in favour of its own “Last login” line.

Each one can be set at three levels — on the device, on a device group, and globally under AAA → Settings → TACACS+ — and every device resolves them along the same device → oldest device group → global chain, with the same creation-time ordering, that the TACACS+ key already uses. The two banners resolve independently: a device that overrides only the MOTD still takes its welcome banner from a group or from the global setting.

On both the device form and the device-group form the two fields sit in a collapsed Login Banners block — on the device side it appears only when TACACS+ is enabled for that device. The block opens by itself when a banner is already stored, so an override never hides behind a closed section, and the device’s Details card names the level each banner resolved from.

Banners are display text, not secrets, so they are stored and shown in the clear. Each field holds up to 4096 characters and multi-line text is fine — line breaks survive to the terminal. One sequence is refused when you save: a literal ${, which in the generated tac_plus-ng configuration is a syntax error rather than text and would stop the whole file from loading — one device’s banner taking AAA down for the entire fleet.

Banners are a TACACS+ mechanism; RADIUS has no equivalent. A banner also cannot be a per-profile setting, because a profile is chosen during authorization while a banner rides in the authentication reply — see TACACS+ profiles & command sets.

AAA and NAC policy rules use devices to answer “on which equipment does this rule apply?” — the WHERE dimension. A rule can target:

• Specific devices — pick individual NAS records, or
• Device groups — match every member of a group.

Pairing this with the source dimension (network objects = the client’s IP) and the when dimension (time ranges) lets you write rules such as “network engineers may run show/config commands on the core-switches group, on weekdays, from the NOC subnet.” See AAA policy for how the WHERE dimension combines with identity, source, and time conditions.

Devices, device groups and network objects are all referenced by other objects, and Taranac refuses to delete one out from under a reference rather than cascading or failing opaquely. Each list carries a Used by column; clicking the badge opens a where used panel that separates references you must detach first from those that clear themselves:

The panel lists each blocker by name with a link to it, so “detach it first” is a click rather than a search.

One global key, a few exceptions. Set tacacs.global_key once. Every device inherits it. For the handful of legacy boxes that need a different key, set the key directly on those devices — they override the global value while everything else keeps inheriting.

Per-vendor CoA. Create groups aruba and cisco. Put CoA port 3799 on the first and 1700 on the second. Add each controller to the right group. CoA pushes now use the correct port per vendor with no per-device configuration.

Site-specific RADIUS secret. Create a group per site (site-emea, site-apac), set the RADIUS secret on each, and add the site’s devices. Devices inherit the site secret; a device that needs its own secret simply sets one and overrides the group.

Decommissioning. Disable a device (uncheck Enabled) to pull it out of all config generation without deleting its record or history. Delete it only when you no longer need the audit trail.

Devices, device groups, and network objects can all be exported and imported (XLSX, CSV, or JSON), with an explicit opt-in to include decrypted secrets in the export — every export is audit-logged, including whether secrets were included. The device sheet covers identity, address, protocol flags, the TACACS+ key and RADIUS secret, and group names; the CoA fields and the login banners are not part of it.

• AAA policy — how devices and device groups drive the WHERE dimension.
• TACACS+ profiles & command sets — the global TACACS+ settings, and why a banner is not a profile field.
• Project repository