802.1X authentication

802.1X authentication is the who and how of network access control: before a switch or access point opens a port, the device — or its user — has to prove an identity. Taranac runs a dedicated FreeRADIUS instance for NAC (separate from the AAA RADIUS used for device administration) that terminates the EAP exchange, checks credentials or certificates against your identity stores, and hands the result to the NAC policy engine, which decides what access to grant (VLAN, ACL, redirect).

This page covers the four methods Taranac supports — EAP-TLS, PEAP, EAP-TTLS and MAB — how each behaves, which identity store and certificates each needs, and when to pick which. Authorization (profiles and rules) lives on the NAC policy page.

nac · method classification

Access-Request EAP + inner-tunnel ttls

marker peap → peap
marker ttls → eap_ttls
EAP + client cert → eap_tls
no EAP → mab

tagged eap_ttls → policy evaluation

How Taranac tags a request: ordered detection rules match on RADIUS signals and assign one method (here, an inner-tunnel ttls marker yields eap_ttls) before policy evaluation.

The four methods at a glance

Method	Proves identity with	Inner method	Works for directory users	Needs client cert	Needs NT-hash
EAP-TLS	Client X.509 certificate	— (cert only, in the TLS handshake)	Yes	Yes	No
PEAP	Username + password	EAP-MSCHAPv2	A directory that can prove an MS-CHAPv2 response — Active Directory (domain join) or FreeIPA (`ipaNTHash`)	No	Yes — stored for local users, read live for FreeIPA, never seen for AD
EAP-TTLS	Username + password	PAP, MSCHAPv2, or EAP-MSCHAPv2 — all three	Yes — any directory type (over PAP)	No	Only on the MSCHAPv2 inner methods, where it behaves exactly like PEAP
MAB	MAC address only	—	n/a	No	No

A single Taranac NAC server offers all four at once. The supplicant on the endpoint chooses the EAP method; MAB is the fallback when no supplicant answers. Each request is tagged with its detected method (eap_tls, peap, eap_ttls, mab), and policy rules match on that tag.

Key concepts

Supplicant — the 802.1X client on the endpoint (Windows native client, wpa_supplicant on Linux, the macOS/iOS/Android built-in client). It selects the EAP method and presents the credential or certificate.
Authenticator — the switch or access point (a NAS) that brokers EAP between the endpoint and Taranac over RADIUS, and enforces the result on the port.
Identity store — where Taranac verifies the credential: the local user directory, or an external LDAP directory — Active Directory, OpenLDAP, FreeIPA or another LDAP server.
EAP tunnel — PEAP and EAP-TTLS first build a TLS tunnel (the endpoint validates Taranac’s server certificate), then carry the password inside it. EAP-TLS has no inner tunnel: the certificate exchange in the TLS handshake is the authentication.
Qualified identities — a supplicant may send the login as DOMAIN\alice or alice@domain.example. Taranac tries the name exactly as sent first, and a qualified name may then only ever resolve to a directory account. Before 1.2.2 the qualifier was stripped and matched against local accounts too, so ANY_PREFIX\alice was a free alias for the local alice — invisible in the log, which named the bare account either way. The log still records the string the client sent, because for MS-CHAPv2 that string is part of the cryptogram; the account it resolved to is what policy uses. Applies to PEAP and EAP-TTLS alike.
MAB (MAC Authentication Bypass) — for devices with no supplicant. The switch sends the endpoint’s MAC address as the username; Taranac looks it up in the endpoint inventory instead of checking a credential.

EAP-TLS — certificate-based

EAP-TLS authenticates with a client certificate during the TLS handshake itself. There is no password and no inner tunnel: the endpoint presents an X.509 certificate, FreeRADIUS validates it against the trusted-CA bundle, and Taranac extracts the identity from the certificate.

This is the strongest method and the recommended one for managed corporate devices. It works for both user certificates and machine certificates (a domain computer authenticating before anyone logs in).

Identity extraction. After a successful handshake, Taranac looks for a user in the certificate in this priority order:

SAN UPN (user@domain.local)
SAN email
Common Name (CN)
the outer User-Name, as a last resort

If a UPN carries a domain suffix and nothing matches, the bare part before the @ is tried too. A user certificate resolves to a user (and that user’s groups) for policy evaluation. A machine certificate that matches no user is treated as a machine-cert flow — the user is empty and the endpoint itself carries the identity. The endpoint’s identity is read the other way round: SAN dNSName first, then the CN, and that value becomes both the endpoint’s certificate identity and its hostname, which the cert_identity_pattern and hostname_pattern classification rules then match on.

Trust. Taranac does not run its own CA by default for trust decisions — it validates client certificates against a CA bundle assembled from three sources: an internal CA hierarchy, uploaded Trusted CAs (for contractors, BYOD, or partner organisations), and per-domain CA certificates attached to an LDAP/AD configuration. Issuer trust, CRL/OCSP revocation checking and the server certificate that FreeRADIUS presents are all managed on the PKI & trust page.

Taranac internal PKI: certificate authorities, issued certificates and the trusted-CA bundle that EAP-TLS validates against. PKI & trust — the CA bundle EAP-TLS validates client certificates against.

Taranac pre-checks the client certificate’s issuer against your trusted CAs before evaluating policy. If the issuer is not trusted, the request is rejected with reason tls_client_cert_untrusted — even though FreeRADIUS would also reject it a moment later. This keeps the NAC authentication log (Logging & Reports → NAC Logs → Auth Log) accurate: no false “accept” for a cert that the TLS layer later refuses.

A different failure looks similar and is not the same thing: when the endpoint does not trust Taranac’s server certificate, it aborts the handshake with a fatal TLS alert of its own. That is logged as tls_server_cert_rejected with the alert text, not as a credential failure — before 1.2.2 it was recorded as PEAP with auth_failed and sent operators hunting a password problem.

PEAP — password inside a TLS tunnel

PEAP (Protected EAP) builds a TLS tunnel using Taranac’s server certificate, then runs EAP-MSCHAPv2 inside it to verify a username and password. It is the default method on Windows and the most common password-based choice.

The catch: MSCHAPv2 is a challenge-response protocol, so the password’s NT-hash is needed to verify it. Taranac has three ways to get one, and which one a login takes is decided by the user’s own directory, never by the installation:

Local Taranac users — the hash is stored beside the account and checked locally. An account whose password was set before NT-hashes were kept has none; re-saving the password generates it.
Active Directory accounts — the hash is unreadable by design (unicodePwd is write-only), so a domain controller has to prove the response. That needs the node to hold a machine account, which is why Active Directory requires the domain join on the MS-CHAPv2 tab of the LDAP configuration. One winbindd, one join, one domain: at most one configuration can own it.
Directories that publish the hash as an ordinary attribute — FreeIPA generates ipaNTHash for every user, byte for byte MD4(UTF-16LE(password)), even where ipa-adtrust-install was never run. Since 1.2.8 Taranac reads it and verifies the response itself: no domain, no join, no winbind. The hash is read per login and stored nowhere. Unlike the domain, this mechanism is not exclusive — any number of such directories can serve PEAP at once, alongside a joined domain.

FreeIPA needs one action on the directory side: ipaNTHash sits in an explicit exclusion list even in the administrator’s own ACI, so an ACI granting the bind account read access has to be added. The MS-CHAPv2 tab generates the LDIF with your bind DN and search base filled in, and Check the directory reports whether the hash is readable. A missing ACI is reported as exactly that, never as a wrong password — FreeIPA answers without the attribute rather than refusing, and counting that as a bad password would feed the brute-force guard.

Directories that publish no hash and cannot hold a machine account still cannot serve PEAP — OpenLDAP, Google Workspace and generic LDAP. Such an attempt is refused by name (mschap_domain_not_joined) rather than as a wrong password, and is not counted as a credential attempt; route those users to EAP-TTLS or EAP-TLS instead. See LDAP directories, which carries the directory-side mechanics, and RADIUS for the same branches on the device-administration side.

Windows PEAP supplicant settings that matter

PEAP has been tested end-to-end with the native Windows 10/11 supplicant against Taranac. A few client-side settings are load-bearing:

Setting	Recommended	Why
Verify server certificate	On	Protects against a rogue RADIUS server. Requires importing Taranac’s server CA into the Local Machine trust store (the supplicant runs as SYSTEM and cannot see the user store).
Connect to these servers	Fill in the server cert CN	Pins the expected RADIUS identity.
Trusted Root CAs	Select Taranac’s CA explicitly	With server verification on, an unselected CA fails the check.
Inner method	EAP-MSCHAPv2	The only inner method Taranac supports for PEAP.
Automatically use Windows logon name	Off for a local Taranac account	When on, Windows sends a qualified name (`COMPUTER\user`), and since 1.2.2 a qualified name may only ever resolve to a directory account — so it no longer finds the local one. For a domain account on a domain PC it is fine.
Cryptobinding TLV	Off	FreeRADIUS does not implement the Microsoft PEAPv0 cryptobinding extension; with it on, Windows will not connect.

EAP-TTLS — password for directory users

EAP-TTLS also builds a TLS tunnel with the server certificate, and Taranac accepts all three of the inner methods a supplicant may choose inside it. They are told apart by what the tunnel actually carries, not by anything you configure:

What arrives inside the tunnel	Inner method	How the password is checked
`User-Password`, no EAP	PAP	Taranac holds the plaintext, so it verifies directly (below)
`MS-CHAP2-Response`, no EAP	MSCHAPv2 (native, non-EAP)	Exactly the PEAP path: NT-hash, domain, or hash-reading directory
`EAP-Message`	EAP-MSCHAPv2	The same PEAP path again

Native EAP-TTLS/MSCHAPv2 — what a supplicant sends with no EAP inside the tunnel — failed for everyone before 1.2.2, including a local account with the correct password. The inner method is recorded on the log row and shown beside the Auth Method badge for EAP-TTLS only, because PEAP always tunnels EAP-MSCHAPv2 and repeating it would be noise — while inner PAP means the password crossed the tunnel in the clear, which is worth seeing at a glance.

With PAP — the usual choice, and the one that reaches every directory type — Taranac receives the actual password and verifies it directly:

Directory users — Taranac performs an LDAP bind as the user. On Active Directory that is a direct bind as user@domain; on OpenLDAP, FreeIPA and other types the account’s DN is resolved first (inside the configured search bases) and the bind uses that DN. The directory checks the password; nothing is stored locally. This is the password-based 802.1X method that works for every directory type, whatever it can or cannot do about NT-hashes.
Local users — the password is checked with argon2id against the stored hash (no NT-hash needed).

A failed bind spends the account’s lockout budget in the directory exactly as an MS-CHAPv2 check does, so Taranac holds further binds for an identity after repeated failures rather than letting a looping supplicant lock the account out. That hold is shared with the PEAP path, because the directory counts both against one account.

EAP-TTLS is native on Linux (wpa_supplicant default), macOS, iOS and Android. On Windows it is supported but not the default, so it usually requires GPO or manual supplicant configuration.

LDAP settings: the directories Taranac binds against to verify EAP-TTLS passwords. Directory configurations — the identity stores EAP-TTLS binds against. Any type works here: this installation carries Active Directory, OpenLDAP and FreeIPA at once.

LDAP bind verification uses the configuration’s own Connection timeout (Settings → LDAP → Connection, 10 seconds by default), and each server in the pool is tried once rather than retried forever — the library’s default would have held a RADIUS worker thread for good against a directory that never answers.

The bind fails closed: an unreachable directory means Access-Reject, never an accept. But an outage and a wrong password are no longer the same answer. The verdict is taken from what the directory itself said — an invalidCredentials result, or Active Directory’s data NNN sub-code — so only a real credential rejection is logged as bad_password and counted against the account’s guards. A directory that could not be asked is logged as domain_unreachable, blames nobody, and spends no lockout budget.

MAB — for devices with no supplicant

Printers, IP phones, cameras and most IoT devices have no 802.1X supplicant. When the switch’s EAP exchange times out, it falls back to MAC Authentication Bypass: it sends the device’s MAC address as the username. Taranac does not check a credential — it looks the MAC up in the endpoint inventory, and if the endpoint exists and is not blocked, the request proceeds to policy evaluation. Unknown MACs can be auto-discovered, classified, and (via policy) redirected to a captive portal.

MAB proves possession of a MAC address, nothing more — a MAC is easily spoofed. Treat it as device identification, not authentication, and scope MAB rules to restricted VLANs and ACLs.

How a request is classified

Every request lands in policy evaluation tagged with one method. Taranac decides the tag from the RADIUS attributes FreeRADIUS provides:

Signal, most reliable first	Detected as
Inner-tunnel marker `ttls` — the inner tunnel ran to completion	`eap_ttls`
Inner-tunnel marker `peap` — likewise	`peap`
EAP present and any client-certificate attribute (serial, issuer, subject, or any SAN — not the CN alone)	`eap_tls`
EAP present, no client cert, no marker, but the daemon’s failure message names the EAP type	that type (13 → `eap_tls`, 21 → `eap_ttls`, 25 → `peap`)
EAP present, nothing identifies the method	`peap`, as a last-resort guess
No EAP at all	`mab`

Policy rules then match on this tag — for example IF [EAP-TLS] user in [Domain Users], or IF [MAB] endpoint in [Printers]. A rule with method Any matches regardless. See NAC policy for how the who/what/where/when conditions combine.

Certificate templates on a Windows CA commonly issue machine certificates with an empty subject, putting the identity in a subjectAltName extension instead. FreeRADIUS then sets no client-certificate Common Name at all, and Taranac used to decide the method from that CN alone — so those sessions fell through to the last-resort guess and were recorded as PEAP, for an exchange that was EAP-TLS from beginning to end.

The consequences went well past a wrong label. A rule matching on EAP-TLS could not match them, so the profile, VLAN and ACL you intended were never applied; and everything Taranac derives from a certificate — the identity, the issuer, machine-versus-person — was skipped in silence, because that whole block was gated on the method being eap_tls.

A certificate is now recognised by any of the fields an X.509 certificate always carries, which is why the table above no longer names the CN. A session that genuinely is PEAP or EAP-TTLS while also carrying a client certificate is still reported as PEAP or EAP-TTLS: the inner-tunnel marker identifies those first.

Two things to know. Earlier records are not rewritten — only authentications after the upgrade are classified correctly. And if you worked around this by writing a rule that matches PEAP to catch your Windows machines, that rule will stop matching them. They now present as EAP-TLS, which is what they were all along; move the rule to EAP-TLS before you upgrade, or those machines will fall through to whatever comes next in the policy.

NAC policy rules grouped by authentication method. NAC policy — rules are grouped by the authentication method they match.

What the log records about the port and the VLAN

Every 802.1X and MAB authentication lands in Logging & Reports → NAC Logs → Auth Log. Two of its columns answer questions the AAA logs deliberately do not: which interface did this endpoint authenticate on, and which VLAN was it in.

The interface. Switches report the port in whatever shape their vendor chose. Cisco says GigabitEthernet0/3 and MikroTik says ether2, and those pass through unchanged. Huawei and H3C/Comware encode it, and since 1.2.6 both encodings are decoded — by shape, not by detected vendor, because a reject path has no resolved vendor and H3C inherited the same formats:

What the NAS sends in `NAS-Port-Id`	What the NAS Port column shows
`GigabitEthernet0/3`, `ether2` — already readable	the value itself
`slot=0;subslot=0;port=18;vlanid=121;interfaceName=GigabitEthernet0/0/18`	`GigabitEthernet0/0/18` — the vendor’s own `interfaceName` always wins
the same `key=value` form with no `interfaceName` (or `unit=` on a Comware stack)	the composed path `slot/subslot/port` — no media type is knowable, so none is invented
`0000018000000121` — the 16-digit form, slot(2) + subslot(2) + port(3) + vlanid(9)	the same path, but only when every field lands inside the range the vendor documents; otherwise the raw string stands, because a confident wrong answer is worse

The raw value is kept beside the readable one and shown on hover, so nothing is lost; the column sorts on the parsed name, and free-text search matches it. The same value appears as Interface in the detail panel of both the auth log and sessions, in endpoint discovery, in CSV and XLSX exports, and in both NAC report templates. It is filled in as authentications arrive — records written before the upgrade keep an empty Interface, because the raw value they stored is the only evidence there is.

The VLAN. An authentication row carries two numbers with two meanings: the VLAN the matched profile assigned, and the VLAN the NAS reported — read from a Cisco vlan-id AV-pair, from vlanid= inside NAS-Port-Id, or from Tunnel-Private-Group-ID, in that order. A disagreement between them is not flagged here, deliberately: on an authentication record the reported VLAN is the one the frame arrived in before any assignment was applied, so flagging it would light an icon on every ordinary dynamic-VLAN authentication. On a live session the same disagreement is flagged, because that is where the port settled after authorization — see Sessions.

This is where public issue #11 started: a MAB’d IP phone tags its own voice VLAN, so there is nothing for a profile to assign and the VLAN appears only inside NAS-Port-Id. An empty assigned VLAN on such a row is a deliberate configuration, not a gap.

Before 1.2.6, a Huawei switch configured with the newer NAS-Port-Id format could silence the whole NAC authentication log. The port description it sent was longer than the column that stored it, the write was refused, the batch was retried unchanged and failed again — so every authentication that followed queued behind a record that could never land, until the queue filled and began discarding real entries. Authentication itself kept working the entire time (the log is written after the fact), which is what made it expensive to diagnose: devices got on the network while the operator watched a journal that had simply gone quiet. The column now holds the full length the protocol allows, and — the more important half — a record that genuinely cannot be written is dropped on its own, loudly and in its own words, instead of taking every record behind it down with it. Entries lost while the log was blocked never reached the database and cannot be recovered.

When to use which

Your situation	Use	Notes
Managed corporate laptops/desktops	EAP-TLS	Strongest. Needs cert provisioning (e.g. AD CS auto-enrollment) and the issuing CA trusted in Taranac.
Domain computers authenticating before login	EAP-TLS (machine cert)	Machine identity; classify into a “Domain Computers” endpoint group.
Contractors / BYOD / partner devices with certs	EAP-TLS (Trusted CA)	Upload the partner CA as a Trusted CA; resolve to a local user or leave as endpoint identity.
LDAP/AD users with passwords	EAP-TTLS	Works against every directory type, whatever it can do about NT-hashes — verified by an LDAP bind.
Directory users on Windows’s default supplicant	PEAP	Needs a directory that can prove MS-CHAPv2: Active Directory on a domain-joined node, or FreeIPA with `ipaNTHash` readable.
Local Taranac users with passwords, Windows default	PEAP	Requires the account’s NT-hash to be stored.
Printers, phones, cameras, IoT (no supplicant)	MAB	Identification, not authentication. Scope to restricted access.
Unknown device, no supplicant, unknown MAC	MAB → captive portal	Policy redirects to a portal for guest/BYOD/AUP onboarding.

A practical layered design: EAP-TLS for everything that can hold a certificate, EAP-TTLS for directory users who authenticate with a password, PEAP where the supplicant leaves you no choice and the directory can prove an MS-CHAPv2 response, and MAB (scoped tight) for the headless devices that have no other option.

Common scenarios

Corporate employee (EAP-TLS, user cert). Laptop presents a user certificate; Taranac extracts the UPN from the SAN, resolves the user and their groups, and policy assigns the corporate VLAN.
Domain computer (EAP-TLS, machine cert). Machine authenticates before login with a computer certificate; no user matches, so the endpoint carries the identity (hostname enriched from the cert) and policy places it in a machine VLAN.
Linux workstation, directory user (EAP-TTLS). wpa_supplicant sends the password over PAP inside TLS; Taranac binds to the directory as that user — user@domain on AD, the resolved DN on OpenLDAP or FreeIPA; on success, policy applies the user’s group rules.
Local admin account on Windows (PEAP). Username/password verified via MSCHAPv2 against the stored NT-hash.
FreeIPA user on Windows (PEAP). The supplicant offers nothing but PEAP-MSCHAPv2; Taranac reads ipaNTHash from the directory for that login, verifies the response itself, and stores nothing. No domain join is involved, and a joined Active Directory on the same node is untouched by it.
Network printer (MAB). No supplicant, so the switch sends the MAC; Taranac finds it in the “Printers” endpoint group and policy assigns the printer VLAN.

NAC overview — how NAC fits together and differs from AAA.
NAC policy — authorization profiles and rules (the what).
Endpoints — endpoint inventory, groups and classification.
PKI & trust — server certificate, internal CA, trusted CAs, CRL/OCSP.
Captive portal — onboarding for unknown devices.
Taranac on GitHub