RADIUS

Taranac authenticates and authorizes device administration over RADIUS in addition to TACACS+. Use RADIUS when a network device — or a platform that only speaks RADIUS for admin login — needs to authenticate operators against Taranac and receive an authorization result (a privilege level, a role, a group name) in the Access-Accept reply.

Unlike TACACS+, where the whole policy ruleset is compiled into the tac_plus-ng daemon, all RADIUS policy evaluation runs inside Taranac’s own handler. A RADIUS Access-Request is matched against the same shared AAA policy table you use for TACACS+, then — depending on the matched rule — answered with an Access-Reject, a bare Access-Accept, or an Access-Accept carrying the reply attributes rendered from a RADIUS profile. There is no per-command authorization and no enable concept in RADIUS; authorization is what the device does with the attributes it receives at login.

A template answers “what can this vendor accept?”; a profile answers “what do we grant this operator?”. Templates are reusable across many profiles. A profile that references a template cannot be orphaned — the template is protected from deletion while any profile points at it.

Each template defines:

• defaults — optional service_type, session_timeout, idle_timeout, and reply_message applied when a profile leaves the field blank.
• attributes — a list of attribute definitions, each with a name, optional vsa_type, data_type (string / integer / enum / boolean / ip), and optional static sub-fields for compound values.

A fresh install ships with eight templates covering the common device-administration platforms:

On first install Taranac also seeds ready-to-use profiles — typically a full-access and a read-only variant per vendor (Cisco priv 15/1, NX-OS network-admin/operator, Juniper super-user/operator, FortiGate admin, Palo Alto superuser/superreader, HPE/Aruba 15/1, Huawei 15/3).

Profiles live under AAA → RADIUS → Profiles.

The RADIUS Profiles list — each profile references one vendor template.

A profile form has two columns. The left column holds identity and protocol-level fields:

The right column shows one card per attribute defined in the chosen template. The input widget follows the attribute’s data_type: text for string/ip, a number field for integer, a toggle for boolean. Compound attributes (static fields) render one input per {placeholder} in the pattern — for example a single Privilege Level input that produces shell:priv-lvl=15.

A raw attributes editor at the bottom lets you append attributes that are not part of the template — each is a name plus value (with optional vendor_id and vsa_type), value capped at 253 characters. This is how you add standard attributes such as Filter-Id on top of a vendor profile, or build a complete reply on the Generic template.

Templates are created through a four-step wizard (Basic info → Defaults → Attributes → Review). Step one fixes the slug (immutable after creation; locked when editing, suffixed -copy when duplicating), the display name, the vendor string, and the integer vendor_id (0–99999). Step two sets the optional defaults. Step three builds the attribute list, including static fields with their patterns and typed sub-fields. Step four reviews the result as YAML/JSON. In most cases the eight built-in templates are enough — define a new one only for a vendor or attribute layout Taranac doesn’t ship.

When an Access-Request arrives, Taranac:

1. Looks up the user and checks eligibility (exists, active, not locked). A failure here is an immediate Access-Reject with a fixed message (User not found, Account disabled, Account locked).
2. Evaluates the AAA policy table — first matching enabled rule wins across the WHO, WHERE, SOURCE, and WHEN dimensions. Rules whose RADIUS action is none are skipped. Policy evaluation happens before the password is checked, so the matched rule can declare whether MFA is required.
3. Verifies the password (local bcrypt or LDAP bind), optionally challenging for MFA.
4. Acts on the matched rule’s RADIUS mode.

If no rule matches, the request is implicitly rejected (No matching policy). A default catch-all rule (high order, WHO = any) guarantees every request gets an explicit answer.

For profile mode, Taranac renders the profile’s attributes in this fixed order, resolving each value as profile value → template default → omit:

1. Service-Type
2. Session-Timeout
3. Idle-Timeout
4. Reply-Message
5. Template attributes — compiled static fields, then any per-attribute raw values, then simple values
6. Raw attributes not tied to the template

Resolution detail worth knowing:

• A timeout of 0 is sent (it explicitly disables the timeout); a blank field falls back to the template default, and only a value that is absent at both levels is omitted.
• An empty Reply-Message is treated as “not set” and is not sent.
• A static field whose required inputs are all blank is skipped; a multi-value static field (e.g. NX-OS roles) emits one attribute instance per value.

A worked example — a Cisco IOS profile with privilege 15, a 7200-second session timeout, and a raw Filter-Id, against a template whose defaults are Login-User / 3600 / 600 — yields:

Service-Type     = Login-User      # blank profile field → template default
Session-Timeout  = 7200            # profile override
Idle-Timeout     = 600             # blank profile field → template default
Reply-Message    = Welcome, admin  # profile value
Cisco-AVPair     = shell:priv-lvl=15
Filter-Id        = ADMIN_ACL       # raw attribute

RADIUS and TACACS+ share one ordered policy table (AAA → Policies). Each rule carries an independent action per protocol: a single rule can, for example, grant a TACACS+ profile and a RADIUS profile, or apply to only one of them.

One ordered policy table drives both protocols; each rule has independent RADIUS and TACACS+ actions.

The matching dimensions are shared:

• WHO — users and/or groups (or “any”).
• WHERE — devices and/or device groups (or “any”).
• SOURCE — the calling station’s network. RADIUS does not support the console-only source option; that is a TACACS+ concept and such a rule never matches a RADIUS request.
• WHEN — always, or a time range (overnight ranges supported).

To grant RADIUS access, set a rule’s RADIUS action to profile and pick the profile; use auth_only to authenticate without sending attributes, or deny to refuse the matched population.

Use the Policy tester to dry-run a hypothetical login (user, device, source, time) and see which rule wins and which RADIUS profile it would apply, without sending real traffic.

• Cisco IOS admin vs read-only. Two profiles on the Cisco IOS template (priv-lvl=15 and priv-lvl=1), bound to two rules whose WHO targets your admin and operator groups.
• Juniper role mapping. A profile returning Juniper-Local-User-Name = remote-su (super-user) or remote (operator); the named local user template must already exist on the JunOS device.
• Mixed estate, one rule. A single rule with WHERE = a device group, granting a TACACS+ profile to Cisco gear and a RADIUS profile to the RADIUS-only platforms in the same group.
• Authenticate without authorizing. A rule in auth_only mode for appliances that handle their own role mapping but still want central credential checks.
• Standard-attribute-only device. Build the reply on the Generic template using raw attributes (e.g. Service-Type, Session-Timeout, Filter-Id).

Prefer TACACS+ for network gear where you want per-command accounting and authorization or an enable workflow. Use RADIUS for devices and platforms that authenticate administration only over RADIUS (many firewalls, controllers, and appliances), or where a simple privilege/role attribute at login is all that’s needed.

Profile fields

Per-protocol policy fields

• AAA overview
• TACACS+ profiles
• AAA policies
• Network devices
• Deployment bundle: github.com/TaranacLabs/taranac