EAP-TLS for domain users

EAP-TLS replaces the password with a certificate. There is no shared secret to phish, nothing to type, and nothing that expires the way a password does — the client proves possession of a private key, and Taranac decides who that key belongs to.

For directory users this is the method that actually fits. PEAP cannot authenticate an Active Directory account at all — it needs an NT hash that lives in the directory, not in Taranac. EAP-TTLS can, by binding to LDAP, but a password still crosses the tunnel. EAP-TLS removes the password from the picture entirely, which is why it is what most Windows domains standardise on.

This guide takes a domain-joined Windows PC and an Active Directory user, and gets the port authorized on a certificate.

Before anything else, decide where client certificates come from. Taranac supports both, they are not exclusive, and the choice does not change how policy or authentication works — only who issues and delivers the credential.

Both feed the same trust bundle, so you can run them side by side: domain laptops on AD CS certificates, everything else on certificates Taranac issued. Nothing downstream needs to know the difference.

This guide walks the AD CS path, because that is the realistic shape of a Windows domain. Where the internal-PKI path differs, it is called out inline.

A client certificate is accepted when it chains to a CA in Taranac’s client trust bundle. That bundle is assembled from three independent sources:

1. Internal CAs — every enabled CA Taranac runs itself
2. Trusted CAs — external CA certificates you upload (/nac/settings/trusted-cas)
3. LDAP domains with EAP-TLS enabled — the CA attached to a directory

For a domain scenario, prefer the third. Open Settings → LDAP, select the domain, and in its EAP-TLS section enable EAP-TLS and paste the root CA of your AD CS (plus a CRL URL, if you intend to check revocation).

Attaching the CA to the domain rather than uploading it as a standalone Trusted CA is not just bookkeeping: the same section also carries which certificates that domain issues (user, computer, or both) and how a certificate maps to a user — the subject of Step 2. Trust and identity rules stay with the directory they belong to, instead of being scattered across two pages.

Use the Trusted CAs page instead when the CA has nothing to do with a directory — a partner’s issuer, or a CA for devices that have no user at all.

A certificate proves a key; it does not by itself say which account that is. Taranac reads an identity out of the certificate and looks it up among its users, in this order:

SAN UPN → SAN email → Subject CN → RADIUS User-Name

The first one that matches an account wins. If a UPN carries a domain suffix (alice@lab.example.com) and no account matches in full, Taranac retries with the bare username. On the LDAP domain you also set identity match explicitly — san_upn, san_email or cn — which is the field that population’s certificates are expected to carry. For AD CS with a standard user template, san_upn is the right answer and the default.

When no user matches, this is not necessarily an error: Taranac treats it as a machine certificate and evaluates policy with no user at all, matching on the endpoint’s groups instead. That is how domain computers authenticate before anyone logs in — see Machine authentication and SSO. This guide stays on user certificates.

gpupdate /force
certutil -user -pulse

Get-ChildItem Cert:\CurrentUser\My |
  Select-Object Subject, EnhancedKeyUsageList, NotAfter

(Get-ChildItem Cert:\CurrentUser\My)[0].Extensions |
  Where-Object { $_.Oid.FriendlyName -match 'Subject Alternative Name' } |
  ForEach-Object { $_.Format($true) }

Same shape as the PEAP rule, with two conditions changed:

Rules are evaluated first match wins, so place it above the default reject. See NAC policy for the full condition model.

Two ways to close it. In a domain they are not equally good.

Either way, verify on the client before touching the supplicant — the CA that signed the server certificate must be present machine-wide:

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

Open the adapter’s Authentication tab, as in the PEAP guide.

Set the method to Microsoft: Smart Card or other certificate. Everything else on this tab behaves as it did for PEAP.

Dialog 1 — the only change from PEAP is the method.

Dialog 2 — certificate on this computer, simple selection, server validation on, and the strict no-prompt checkbox at the bottom.

The CA you tick here is the one from Step 5 — the issuer of the server certificate. It is usually a different CA from the one in Step 1, which is what makes this pair so easy to get half-right: fix only Step 1 and every client refuses to talk; fix only Step 5 and the server rejects every client.

Set Specify authentication mode to User authentication, and the supplicant will use the certificate from the logged-on user’s store. On a domain machine, User or computer authentication also works and is what you would pick once machine certificates are in play.

Dialog 3 — User authentication for this guide. The single sign-on block below it is what turns this into two-phase machine-then-user authentication; that gets its own page.

Bounce the port and open Logging → NAC → Authentication (/logging/nac/authentication). An EAP-TLS accept shows the resolved username and the matched rule, exactly as PEAP did.

Filtered to EAP-TLS. The accepts carry the full UPN as the username, the rule that matched (EAP-TLS · AD_Users → Corp-Data) and the VLAN it returned. Rows identifying themselves as host/<fqdn> are the machine phase — a different flow, covered in Machine authentication and SSO.

Note what the username column shows: the UPN from the certificate, not a bare account name. That is the identity Taranac matched against the directory user, and seeing it here is the quickest confirmation that Step 2 resolved the way you intended.

The endpoint gets more than an accept, though. Taranac records the certificate it saw — subject CN, the SAN entries, serial and issuer — against the endpoint under Endpoints (/nac/endpoints). That turns the endpoint list into an inventory of which certificate each device authenticated with, which is what you want on the day a CA has to be rotated or a batch of certificates revoked.

Sessions still come from accounting, not authentication — if an accept appears with no session, see that callout in the PEAP guide.

• 802.1X authentication — how each method behaves
• PKI & trust — CAs, server certificate, CRL, EST enrollment
• LDAP directories — directory integration and sync
• 802.1X with PEAP — server-certificate trust, in detail