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 in RADIUS, and the protocol has no enable exchange at all; authorization is what the device does with the attributes it receives at login. Devices that escalate privilege through the vendor $enab<N>$ convention are answered separately — see Privilege escalation (enable).

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 fifteen 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 static field with no placeholders is not a parameter but one alternative in a menu — PAN-OS hangs superuser, superreader and deviceadmin off a single attribute. Where the template does not mark that attribute multi-valued, the alternatives render as a radio group, and a profile carrying more than one of them is refused on save: three conflicting roles in one Access-Accept is nothing a device can act on.

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. An entry may be identified by name or by numbers alone: a numbered one is sent as Attr-26.<vendor_id>.<vsa_type> for a VSA and Attr-<vsa_type> for a standard attribute, which is how FreeRADIUS addresses an attribute it knows by number. An entry with neither a name nor a number cannot be addressed at all and is skipped with a warning in the RADIUS service log.

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 fifteen built-in templates are enough — define a new one only for a vendor or attribute layout Taranac doesn’t ship.

A profile can only send an attribute the RADIUS service can name, and the FreeRADIUS distribution dictionaries — around 8500 attributes across 195 vendors — do not carry everything a vendor defines. Settings → RADIUS has an Attribute dictionary card for the rest: paste the vendor’s own dictionary text into it, verbatim.

VENDOR          Example                 32473
BEGIN-VENDOR    Example
ATTRIBUTE       Example-Policy-Id       1       string
END-VENDOR      Example

Once saved, the name can be used like any other attribute — as a raw attribute on a RADIUS profile — and it goes out in the Access-Accept. VALUE lines work too, so an attribute can have named values instead of bare numbers. The card lists back what your text declares.

• The text is stored as you typed it, so it stays comparable line for line with the vendor’s file. A mistake is refused on save and named with its line number in your own text, not in the file the service reads.
• What already exists, beside the editor, opens a searchable list of the vendors and attributes the service already ships — filterable by attribute name or vendor. A name that already exists is refused on save; a new name that reuses a number already in use is accepted and then quietly takes the original’s place in what the service reports.
• Saving restarts the service automatically (under a second): FreeRADIUS reads dictionaries only at start-up.
• The dictionary is capped at 64 KB, and each RADIUS service keeps its own: device administration (Settings → RADIUS) and 802.1X (Settings → NAC) do not share one.

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 credential — how depends on what the device sent; see Credential transports — optionally challenging for MFA.
4. Acts on the matched rule’s RADIUS mode.

A privilege-escalation request is recognised before step 1 and takes none of these steps — see Privilege escalation (enable).

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.

There is nothing to choose here: the branch is picked from what the device actually sent.

Neither of the two unsupported transports counts towards the brute-force guard — a protocol mismatch says nothing about anyone’s password, and one misconfigured NAS must not be able to lock every administrator off a device.

Which NT hash MS-CHAPv2 uses is decided by the user’s own account, never by an installation-wide switch:

• Local accounts — Taranac keeps the NT hash alongside the argon2id one. An account whose password has not been saved since NT hashes were introduced has none, and is rejected with mschap_no_nt_hash until the password is re-saved.
• Active Directory — unicodePwd is write-only and readable by nobody, so the response can only be verified by a domain controller, through the machine account this installation holds. The node must be joined and MS-CHAPv2 enabled on that LDAP configuration; at most one configuration may own the domain.
• A directory that publishes the hash — FreeIPA creates ipaNTHash for every user, so verification is a search plus the same arithmetic used for local accounts: no domain join, no winbind, and no exclusivity. A node can hold a domain join and any number of hash-readable directories at once, and neither borrows the other’s verifier. MS-CHAPv2 is switched on for such a directory the moment its configuration is created. One operator action is still required — ipaNTHash sits in an explicit exclusion list even in the administrator’s own ACI, so the bind account needs an ACI granting it read access. Setting that up, and the Check directory button that reports whether the hash is readable, are on the LDAP / Active Directory page. A missing ACI is reported as exactly that, never as a wrong password, and never counts towards the brute-force guard.

The hash is read on each login and cached nowhere.

RADIUS has no protocol form for privilege escalation, but a family of platforms — Cisco IOS / IOS-XE, Cisco Business, H3C Comware 7, Eltex ESR — sends one anyway, as an ordinary Access-Request whose User-Name is the synthetic $enab<N>$. It names no person, so there is no account to look up, no group, no policy rule and nothing for MFA to apply to.

Taranac recognises that name and answers it against a global enable password on Settings → RADIUS, beside the shared secret and behaving the same way: revealed on request with the reveal recorded in the audit log, copied, regenerated, saved only when changed. It is generated at first boot, so the feature is never live with a blank password — change it before handing it out. One password serves every privilege level, because the level is carried by the username and the request identifies nobody else. A successful escalation is answered with a bare Access-Accept — no reply attributes, since a login profile’s timeouts mean nothing for an escalation.

Escalations appear in the authentication log as themselves: an enable → 15 badge beside the synthetic name, with the request type and requested level in the detail panel. A request that arrives with no enable password configured is rejected as enable_not_configured, not as a wrong password.

Equipment that sends the operator’s real name for an escalation (Aruba AOS-S, Cisco ASA, AOS-CX 10.15 and later) is answered as an ordinary login, which is what it is — and granting the privilege level at login, where the user is known, remains the stronger arrangement.

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
• LDAP / Active Directory — directory setup, including what MS-CHAPv2 needs from a directory
• Deployment bundle: github.com/TaranacLabs/taranac