802.1X with PEAP, end to end

This guide takes the lab from Build an 802.1X lab and gets a real user onto the network: a Windows PC authenticates with a username and password inside a TLS tunnel, Taranac matches a policy rule, and the switch puts the port into VLAN 10.

PEAP is the right first method to prove out. It needs no client certificates, so there is exactly one moving part on the client — and the Windows supplicant’s three dialogs contain a handful of checkboxes that will silently break the connection if they are wrong. Every setting below was tested against Taranac’s NAC RADIUS (FreeRADIUS 3.2.8) with the native Windows 10/11 supplicant, and the ones that matter are called out with what actually happens when you get them wrong.

What you’ll have at the end: a user authenticating over PEAP/MSCHAPv2, a policy rule granting VLAN 10, the session visible in Taranac, and the port closed so unauthenticated devices no longer get through.

PEAP verifies a password using MS-CHAPv2, which needs the NT hash of that password on the server side. Taranac derives and stores that hash whenever a local user’s password is set, so a local user works for 802.1X with no extra step.

1. Open Infrastructure → Identity → Groups and create a group — PEAP-Users. The group is what your policy rule will match on, which is far more maintainable than naming individual users in policy.

2. Open Infrastructure → Identity → Users (/infrastructure/users), click New, and create a local user — say nacuser-peap — with a password that satisfies the password policy. Add them to PEAP-Users.

3. Turn Must change password off for this account. The new-user form ticks it by default, and it is not cosmetic: a local account carrying the flag is refused at 802.1X before the password is even checked, with Password change required on the wire. Leave it on and every attempt in this guide fails — and the auth log will say auth_failed, which reads as a wrong password and sends you to the wrong place entirely.

Infrastructure → Identity → Users — a local account is all PEAP needs; the NT hash is derived automatically.

Windows validates the RADIUS server’s certificate before it will send a password through the tunnel — and it is right to. This step is where most PEAP bring-ups actually stall, and the failure mode used to be nasty: when Windows rejects the server certificate the TLS handshake dies inside the EAP layer, no password is ever checked, and the reject looked exactly like a wrong one.

It no longer does. A supplicant refusing the server certificate does not go quiet — it sends a fatal TLS alert, Taranac reads it out of the EAP message, and the auth log records the reject as tls_server_cert_rejected with the alert’s own text (unknown_ca and friends). So this failure now names itself. Note that the reason arrives in the log as that raw token: the UI’s translation table does not yet carry it.

Two different certificates are involved here, and confusing them is the single most common way this step goes wrong:

You install the CA, and you name the server. Install the server certificate instead and you will get a setup that appears to work while validating nothing — see the callout below.

1. Open NAC → Settings → PKI / Certificates (/nac/settings/pki) and find the NAC Server Certificate — the one FreeRADIUS presents for NAC. Note its CN (in a default install, taranac-nac) and which CA issued it. You will need both.

2. Download that CA’s certificate — not the server certificate.

3. Install the CA on the Windows client — into the computer store:

   # Run as Administrator
   Import-Certificate -FilePath .\taranac-internal-ca.pem `
                      -CertStoreLocation Cert:\LocalMachine\Root

   Or certlm.msc (not certmgr.msc) → Trusted Root Certification Authorities → Import.

4. Verify it landed, and that what landed is a CA:

   Get-ChildItem Cert:\LocalMachine\Root |
     Where-Object { $_.Subject -match 'Taranac' } |
     Select-Object Subject, Issuer

   On a CA certificate, Subject and Issuer are the same (it is self-signed, a root). If they differ, you imported an end-entity certificate — go back to step 2.

5. If you already imported the server certificate on an earlier attempt, remove it. It is inert once the CA is trusted, but leaving an end-entity certificate sitting in the machine’s root store misrepresents what the working configuration actually requires — and the next person to copy this setup will carry the mistake forward.

NAC → Settings → PKI / Certificates — the server certificate’s CN is the value Windows will check against.

The profile is what the switch is told to do when a rule matches.

1. Open NAC → Policies → Authorization Profiles (/nac/policies/profiles) and click New profile. Name it Corp-Data.

2. Set VLAN ID to 10. That is all this lab needs — Taranac sends the standard tunnel attributes and the switch moves the port.

3. Optionally set Re-auth timer (seconds) so sessions are periodically re-authenticated — it sends Session-Timeout together with Termination-Action = RADIUS-Request, and for that reason cannot be combined with the plain session timeout. Leave ACLs and URL redirect alone for now.

NAC → Policies → Authorization Profiles. The Used by column tells you how many rules depend on a profile before you change it.

VLAN assignment is the most portable authorization result there is — every switch that does 802.1X supports it. Downloadable ACLs and URL redirects are more powerful and considerably more vendor-dependent; see NAC policy for when each is worth reaching for.

1. Open NAC → Policies → Policy Table (/nac/policies) and look at what is already there before you add anything. A fresh install ships three rules:

   #	Rule	Matches
   1	Dot1x Known Users → Corporate	PEAP · any user · any endpoint · any device · always → Corp-Default (VLAN 100)
   2	MAB Known Endpoints → Restricted	MAB · any → MAB-Default (VLAN 300)
   —	Default — Reject	everything else

   Rule 1 matches every PEAP request. The Add rule button appends to the end of the list, so a rule added that way would sit below it and never be reached — the user would authenticate, land in VLAN 100, and the log would name a rule you did not write. Instead, hover rule 1’s row and press its ↑ button: that is Insert rule above, and the drawer opens titled New rule at position #1. (The ↑ and ↓ on a row insert; to move an existing rule, drag its handle.)

2. Fill the drawer in:

   Field	Value
   Rule name	PEAP → Corp-Data
   Method	PEAP
   Action	Permit (assign profile)
   Who	PEAP-Users
   What	Any endpoint
   Where	Any device — or restrict to your lab switch
   When	Always
   Authorization profile	Corp-Data

3. Save, and confirm the order. NAC policy is first match wins, evaluated top-down by the rule numbers, with Default — Reject always at the bottom. Drag to reorder if the rule did not land where you meant.

4. Prove the order before you touch the switch. NAC → Policies → Policy Tester (/nac/policies/tester) simulates one request: method PEAP (802.1X), username nacuser-peap, your switch’s NAS IP. It answers with Rule #N matched and an evaluation trace showing every rule it walked past. If it names anything other than your new rule, fix the order now — this is thirty seconds against a port bounce and a puzzled log reading.

The rule reads as a sentence: IF PEAP · USER IN PEAP-Users · any endpoint · any device · always → Corp-Data · VLAN 10, and it sits at #1 — directly above the shipped Dot1x Known Users → Corporate, which would otherwise have matched first. The table groups rules by method for readability, but evaluation order is the rule number, and Default — Reject always ends the list.

On the client, first make sure the Wired AutoConfig service is running and set to Automatic — without it the Authentication tab does not even appear:

Set-Service dot3svc -StartupType Automatic
Start-Service dot3svc

Then open Network Connections → your Ethernet adapter → Properties → the Authentication tab. There are three nested dialogs; take them in order.

Dialog 1 — 802.1X on, PEAP chosen. Settings opens Dialog 2; Additional Settings opens Dialog 3.

A working strict configuration: validation on, the CA ticked, and Don’t ask user to authorize new servers or trusted CAs. Reaching this state without a single prompt is the proof that the trust chain is genuinely valid.

The three states of “Connect to these servers”, because only one of them is a trap:

Without name pinning, any server holding a certificate from that CA is accepted. With a dedicated internal CA that is a small gap; with a corporate CA that issues certificates widely, it is the whole attack.

Two settings worth understanding rather than copying:

• Automatically use my Windows logon name and password. This makes Windows send the logged-on identity, which on a workgroup machine arrives as DESKTOP-XYZ\alice and on a domain machine as DOMAIN\alice or alice@domain. For a local Taranac account this must be off. Since 1.2.2 a qualified name may only ever resolve to a directory account: stripping the prefix and matching a local one made ANYTHING\alice a free alias for the local alice, and an operator could not see it in the log because the row named the bare account either way. So DESKTOP-XYZ\nacuser-peap resolves to nothing and the attempt is rejected as User not found. It comes into its own on a domain PC with a domain account, where the qualified name is the real one.

  ⚠️ There is a second trap in the same checkbox: with it on and Enable single sign on off, Windows sends no RADIUS request at all — the supplicant runs as SYSTEM and has no way to reach the logged-on user’s credentials. The Wired-AutoConfig event log says 0x50001, Taranac logs nothing, and the port simply never authenticates.

• Identity Privacy. Sends a placeholder such as anonymous as the outer identity so the real username never appears in cleartext, and reveals it only inside the tunnel. Taranac carries the inner identity out of the tunnel and logs and evaluates policy against it, so this works as intended — on the accept path. On an inner reject the tunnelled reply attributes are never copied outward, so the row in the auth log carries the outer identity: your failed logins will read anonymous. Worth knowing before you turn it on and then go debugging. On wired switch ports the threat it addresses is modest — an attacker needs physical access to the cable — but on wireless it is worth turning on.

Dialog 3 — pick User authentication. Save credentials stays greyed out until you do.

The credentials that are actually sent over 802.1X live here — not in the Windows logon.

Bounce the port (unplug and replug, or shutdown / no shutdown on the switch), and watch both ends.

On Taranac — Logging & Reports → NAC Logs → Auth Log (/logging/nac/authentication):

• an Accept for nacuser-peap, Auth Method PEAP
• the Rule that matched and the Profile it returned, right in the row — PEAP · PEAP-Users → Corp-Data — plus the VLAN column
• a live entry under Logging & Reports → NAC Logs → Sessions (/logging/nac/sessions)
• the endpoint under NAC → Endpoints → Endpoints (/nac/endpoints), now tied to a user

The NAC Auth Log, filtered to PEAP — this is where the guide is proved. Every row is the same rule (PEAP · PEAP-Users → Corp-Data) accepting nacuser-peap on the lab’s Arista switch, VLAN 10, no reject reason. The rule is written once and is not per platform: point a Cisco at the same Taranac and its rows land in this same table, matched by the same rule.

Logging & Reports → NAC Logs → Sessions — an authenticated session, its endpoint, the port it came in on, and live traffic counters.

On the switch:

show authentication sessions interface GigabitEthernet1/1 details

debug dot1x events
debug radius authentication

show dot1x interface Ethernet3
show dot1x hosts
show radius

On Windows: the adapter should pick up an address in VLAN 10’s subnet (10.30.10.x). If the port authorized but the PC kept an old address, release and renew — some supplicants do not re-DHCP after a VLAN change on their own.

The proof that authorization actually applied: ipconfig /all — or Status → Details — shows an address in VLAN 10, handed out after Taranac told the switch where to put the port.

Everything so far ran with authentication open — authentication happened and was logged, but traffic passed regardless. Now enforce it.

interface GigabitEthernet1/1
 no authentication open

Re-test immediately: bounce the port with correct credentials (should authorize and pass traffic), then with a device that has no supplicant configured (should be denied, or land wherever your MAB rule sends it). Do this while you still have console access to the switch.

For deeper diagnosis, Troubleshooting covers reading the NAC handler’s decisions.

• MAB for printers and IoT — the other half of every real access port. (Coming next in this series.)
• EAP-TLS for domain users — certificates instead of passwords, and the method that fits Active Directory accounts.
• EAP-TTLS for directory users — the password method that works against any directory type, whatever it can do about NT hashes.

• 802.1X authentication — how each EAP method behaves and what it needs
• NAC policy — profiles, conditions, CoA
• PKI & trust — server certificates and trusted CAs
• Users & groups — local accounts, NT hashes and group membership
• LDAP directories — the domain join, the ipaNTHash ACI, and Check the directory