AuthHound

Access-Accept · Filter-Id / role not applied

RADIUS Filter-Id not applied: the ACL name the NAS quietly ignores

The device authenticates, gets its Access-Accept, and then has the wrong access (too much or too little) even though your RADIUS policy clearly returns a Filter-Id. The trap is a single fact people forget under pressure: RADIUS sends the name of an ACL, never the ACL itself.

1. The named filter doesn’t exist on the NAS

Filter-Id (and its vendor cousins, Cisco-AVPair ip:inacl and Aruba-User-Role) is a reference by name to a filter that must already be configured on the switch, firewall, or controller. If that name isn’t defined on the box, behavior is vendor-specific and never obvious:

  • some platforms deny all traffic for the session,
  • some ignore the attribute and apply nothing,
  • some fall back to a default role.

Either way the RADIUS side “authenticated fine.” Check: does an ACL/role with that exact name exist on the NAS the device connected to?

2. The name doesn’t match exactly

The match is literal and usually case-sensitive. GUEST_ACL ≠ guest_acl ≠ GUEST_ACL (trailing space from a copy-paste). Some platforms also use a direction suffix convention (.in / .out) that must be present, or must be absent. Check: compare the returned string byte-for-byte against the configured name; watch for whitespace and case.

3. It exists on some of your gear, not all

On a mixed or multi-site estate, the same policy returns the same Filter-Id to every NAS, but the ACL is only defined on the switches where someone configured it. Result: correct enforcement in one closet, wide-open (or locked-out) in another, from one unchanged RADIUS policy. Check: confirm the filter/role is pushed to every NAS the policy can reach, ideally from config management, not by hand.

4. Wrong mechanism for the platform

Filter-Id is the RFC-standard way, but some platforms only honor their vendor attribute for downloadable/named ACLs. Cisco expects Cisco-AVPair ip:inacl#1=... for per-user entries, Aruba expects Aruba-User-Role. Returning the standard Filter-Id to gear that only reads its own VSA is a silent no-op. Check: match the attribute you return to what that vendor’s OS version actually consumes.

The one diagnostic that settles it

On the NAS, read the session’s applied policy directly, e.g. show authentication sessions interface <if> details (Cisco) or the equivalent client/role view on your platform. It shows the ACL/role name the NAS received and whether it resolved it to a real filter. A name received but unresolved is cause 1 or 2; nothing received is a policy-side problem (the attribute never left the server; confirm with radiusd -X or the NPS reply attributes).

Prove what the server actually returned: the open-source authhound-probe prints every authorization attribute in the Access-Accept and asserts the one you care about, so a silently ignored attribute becomes a hard FAIL. 

export AUTHHOUND_RADIUS_SECRET='shared-secret'   # not in argv or shell history
authhound-probe radius test --server radius.corp.com --peap alice --expect-attr Filter-Id=staff

Recipe: assert returned attributes with --expect-vlan / --expect-attr

Have the full log open? Paste it here

The analyzer recognizes 55 common failure signatures and ranks the likely causes for your specific output. It runs entirely in your browser; nothing is uploaded.

Related failures

In the attribute reference

  • Filter-Id

    Filter-Id (attribute 11) returns the name of a filter or ACL that must already exist on the NAS; RADIUS is selecting it by name, not sending the rules.

  • Cisco-AVPair

    Cisco-AVPair is a string VSA (vendor 9, attribute 1) that carries Cisco features as "attribute=value" pairs: the vehicle for dACLs, URL redirects, and privilege levels that no standard RADIUS attribute expresses.

  • Aruba-User-Role

    Aruba-User-Role is a string VSA (vendor 14823, attribute 1) that puts a session into a named Aruba role. Like Filter-Id, it selects policy by name; the role has to exist on the controller.

This failure is usually invisible until users complain. AuthHound is building continuous monitoring that catches it first. Early access:

No spam, no sharing: one email when it's ready, and you can reply to be removed anytime.