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 can authenticate an Active Directory account, but only by asking a domain controller to prove the MS-CHAPv2 response — which means joining the Taranac node to the domain on the LDAP configuration’s MS-CHAPv2 tab — and since there is one winbindd and one join, at most one configuration can own it. EAP-TTLS avoids all that by binding to LDAP, but a password still crosses the tunnel. EAP-TLS removes the password from the picture entirely and needs no join at all, which is why it is what most Windows domains standardise on. See 802.1X authentication for how each method gets its credential.

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 → Integrations → LDAP, select the domain, and on its EAP-TLS tab tick Enable EAP-TLS for this domain and paste your AD CS certificates into CA Certificate (PEM): the root, and on a two-tier hierarchy the issuing CA that signs the client certificates as well, one after the other. Enabling without a certificate is refused, so this is one action rather than two. With the root alone, Taranac accepts only the clients that send their issuing CA’s certificate along with their own; the issuing CA in the field accepts every client of it, and is what lets its CRL be verified and checked (see the caution below).

Attaching the CA to the domain rather than uploading it as a standalone Trusted CA is not just bookkeeping: the same tab 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 one identity out of the certificate — the first of these fields the certificate actually carries:

SAN UPN → SAN email → Subject CN

The RADIUS User-Name is never used: the supplicant can put anything there. A certificate carrying none of the three is a machine session with no user.

That is a choice of field, not a search. Whichever field wins is looked up case-insensitively among Taranac’s active users. If it matches nothing, Taranac does not fall back to the next field. If the UPN is alice@lab.example.com and no account is named that in full, the bare alice is tried.

For a directory account such as your AD users, that is not enough. The certificate must also be bound to the account’s directory, in one of two ways:

• the UPN (or CN) carries the LDAP configuration’s domain suffix exactly, case-insensitively. alice@lab.example.com matches an account of the configuration whose suffix is lab.example.com. A sub-domain or an alternative UPN suffix (alice@example.com) does not.
• or the identity is the account’s own e-mail address (its mail attribute). This is the only way a SAN e-mail is accepted.

A certificate that names a directory account without either is rejected before policy, with tls_identity_domain_mismatch in the Auth Log. A bare CN such as alice, with no domain, is rejected as tls_identity_no_domain. Neither falls back to the machine flow. Local Taranac accounts are not bound this way: any trusted CA’s certificate for alice@anything names the local alice.

So the certificate template decides the lookup. A certificate carrying both a UPN and an e-mail address is always resolved by the UPN; if the accounts you want matched are named by something else, the certificate must not carry a UPN at all. With AD CS’s standard user template the UPN’s domain is the AD domain, which is the configuration’s domain suffix, so it matches without further work.

The LDAP domain’s Identity extraction setting — san_upn, san_email or cn, defaulting to san_upn — records which field that population’s certificates are expected to carry, and for AD CS with a standard user template san_upn is the right answer. Treat it as a declaration rather than a switch: the order above is fixed in the 802.1X service and is the same for every domain.

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 — which can be filled from the directory itself, by LDAP DN or LDAP group classification rules, rather than by hand. 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.

Three 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 & Reports → NAC Logs → Auth Log (/logging/nac/authentication). An EAP-TLS accept shows the resolved username and the matched rule, exactly as PEAP did.

Filtered to EAP-TLS. Each accept carries a username, the rule that matched (EAP-TLS · AD_Users → Corp-Data) and the VLAN it returned. Machine-phase rows are a different flow, covered in Machine authentication and SSO.

Note what the username column shows: the Taranac account the certificate resolved to, as it is named in Taranac (for a synced AD user, its login name). It is never what the supplicant typed into User-Name. Seeing the account you expected here is the quickest confirmation that Step 2 resolved the way you intended. A row for a certificate that resolved to no account shows the name in the certificate instead (the UPN, e-mail or CN, else its DNS name).

The endpoint gets more than an accept, though. Taranac records the certificate it saw — subject CN, the SAN entries, serial and issuer, plus whether it reads as a user or a machine certificate — against the endpoint under NAC → 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
• Certificate revocation: CRL and OCSP — which CAs are checked, which CA’s CRL counts, OCSP
• Taranac under your corporate root — an Internal CA signed by AD CS
• LDAP directories — directory integration and sync
• 802.1X with PEAP — server-certificate trust, in detail