TACACS+

TACACS+ is how Taranac controls administrative access to your network gear — the routers, switches, firewalls and other devices your engineers log in to. It separates authentication (who you are), authorization (what you may do once logged in) and accounting (a record of what you did), and it can authorize individual commands, which is what makes it the standard choice for device administration.

In Taranac, TACACS+ and RADIUS share one identity store, one set of network devices and one AAA policy table. Use TACACS+ when an admin opens a shell on a device (SSH, Telnet or console) and you want to grant a privilege level, restrict commands, or keep a per-command audit trail. Use RADIUS for endpoint network access (802.1X, MAB) and for platforms that do their administration over RADIUS instead.

Taranac models TACACS+ authorization with three linked objects plus the privilege/enable chain. Everything is bound to users and devices through the policy table — you build the objects once and reference them from rules.

When an admin authenticates, Taranac evaluates the AAA policy table top to bottom, first match wins. Each rule matches on four dimensions — WHO (user or group), WHERE (device or device group), SOURCE (network the admin connects from, or the physical console) and WHEN (always, or a time range). The first rule whose conditions all match determines the TACACS+ action:

• profile — apply the named shell/authorization profile (priv-lvl, command set, etc.)
• auth_only — authenticate the login but apply no authorization profile
• deny — reject, with an optional message returned to the device
• none — the rule does not apply to TACACS+ (it may still act on RADIUS)

The default catch-all rule sits last and denies everything, so anything not explicitly permitted is rejected.

For privilege escalation, Taranac resolves the enable mode by walking a chain and taking the first non-inherit value:

User → Group → Profile → Global setting (tacacs.global_enable_mode)

Modes are:

The TACACS+ objects live under the AAA section of the admin UI. The usual order is: pick or create a template, build any command sets you need, create the profiles that carry the values, then bind profiles to users/devices in the policy table.

A template fixes the attribute schema for a vendor/platform. Most operators never create one — the built-in templates already cover the common platforms. Open one to see the services it defines (typically shell) and the attributes available on a profile built from it. Two template capabilities matter when you build profiles:

• Enable Password — whether the platform supports TACACS+ privilege escalation.
• Command Authorization — whether the platform supports per-command authz, and the match style (regex, exact, or prefix) used to compare command arguments.

Each attribute in a template also declares two things that reach a profile:

• its separator — RFC 8907 distinguishes attr=value, which the device must implement or else refuse the whole authorization, from attr*value, which the device may ignore. The template declares which one the platform expects and the generated configuration sends exactly that.
• whether it is required — a required attribute is marked with a red * in the profile form and cannot be saved empty.

A command set is where you express “this role may run these commands and not those.” Each row is a command (for example show) with a permit/deny action and an optional args sub-list of patterns that refine the match. Rules are evaluated in order, and a command no rule matches falls through to the attached profile’s Default Command Action — which is permit on a new profile. So a read-only set is a few permits plus a profile whose default command action you set to deny.

Command sets: ordered permit/deny rules with optional per-argument patterns.

Each command row supports:

• a command to match (e.g. show, configure),
• a permit/deny toggle,
• optional permit/deny messages returned to the device,
• an args list, each entry an action plus a match pattern (regex or exact string, per the template’s match style).

Taranac seeds one starter command set — read-only (show, ping, traceroute and exit permitted) — which you can use as-is or clone.

A profile binds it all together: it references a template, supplies the attribute values (for the shell service this includes priv-lvl), optionally attaches a command set with its default command action, and configures the enable mode and timeouts.

Profiles: each entry references a template and carries the values applied on a policy match.

Key profile fields:

• Template — selects the form/attribute schema.
• Service attributes — values per service (e.g. priv-lvl on shell); the input type follows the attribute’s data type (text, number, enum select, or toggle).
• Command Set — shown only when the template supports command authorization, together with the Default Command Action (permit or deny) applied to commands the set does not match. A new profile starts at permit, so it works the moment it is attached and you narrow it afterwards.
• Enable Password — inherit, login_password, or custom (custom stores an encrypted secret, revealed on demand by an authorized operator).
• Session timeout, idle timeout — optional.
• Raw AV-pairs — a freeform escape hatch for vendor-specific attributes the template does not model. A raw pair naming a service the template already defines is merged into that service’s block (and overrides a templated attribute of the same name) rather than getting a block of its own.

Taranac seeds four ready-to-use profiles, including General Full Access (priv 15) and General Read-Only (priv 1). These are seeded once; your edits and deletes survive a container rebuild.

Profiles do nothing until a policy rule references one. In the policy table, add a rule, set its WHO/WHERE/SOURCE/WHEN conditions, set the TACACS+ action to profile, and pick the profile. Rules are first-match-wins, so order them from most specific to most general; the default deny stays last.

The AAA policy table: first-match-wins rules mapping WHO/WHERE/SOURCE/WHEN to a TACACS+ (or RADIUS) action.

Before rolling a change out, simulate it with the policy tester: supply a username, a device IP, the protocol, the source and a time, and Taranac shows which rule matches and which profile (and command set) would apply. This catches ordering mistakes without touching a live device.

Policy tester: simulate a request and confirm which rule and profile would win.

Read-only NOC operator. Create (or reuse) a read-only command set that permits show and a few diagnostics. Put it on a profile with priv-lvl 1, enable mode deny, and the default command action set to deny so everything the set does not permit is refused. Add a policy rule: WHO = the NOC group, action = profile.

Full network admin with enable. Use the seeded General Full Access (priv 15) profile, or one like it, with no command set (or a permissive one) and enable mode login_password (re-uses login credentials) or inherit (defers to the group/global setting). Policy rule: WHO = the network-admins group.

Restrict configure / show running-config. In a command set, add explicit deny rows for configure and for show with an args pattern matching running-config, placed above the broader permits. Because matching is first-match-wins within the set, the denies win for those commands while everything else stays permitted.

Per-device-group privilege. Build two profiles (e.g. full vs. read-only) and two policy rules with the same WHO but different WHERE (device groups), e.g. full access on lab devices and read-only on production. Order the more specific rule first.

Console fallback. Add a rule with SOURCE = console to apply a specific profile (or an explicit deny) when an admin connects on the physical console rather than over the network. Console is a TACACS+-only source dimension.

Command sets vs. shell-profile attributes. Use priv-lvl (a profile attribute) for coarse, device-enforced levels — it’s simplest and needs no per-command round-trips. Reach for a command set when you need finer control than the privilege level gives you (allow some commands but not others at the same level) and the platform supports command authorization. Many roles use both: a privilege level plus a command set that trims it.

Templates vs. per-profile configuration. Templates define structure and are mostly a one-time, per-platform concern; profiles hold the values you tune. Don’t create templates to express role differences — that’s what profiles and command sets are for. Create or edit a template only when a vendor/platform or attribute the shipped templates don’t model.

Privilege level vs. command authorization.

TACACS+ vs. RADIUS for device administration.

Profile fields exposed in the UI:

Command-set fields:

Enable-chain modes (first non-inherit wins, evaluated User → Group → Profile → Global): inherit, login_password, custom, deny, and permit (profile level only).

• AAA overview — what TACACS+ and RADIUS each cover.
• Network devices — devices, device groups and shared secrets.
• AAA policy — the first-match rule table that binds profiles to users and devices.
• RADIUS — RADIUS profiles and vendor-specific attributes.
• Taranac on GitHub — the deployment bundle and product documentation.