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:

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

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).

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. You cannot delete 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 groups rules visually by authentication method (PEAP, MAB, EAP-TLS, and so on), but it remains a single flat, ordered list — the grouping is just for readability. Reorder rules by dragging; the rule that should win for overlapping conditions must sit higher.

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, LDAP computer sync, and so on).

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 and is supported on a subset of platforms (for example Cisco IOS / IOS-XE); on switches 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.

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:

• Active Sessions (under Logging → NAC) — per-session Disconnect, Reauth, Bounce port and VLAN change actions.
• Endpoints — a CoA re-auth quick action on an endpoint affects its live sessions; this is also fired automatically when you reassign an endpoint’s groups or block it, so a regroup or block takes effect without waiting for the device to reconnect.

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 a 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 firing CoA re-auth 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