NAC policy

NAC policy is where you decide what access a device or user gets once it has proven who it is. 802.1X authentication answers who connected (a corporate laptop with a certificate, an employee over PEAP, a printer over MAB). NAC policy answers what they may reach — which VLAN they land in, which ACL is enforced, and whether they are redirected to a portal first.

In Taranac these are two distinct steps. The authentication layer verifies the identity (EAP, certificate, or MAC). The policy layer then evaluates an ordered list of rules, picks the first one that matches, and returns the authorization result the switch should apply. Everything on this page is configured under the Policies section of the admin UI — there is no need to touch RADIUS or any switch CLI by hand.

An authorization profile is the result of a policy decision — the bundle of access you grant when a rule permits a device. Profiles are vendor-agnostic: you describe the intent (a VLAN, an ACL name, a set of ACL lines, a redirect URL), and Taranac renders the correct RADIUS attributes for whichever switch the request came from (see the Vendor Dictionary note below). A profile can carry any combination of:

The two timers are mutually exclusive. Both render into Session-Timeout and differ only in the Termination-Action that goes with it, so a profile that sets both is refused on save rather than letting one silently override the other.

Profiles are always a permit result. A reject is expressed on the rule itself, not as a profile (see below).

Profiles live under Policies → Authorization Profiles. The list can be filtered by VLAN — “which profiles drop an endpoint into VLAN 40” without paging through it — and shows how many rules use each profile; a profile a rule names cannot be deleted until the rule stops naming it.

A policy rule maps a set of conditions to an action. Rules live in one ordered table and are evaluated top to bottom — first match wins. As soon as a rule’s conditions all match, its action is applied and evaluation stops.

A rule’s action is either:

• Permit — apply the referenced authorization profile (returns Access-Accept with VLAN / dACL / redirect attributes).
• Reject — return Access-Reject with no attributes (no profile).

Beyond its conditions and its action a rule carries a name, an optional description, and an Enabled toggle — a disabled rule is skipped during evaluation as though it were not there. A rule can also require MFA. On 802.1X that is push only, and it is offered neither for MAB nor for a reject rule; see 802.1X authentication for what satisfies it.

Each rule matches on up to five condition dimensions. Within a single dimension the list is OR (any member matches); across dimensions the logic is AND (every configured dimension must match):

Any dimension can be left as “any”, which makes it not participate in matching.

One ordering trap is worth knowing before you build the table, because it produces a policy that tests fine and misbehaves later.

A WHO condition is only true when a user authenticated. A WHAT condition is true whenever the endpoint is in the group — with or without a user. So a rule matching on an endpoint group also matches sessions that do have a user, while a rule matching on a user group can never match one that does not.

That makes the endpoint-group rule the broader of the two, and broader rules belong lower. Put a device-conditioned rule above a user-conditioned one and it takes both, and every authenticated user silently receives the access you designed for unattended devices.

This bites hardest with 802.1X machine authentication, where the same port authenticates twice — once as a computer with no user, once as the user. See Machine authentication and SSO.

The table always ends with a locked default rule (lowest priority). It is a catch-all that fires when nothing above it matched. By default it is a reject, so an unrecognized device gets no access unless an earlier rule explicitly grants it. It sits in its own card below the list. You cannot delete, disable or reorder the default rule, but you can change its action — for example, point it at a guest-redirect profile instead of rejecting.

Open Policies → Policy Table. Each row is a rule, in priority order. The table puts a heading over each run of consecutive rules sharing an authentication method (PEAP, MAB, EAP-TLS, and so on), but it remains a single flat, ordered list — the grouping is only for readability, and a method whose rules are not adjacent gets more than one heading.

Reorder rules by dragging; the rule that should win for overlapping conditions must sit higher. Dragging is switched off while a filter is active, so you can never reorder a subset of the list and corrupt the real order. Each row also offers insert rule above / below, duplicate, and the enable toggle.

The NAC policy table — ordered rules, first match wins, with the locked default at the bottom.

For each rule you set:

1. How — the authentication method (or any).
2. Who / What / Where / When — the condition dimensions. Leave any of them as “any” to ignore that dimension.
3. Action — permit (then choose an authorization profile) or reject.

The What dimension is built on endpoint groups. Group membership is what lets you write a single rule like “any device in Printers → restricted VLAN” instead of listing MAC addresses. Endpoints land in groups either by manual assignment or automatically through classification rules — by OUI, vendor name, MAC pattern, certificate, hostname, or the machine’s place in a directory and the directory groups it belongs to.

Endpoint groups — referenced by the “What” condition of a rule.

Discovered devices appear under Endpoints, where you can see which groups each one belongs to before you reference those groups in policy.

Endpoints discovered via RADIUS, LDAP sync, and manual import.

A permit result is made of three independent levers. Use them alone or in combination.

The switch places the authenticated port (or MAC, in multi-auth mode) into a specific VLAN. This is the coarsest and most widely supported control — segmentation happens at the switch. Configure it by setting a VLAN ID on the profile.

Under the hood this is the standard RADIUS VLAN tunnel triple, which Taranac emits for every vendor:

Tunnel-Type            = VLAN
Tunnel-Medium-Type     = IEEE-802
Tunnel-Private-Group-ID = 100

A downloadable ACL pushes the access-control rules from Taranac to the switch as part of Access-Accept — you do not have to pre-define them on every switch. Enter the rules as an ordered ACL lines list on the profile, for example:

permit udp any any eq 53
permit tcp any any eq 443
deny   ip  any any

dACLs give per-session, granular filtering on top of (or instead of) a VLAN. They are vendor-dependent — Taranac renders them where the switch supports them (for example Cisco’s ip:inacl# AV-pairs, or Juniper / Huawei filter attributes). Where a vendor offers only role-based access (such as Aruba user roles) or no dACL at all, use a named ACL (an ACL already defined on the switch, referenced by name) or rely on VLAN segmentation instead. The Policy Tester’s per-vendor preview shows exactly what each switch would receive.

A URL redirect sends the session’s web traffic to a portal — typically a captive portal for guest registration, BYOD onboarding, or an acceptable-use prompt. A redirect profile usually combines three things: a holding VLAN, the redirect URL, and a redirect ACL that defines which traffic is intercepted (web) versus allowed through (DNS, the portal itself). URL redirect is the most vendor-specific result of the three: in the shipped Vendor Dictionary only Cisco IOS / IOS-XE declares it. On a switch without it, fall back to a dedicated guest VLAN whose gateway forces the portal.

The three levers stack. Common combinations:

• VLAN only — simplest; segmentation handled by the switch.
• VLAN + dACL — a broad VLAN plus fine-grained per-session filtering.
• VLAN + redirect (+ redirect ACL) — a holding VLAN that bounces the user to a portal before granting real access.

You author one profile by intent and Taranac maps it to the right attributes per switch vendor via its built-in Vendor Dictionary. A single “Printers — VLAN 300, ACL PRINTERS-ONLY” profile therefore works across Cisco, Aruba, Juniper, Mikrotik and the rest — the renderer produces the correct VLAN, dACL or role attributes for whatever NAS sent the request. The vendor is detected from the request’s attributes, or taken from the device record. You can inspect and extend the dictionary under Policies → Vendor Dictionary.

An extra attribute on a profile is sent by name, exactly as you typed it, with no vendor mapping — and the 802.1X service can only send a name it can look up. The FreeRADIUS dictionaries it ships with are large (around 8500 attributes across 195 vendors) but do not carry everything a vendor defines, and a profile referring to a name that is not there used to produce nothing at all, with no error anywhere.

Settings → NAC therefore has an Attribute dictionary card. 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 as an extra attribute on an authorization profile, and it goes out in the Access-Accept. VALUE lines work too. What already exists, beside the editor, opens a searchable list of what the service already ships — worth a look first, since a name that already exists is refused on save. A mistake is refused with its line number in your own text, and saving restarts the 802.1X service automatically (under a second): FreeRADIUS parses dictionaries once, before it reads its configuration, so a reload would apply nothing. The dictionary is capped at 64 KB.

Each service keeps its own: the one on Settings → NAC is not shared with the device-administration dictionary on Settings → RADIUS.

When you change policy, devices that are already connected keep whatever authorization they were granted at connect time — RADIUS Access-Accept is a one-time event. To push a new decision to a live session, the switch must be told to re-evaluate. That mechanism is Change of Authorization (CoA): Taranac sends a RADIUS CoA packet to the switch on UDP 3799, and the switch acts on it.

Taranac does not silently re-push policy to every live session the instant you edit a rule. CoA in the current release is an operator-initiated action plus some automated session housekeeping — not an automatic blanket re-authorization on every policy edit. The CoA actions available are:

• Logging & Reports → NAC Logs → Sessions — per-session Disconnect, Re-authenticate, Change VLAN… and Bounce Port. This is the only surface with explicit CoA actions.
• Blocking an endpoint disconnects its live sessions via CoA as a side effect, so the block takes hold without waiting for the device to reconnect. Bulk block deliberately skips that step — see Endpoints.
• The captive portal fires a CoA re-auth of its own once a guest registers, which is what moves the device out of the registration VLAN.

Changing an endpoint’s groups sends nothing — neither a manual reassignment nor a classification change. That is a session teardown, and the decision is left to you.

An acknowledged Disconnect does not drop the session row on the spot. Taranac waits for the switch’s Accounting-Stop so the session is archived with its final counters; if no Stop arrives within a grace window (30 seconds by default), a background job closes it and records it as an admin disconnect rather than as a stale session. The same job covers a guest session revoked or expired by the captive portal. It sends nothing to the network — session liveness is read from accounting and never by asking the switch, which is described in the NAC overview.

The job is NAC Session Finalize (pending disconnects), runs every 10 minutes by default, and is listed under System → Workers. Since 1.2.8 turning it off persists: it is a stored setting rather than a pause held in the scheduler’s memory, which used to be forgotten on the next container restart.

Corporate laptop → employee VLAN. PEAP or EAP-TLS rule with How = PEAP/EAP-TLS and Who = employee user group (or What = a corporate-devices endpoint group for machine auth). Action: permit → a full-access profile with the employee VLAN.

Unknown device → guest VLAN + captive portal. A low-priority MAB rule whose What is an unknown/unclassified group (or the default rule) → permit a Guest-Redirect profile: a registration VLAN plus a redirect to the captive portal. After the visitor registers, their endpoint moves into a guest group and the portal’s own CoA re-auth drops them into the real guest VLAN.

Printer (MAB) → restricted dACL. Classification rules put the printer’s MAC into a Printers endpoint group (by OUI/vendor). A How = MAB, What = Printers rule permits a profile with a restricted VLAN and a print-only dACL (allow print/discovery ports, deny the rest).

Quarantine for non-compliant devices. Put the affected endpoints in a Quarantine group and add a high-priority rule What = Quarantine → permit a remediation profile (isolated VLAN, dACL allowing only patch/AV servers), or reject outright. Moving an endpoint into the group and re-authenticating its session from Sessions quarantines a live device immediately.

Rules of thumb:

• Start with VLAN assignment for everyone; it is the most portable.
• Add a dACL (or named ACL) when a VLAN is too coarse and you need device-class-specific filtering (printers, IoT, cameras).
• Use redirect only for onboarding/guest flows, and always pair it with a holding VLAN and a redirect ACL.
• When mixing vendors, lean on VLAN + named ACL for the common denominator and reserve dACL/redirect for the platforms that support them — the Policy Tester’s per-vendor preview will tell you what each switch actually gets.

• NAC overview — how NAC differs from AAA.
• 802.1X authentication — EAP-TLS, PEAP, EAP-TTLS and MAB (the who).
• Endpoints — endpoints, groups and classification rules (the what).
• Captive portal — guest, BYOD and AUP onboarding flows.
• Internal PKI — certificates for EAP-TLS.
• Deployment bundle: github.com/TaranacLabs/taranac