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

1. marker peap → peap ✗
2. marker ttls → eap_ttls ✓
3. EAP + client cert CN → eap_tls ✗
4. no EAP → mab ✗

tagged eap_ttls → policy evaluation

Method	Proves identity with	Inner method	Works for directory users	Needs client cert	Needs NT-hash stored
EAP-TLS	Client X.509 certificate	— (cert only, in the TLS handshake)	Yes	Yes	No
PEAP	Username + password	EAP-MSCHAPv2	Active Directory only, and only on a domain-joined node	No	Yes (local users)
EAP-TTLS	Username + password	PAP (plaintext, inside TLS tunnel)	Yes — any directory type	No	No
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.

• 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.
• 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 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 reads the identity from the certificate in this priority order:

1. SAN UPN (user@domain.local)
2. SAN email
3. Common Name (CN)
4. SAN dNSName (typically a machine FQDN)

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, with the hostname enriched from the certificate’s CN or DNS SAN.

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.

PKI & trust — the CA bundle EAP-TLS validates client certificates against.

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. For local Taranac users that hash is stored and checked locally. A directory account’s hash is not readable by design, so it has to be verified by the directory itself — which only Active Directory will do, and only once the Taranac node has joined the domain (see the MS-CHAPv2 tab on the LDAP configuration).

Directories that are not Active Directory cannot serve PEAP at all — OpenLDAP, FreeIPA and the rest hand out no NT-hash. 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.

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	When on, Windows sends COMPUTER\user, which fails the lookup.
Cryptobinding TLV	Off	FreeRADIUS does not implement the Microsoft PEAPv0 cryptobinding extension; with it on, Windows will not connect.

EAP-TTLS also builds a TLS tunnel with the server certificate, but runs PAP inside it — the password travels as plaintext, protected by the surrounding TLS. Because Taranac receives the actual password, it can verify 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 — and the only one for those that are not Active Directory.
• Local users — the password is checked with bcrypt against the stored hash (no NT-hash needed).

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.

Directory configurations — the identity stores EAP-TTLS binds against. Any type works here: this installation carries Active Directory, OpenLDAP and FreeIPA at once.

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.

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

Signal	Detected as
Inner-tunnel marker ttls	eap_ttls
Inner-tunnel marker peap	peap
EAP present and a client certificate CN	eap_tls
EAP present, no client cert, no marker	peap (best 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.

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

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	The only password method for directory users — verified by LDAP bind.
Local Taranac users with passwords, Windows default	PEAP	Requires NT-hash storage; does not work for LDAP users.
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 only for local accounts on Windows, and MAB (scoped tight) for the headless devices that have no other option.

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