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 → 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 → 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. It is on by default and is an admin-UI concept; leaving it on will not block 802.1X, but it makes the account’s state confusing while you are testing.

Infrastructure → 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 is nasty: when Windows rejects the server certificate, the TLS handshake dies inside the EAP layer, so the attempt may not produce a normal policy decision in the log. It looks like nothing happened.

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 (/nac/settings/pki) and find the 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 — 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 a reauth timer so sessions are periodically re-authenticated. 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 click Add rule.

2. Give it these conditions and result:

   Dimension	Value
   How (method)	peap
   Who (user groups)	PEAP-Users
   What (endpoint groups)	Any endpoint
   Where (device groups)	Any device — or restrict to your lab switch
   When	Always
   Result	Corp-Data

3. Save, and check where the rule landed. NAC policy is first match wins, evaluated top-down by the rule numbers, with Default — Reject at the bottom. Drag the rule up if a broader rule above it would swallow your traffic first.

The rule reads as a sentence: IF PEAP · USER IN PEAP-Users · any endpoint · any device · always → Corp-Data · VLAN 10. 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 the older field guidance told people to avoid, which now work:

• 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. Taranac now normalises all three forms — it strips the NT-style prefix and the UPN suffix before looking the user up — so the option no longer breaks authentication provided the Windows account name and password match the Taranac account. In this lab they do not (you created a standalone nacuser-peap), so leave it off and enter credentials explicitly. It comes into its own with directory integration.
• 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 through and evaluates policy against it, so this works as intended. 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 → NAC → Authentication (/logging/nac/authentication):

• an Access-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 showing 10
• a live entry under Logging → NAC → Sessions (/logging/nac/sessions)
• the endpoint under Endpoints (/nac/endpoints), now tied to a user

The NAC Auth Log, filtered to PEAP — this is where the guide is proved. The same rule (PEAP · PEAP-Users → Corp-Data, VLAN 10) accepted the same user on a Cisco switch and on an Arista one: policy is written once, not per platform. The rejects below are a directory account attempting PEAP, which cannot work — see the callout in Step 1.

Logging → NAC → 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 does work with LDAP/AD.

• 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