Machine authentication and SSO

A domain workstation needs network access before anybody logs in — to reach a domain controller, apply group policy, run scheduled tasks, accept a remote session. But the user’s certificate lives in the user’s profile, which does not exist until they sign in. So the machine authenticates first, with its own certificate, and the session is re-authenticated as the user at logon.

That is what Windows calls single sign-on for this network, and Taranac sees it as two separate authentications on the same port: one with no user at all, one with a user. Getting it right is mostly a question of which policy rule each phase lands on — and that is where this goes wrong in practice.

The user chain is a choice of field, not a search: Taranac takes the first of those four that is present and looks that value up once, with a single retry on the bare name before the @. If the certificate carries a UPN that names no account, it does not fall back to the CN.

The asymmetry in the last two rows is the whole story. In the machine phase there is no user, so a rule with a user-group condition simply cannot match. In the user phase, both the user and the endpoint conditions are true — which means a rule written for the machine phase will happily swallow the user phase too, if you let it.

The computer certificate is issued exactly like the user one, from a computer template with Client Authentication EKU, autoenrolled to Domain Computers, with the machine’s FQDN in the SAN.

# elevated — machine enrollment is a machine-context operation
certutil -pulse
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter

Note the difference from the user certificate: no -user, and elevation required. Machine and user autoenrollment are independent mechanisms with different stores, different policy halves and different permissions — a working one tells you nothing about the other. If nothing arrives, the diagnostic ladder in the EAP-TLS guide applies here too.

In the machine phase policy has only the endpoint to match on, so the endpoint has to be in a group by the time it authenticates. Two mechanisms feed that, and they complement each other.

Classification rules. A fresh install already seeds an endpoint group called Corporate Devices — described as “Domain-joined corporate machines, full network access” — but it seeds no rules for it. Open NAC → Endpoints → Endpoint Groups, pick that group (or one of your own), and give it rules that recognise a domain machine: Certificate Authority, which matches endpoints whose certificate was issued by a CA you select from the NAC trusted list, and Hostname Pattern. Any endpoint matching either rule joins the group. See Endpoints.

Computer sync. On the LDAP domain, enabling computer synchronisation imports the directory’s computer objects as endpoints — before those machines ever authenticate. When a machine certificate then arrives, Taranac matches its FQDN against the staged computer objects by hostname, case-insensitively, and carries their directory data onto the endpoint: distinguished name, GUID, operating system, description. It binds only an endpoint that has no directory GUID yet, so it never re-writes one already bound.

Once that link exists, a machine can also be classified by where its object sits (LDAP Distinguished Name) or by the directory groups it is in (LDAP Group Membership) — both added in 1.2.7, see directory-based classification. Three things about them are worth knowing before you write one:

• A DN is matched component-wise, never as a substring. A rule for OU=Computers,DC=corp,DC=local does not also capture OU=Computers-Test,DC=corp,DC=local. One semantic covers both uses: name a container and it matches that container’s whole subtree; name a full object DN and it matches that one object.
• The rule carries the Directory it speaks about. With several forests joined, the same DN — and certainly the same group name — exists in more than one, and an unscoped rule is how a machine from one domain lands in a group written for another. Leaving it as None means “any directory”.
• Matching on group membership needs a computer’s memberOf, which nothing was importing. Collecting it is a switch of its own — Group membership, under Groups on the LDAP configuration’s Computer Sync tab (Settings → Integrations → LDAP) — and it is off by default, because an upgrade must not start recording which groups your machines are in without being asked. Turning it back off stops the collection and keeps what was already collected. The endpoint’s card then lists every group the directory reports for that machine, which is what answers “why did my rule not fire”.

Since 1.2.7 computer sync is not Active Directory’s alone: it runs on FreeIPA, OpenLDAP and generic LDAP too, and the difference is one line of filter — (objectClass=computer) on AD, (objectClass=ipaHost) on FreeIPA, (objectClass=ieee802Device) on an OpenLDAP that keeps machines the RFC 2307 way. The form prefills it from the directory type you chose. Google Workspace is the one type that still declines: Secure LDAP serves users and groups, and devices live behind an API no filter reaches.

That difference matters here more than it looks. FreeIPA and OpenLDAP both publish macAddress, so a machine there becomes a real endpoint on the first sync, before it has ever authenticated — and is classified before its first connection. Active Directory has no standard attribute for a MAC, so its computers are staged in Pending Computers instead and only become endpoints when a certificate supplies the address. Pending Computers is an Active Directory concept; on the other directory types you will not see that list fill up. See Computers.

This is the step that decides whether SSO works or merely appears to. Everything here happens in NAC → Policies → Policy Table.

Start from what a fresh install gives you. The seeded rules are Dot1x Known Users → Corporate (method PEAP) and MAB Known Endpoints → Restricted (method MAB), then Default — Reject at the bottom. Policy compares the method exactly, so neither of the first two catches an EAP-TLS session at all: until you add rules of your own, both phases fall straight through to the reject.

Add a rule for the machine phase — method EAP-TLS, matching the endpoint group, granting whatever a pre-logon machine should get:

Add rule appends the new rule below every existing non-default one, so it is the wrong control for the second of the pair. Add the machine rule first, then use ↑ Insert rule above on that row to place the user rule ahead of it.

The same reasoning explains a symptom worth recognising, and it is worth being precise about which rules can cause it. A rule whose Method is MAB cannot swallow the machine phase — the method is compared exactly, and an EAP-TLS request is not MAB. What can swallow it is a rule whose method is Any: it matches every method, and if its only other condition is the endpoint group it will take the machine phase before your EAP-TLS rule ever sees it — sending domain computers into whatever restricted VLAN that rule was built for. If pre-logon machines land somewhere surprising, look at every Any-method rule above yours, not just the one you added.

Enough to be a domain member and nothing more: reach the domain controllers, DNS, your management systems. It does not need what the logged-in user needs, and this is the phase an unattended machine sits in overnight. Whether that is a separate VLAN or the same one with a tighter ACL is a design decision — see NAC policy.

In the adapter’s Advanced settings:

User or computer authentication, with single sign-on performed immediately before user logon.

Reboot the machine, wait at the logon screen, then sign in. Open Logging & Reports → NAC Logs → Auth Log, set Auth Method to EAP-TLS and Endpoint MAC to this machine’s address, and read it bottom-up. A correctly configured port produces two accepts a logon apart, both EAP-TLS, on the same MAC — differing in the Rule and VLAN they landed on.

Telling the two apart is easier than it sounds: Taranac writes a Username on the row only when the certificate resolved to an account, and a machine certificate resolves to none. The machine phase is normally the row with no username; the user phase carries the UPN.

Filtered to EAP-TLS and to this one machine’s MAC, so the port’s whole story is on screen. Read the Rule and VLAN columns of each row — this is the view that exposes a phase landing somewhere you did not intend.

Check three things in those rows, in this order:

1. The machine phase is an accept, not a reject. A reject whose Rule is Default — Reject means the endpoint was not in your group yet — see the classification callout in Step 2. Its Reject Reason reads policy_reject: the NAC Auth Log prints that column exactly as the engine recorded it, with no translation, so every reason on this page shows as a raw token in every interface language.
2. Each phase matched the rule you intended. The rule name is in the row. This is where a machine phase landing on an Any-method rule, or a user phase landing on the machine rule, becomes visible.
3. The VLANs are the ones you designed, and if they differ between phases, that the client actually re-addressed after logon.

• EAP-TLS for domain users — trust, issuance, supplicant
• Endpoints — endpoint groups and classification rules
• NAC policy — conditions, first-match-wins, CoA
• LDAP directories — directory and computer sync, including group membership