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 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. Create an endpoint group — Corporate Devices — and give it rules that recognise a domain machine, for example by certificate (issued by your AD CS) and by hostname. Any endpoint matching either rule joins the group. See Endpoints.

AD computer sync. On the LDAP domain, enabling computer synchronisation imports Active Directory computer objects as endpoints — before those machines ever authenticate. When a machine certificate then arrives, Taranac binds the authenticating endpoint to the matching AD computer by hostname and carries over its directory data: distinguished name, GUID, operating system, description.

This is the step that decides whether SSO works or merely appears to.

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

The same reasoning explains a symptom worth recognising: a machine phase that matches a rule written for MAB. A MAB rule conditioned on the same endpoint group will match an EAP-TLS machine request too, since it also has no user — sending domain computers into whatever restricted VLAN you built for unknown devices. If pre-logon machines land somewhere surprising, look at every rule whose only condition is that endpoint group, 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 → NAC → Authentication and read it bottom-up. A correctly configured port produces:

accept  eap_tls  host/PC-DEMO-01.lab.taranac.pro   ← machine phase, at boot
accept  eap_tls  ad_user1@lab.taranac.pro          ← user phase, at logon

Filtered to EAP-TLS and to this one machine’s MAC, so the port’s whole story is on screen. The machine phase identifies itself as host/<fqdn>; the user phase as the UPN. Read the rule and VLAN columns of each row — this is the view that exposes a phase landing somewhere you did not intend.

The screenshot above is worth reading as a diagnosis rather than a success. The machine phase was first rejected against Default — Reject — classification had not yet placed the endpoint in its group — and then, once it had, accepted into a rule built for MAB, landing in the restricted VLAN 30 while the user phase correctly reached VLAN 10. Both symptoms in this guide, in one port’s history.

Check three things in those rows, in this order:

1. The machine phase is an accept, not a reject. A reject naming the default rule means the endpoint was not in your group yet — see the classification callout in Step 2.
2. Each phase matched the rule you intended. The rule name is in the row. This is where a machine phase landing on a MAB 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