AAA policy

The AAA policy is the shared decision engine for device administration. Every TACACS+ and RADIUS request that reaches Taranac is evaluated against one ordered list of rules. The engine walks the list top to bottom and stops at the first rule that matches — that rule decides whether the session is permitted, which profile (command set, privilege level, RADIUS attributes) is applied, and whether MFA is required.

Because evaluation is first-match-wins, rule order is the policy. A broad rule placed near the top will shadow more specific rules below it. The list always ends with a single, undeletable default rule that catches everything not matched above — so there is no such thing as “no decision”.

aaa · policy

tacacs noc-op core-sw · 10.0.0.5 · Tue 11:05

WHOWHERESOURCEWHENACTION

1. 1 noc Any Any 22–06 profile ✗
2. 2 noc Any Any 09–18 profile ✓
3. · Any Any Any Always deny

permit rule 2 profile: read-only

The AAA policy table: ordered rules with WHO / WHERE / SOURCE / WHEN conditions and per-protocol actions, with the default rule pinned below the separator.

A rule has four match dimensions and two independent action columns (one for TACACS+, one for RADIUS). A rule matches a request only when all four dimensions match; the action column for the request’s protocol then decides the outcome.

Dimension	Question it answers	What you select
WHO	Which identity is authenticating?	”Any user”, or a set of users and/or groups
WHERE	Which network device (NAS) is the request coming through?	”Any device”, or a set of devices and/or device groups
SOURCE	How / from where did the session originate?	”Any source”, a set of source networks, or “console” (TACACS+ only)
WHEN	At what time is the request happening?	”Always”, or a named time range

Each rule carries the following beyond its dimensions:

• Description — an optional free-text label shown in the table. (Rules are identified by their order and description; there is no separate “name” field.)
• Order — the rule’s position in the list; lower runs first.
• Enabled — a disabled rule is skipped entirely during evaluation, as if it were not present.
• MFA — off or required. When required, the matched session must satisfy multi-factor before the action is applied (subject to global MFA being enabled and the user having an enrolled provider).

WHO. With “Any user” off, the rule matches if the authenticating user is directly listed or belongs to any listed group. Group membership is resolved at evaluation time, so adding a user to a group immediately changes which rules they hit.

WHERE. With “Any device” off, the rule matches if the NAS is directly listed or is a member of a listed device group. Devices defined as a subnet or range also match when the NAS IP falls within their network object — so you can target a whole management subnet with a single device entry.

SOURCE. This dimension describes where the client session comes from:

• Source networks — match when the client’s source IP is contained in one of the selected network objects (host, subnet, or group; ranges are not offered here).
• Console — a TACACS+-only checkbox that matches sessions arriving on a device’s console/AUX port rather than over the network.

WHEN. “Always” matches at any time. Otherwise you pick one time range — a reusable schedule of weekday + start/end windows (overnight windows like 22:00–06:00 are supported). Times are interpreted in the system timezone (set under system settings), not UTC, so “09:00–18:00” means business hours in your timezone regardless of where the server runs.

Each rule sets a mode for TACACS+ and, independently, for RADIUS:

Mode	Meaning
none	This rule does not handle this protocol. Evaluation continues to the next rule for that protocol.
deny	Explicitly deny access for this protocol. Optional message returned to the client.
auth_only	Permit, but assign no profile — authentication succeeds with no attributes/authorization. Optional message.
profile	Permit and apply a named profile (full attribute / command-set / privilege injection).

The none mode is what lets a single list serve both protocols. A rule can, for example, apply a TACACS+ command-set profile while leaving RADIUS at none, so RADIUS requests pass straight through to rules below.

A deny or auth_only rule may carry a message: for TACACS+ this is shown on the terminal (multi-line banners allowed); for RADIUS it becomes the Reply-Message (capped at 253 bytes by the protocol).

Exactly one rule is the default (catch-all). It is pinned below a separator at the bottom of the list and is special:

• It cannot be deleted or reordered — it is always last.
• Its WHO / WHERE / SOURCE are locked to “Any” and WHEN to “Always”, so it matches every request that nothing above caught.
• Out of the box it ships as deny all (TACACS+ deny with message “Access denied by default policy”, RADIUS none).

This is a deny-by-default design: access is only what your rules explicitly grant. You may change the default’s actions and message, but not its conditions.

Open AAA → Policy. The table lists all rules in evaluation order; the default rule sits under the divider.

1. Add a rule. Click to create a rule. The form is organised as the four dimensions plus the two action columns. Toggling a dimension to “Any” clears and hides its selectors.
2. Set conditions. For each dimension, either leave it on “Any” or pick the specific users/groups, devices/device groups, source networks, or time range. Selectors let you create the referenced object inline if it does not exist yet.
3. Set actions. Choose a mode per protocol. Pick a profile for profile mode, or type an optional message for deny / auth_only.
4. Choose MFA. Tick “require MFA” if this rule’s sessions must pass multi-factor.
5. Place the rule. New rules can be inserted at a chosen position; “Insert above”/“Insert below” on existing rows put the new rule exactly where you want it. You can also reorder later by dragging rows.

Rows can be expanded to inspect the resolved profile and the membership of any selected group or device group (read-only).

Since the first match wins, place rules from most specific to most general:

1. Explicit denies and break-glass exceptions first. A “lock out contractor group everywhere” rule must sit above any rule that would otherwise grant them access.
2. Narrow grants next. Rules scoped to specific devices, source networks, or time windows.
3. Broad grants after. “All network engineers get the standard profile on all devices.”
4. The default rule last (it is pinned there automatically) — deny-all backstop.

A useful test: if rule B is a strict subset of rule A’s conditions, B must come before A, or it can never fire.

Read-only NOC during business hours. WHO = group noc; WHERE = Any; SOURCE = Any; WHEN = time range business-hours; TACACS+ = profile (a read-only command set); RADIUS = none. Outside the window this rule does not match, so the user falls through to whatever comes next (often the deny-all default).

Full admin from the jump host only. WHO = group network-admins; WHERE = Any; SOURCE = source network jump-hosts; WHEN = Always; TACACS+ = profile (privilege 15). Because SOURCE is set, keep RADIUS = none — RADIUS could never satisfy the source restriction anyway. Order this above the read-only NOC rule if admins are also NOC members.

Console always works (break-glass). WHO = Any; WHERE = device group core; SOURCE = console; WHEN = Always; TACACS+ = auth_only or a profile. Placed near the top, this guarantees physical console access even if network paths are misconfigured.

RADIUS Wi-Fi admin onboarding to switches. WHO = group wifi-admins; WHERE = device group access-switches; SOURCE = Any; WHEN = Always; RADIUS = profile; TACACS+ = none. Mirrors the TACACS+ rules but on the RADIUS column.

Service account, permitted but silent. Combine an auth_only rule for a monitoring account with a log exclusion (below) so the constant polling does not flood the logs.

Situation	Use mode
Grant access with a specific privilege / command set / attributes	profile
Permit the login but assign nothing (rare; e.g. a NAS that authorizes itself)	auth_only
Block this identity/scope outright, with a message	deny
This rule is only about the other protocol — let this one fall through	none

The policy tester simulates a request against the live rules and shows exactly which rule wins and why, without touching production traffic. Use it after every non-trivial change.

The policy tester: enter a simulated request and read back the winning rule, resolved action, MFA/enable chain, and a per-rule pass/fail trace.

Enter the request parameters:

Field	Notes
Protocol	tacacs or radius — selects which action column is evaluated.
Username	The identity to test (must exist; an unknown user returns a “user not found” result).
NAS IP	The device the request arrives through, for WHERE matching. Omit it and only “Any device” rules can match.
Source IP	The client IP, for SOURCE matching. Omit it and only “Any source” rules can match.
Access type	remote or console (TACACS+ only) — drives the console SOURCE check.
Timestamp	The simulated time for WHEN matching. “Now” fills the current local time; a timezone badge shows which timezone applies. Leave blank to use the current server time.

The result shows:

• A banner — green for a permit, red for a deny or unknown user, yellow when no rule matched.
• The winning rule and its resolved action (mode + profile name).
• The MFA chain (whether MFA is enforced, the user’s resolved provider, or a warning if MFA is required but the user has no provider) and, for TACACS+, the enable-password chain showing which level resolved it (user / group / profile / global).
• The resolved context — the effective username, NAS, source, time, and access type used.
• A full evaluation trace: every rule that was examined, marked match, skip, or disabled, each expandable to a per-dimension pass/fail breakdown (e.g. “user ‘admin’ is member of matching group ‘network-admins’”). This is the fastest way to find a rule that fires too early or never fires.
• Warnings — notably the RADIUS-SOURCE caveat described above.

Log exclusions are a separate list (under the same AAA area) that suppress noisy-but-expected traffic from the logs — monitoring pollers, backup accounts, automation — without affecting access decisions. They are matched independently of the policy rules and apply to both protocols by default.

Each exclusion matches on:

• Identity — by exact username, a username_pattern wildcard (e.g. svc-*), or a user_group.
• NAS filter (optional) — any, a network_object, or a device_group.
• Protocol — all, tacacs, or radius.

And controls, independently, which event types to suppress (authentication, authorization, accounting) and where to suppress them:

Destination	Default	Effect
Database	suppressed	Keeps the event out of the UI logs table.
Syslog	kept	Whether the event is still forwarded to external syslog.
Alerts	suppressed	Keeps the event from raising alerts.

• TACACS+ profiles & command sets — the profiles you assign in profile mode.
• RADIUS profiles — the RADIUS attribute profiles assigned by rules.
• Network devices — devices and device groups used in WHERE.
• Users & groups and MFA — the identities and second factor evaluated by WHO and the MFA flag.
• Logging & accounting — where excluded and kept events land.
• Project repository