Every call an agent makes to the server runs over mutual TLS, authenticated by a certificate the product’s own internal CA issued at enrolment. What decides how much that certificate is trusted with, though, is not the certificate itself but how the agent proved its identity to get one. A domain-joined machine authenticates as its own computer account before it ever enrols; a machine that cannot do that enrols on a bearer token alone, and is deliberately capped in what it can be trusted with as a result.
How it works
Enrolment classifies a machine from what actually authenticated the request, never from anything the machine merely claims about itself. A Kerberos machine identity produces a domain agent; no authentication at all produces a workgroup agent, if the operator has chosen to allow that path; and NTLM, or a Kerberos attempt that failed outright, is refused rather than quietly downgraded to the weaker path — a machine having a bad day with its ticket has to fix it and retry, not fall back to something weaker. The install token is required on both paths regardless, because it also carries the target group — the routing decision of which fleet policy a new agent joins — so a valid Kerberos identity without a valid token still does not enrol.
The domain path
A domain-joined agent runs as the Windows local system account, which lets it authenticate over
Kerberos as its own computer account automatically, with nothing to configure or store. The server
reads the machine’s SID from that authenticated session — never from anything the request itself
says — looks the computer up in Active Directory over LDAPS, and takes the hostname from AD’s own
dNSHostName rather than whatever the agent reported, so the name shown in the console cannot be
forged. If that directory lookup cannot be completed, enrolment is refused outright rather than
proceeding on the Kerberos proof alone. A machine that re-enrols — a certificate rotation, a
reinstall, a reimage — supersedes its own previous row instead of leaving a duplicate, because its
identity is the AD account itself rather than a name it typed in.
The workgroup path, and what it gives up
A genuinely non-domain machine has no computer account to authenticate as, so it enrols on the install token alone. This path is off by default, and an operator has to turn it on deliberately before any machine can use it. Three things a domain agent gets are given up here, precisely:
- An unforgeable hostname. There is no directory to check a workgroup machine’s claimed name against, so it is recorded as self-asserted rather than authoritative — the console marks it with a workgroup badge for exactly that reason.
- Eligibility for a domain credential. A workgroup agent can only ever be assigned a local account credential; the server refuses a domain credential outright even if one is somehow submitted for it.
- A second factor on top of the token. A domain agent’s Kerberos ticket is something the token cannot substitute for — a leaked token alone cannot enrol a machine as a domain agent, because the machine key still has to be present. A workgroup enrolment has no equivalent second proof; the token is the whole of it.
Nothing here is a bug to be patched — it is what makes the fallback honest. Autologon Manager caps what a workgroup identity can be trusted with rather than pretending to verify an identity that has no cryptographic anchor to check. What it still catches: a workgroup machine cannot enrol under the same name as an existing active agent and be mistaken for it, so an attacker with a leaked token can add a new plausible-looking machine but cannot impersonate one already in the fleet. A domain-joined machine never quietly takes this path for itself — one that cannot momentarily reach a domain controller keeps insisting on Kerberos and retrying, rather than falling back and forfeiting its own eligibility for a domain credential.
Mutual TLS between agent and server
Every agent holds a client certificate the internal CA issued at enrolment, and every call on the agent port is mutual TLS: the agent checks the server’s certificate against a fixed identity baked into the pin rather than whatever hostname it happened to dial, and the server checks the agent’s certificate against an allow-list rather than a certificate revocation list. Dropping an agent from that allow-list refuses its very next poll immediately — the whole revocation mechanism, with nothing external to publish or keep online. Enrolment itself runs on a separate port that never asks for a client certificate, for the obvious reason that an unenrolled agent does not have one yet; the two are split at the TLS layer rather than negotiated within a single connection, because asking for a certificate that might not be offered stalls a modern TLS handshake for around thirty seconds.
Limits
Losing the CA’s own private key is a whole-fleet event. Every agent certificate was signed by that CA, so its loss invalidates all of them at once, and recovery means standing up a new CA and re-enrolling every agent. Back up the server’s PKI data directory alongside its database for exactly this reason.
The workgroup path’s residual risk is accepted, not eliminated. A self-asserted hostname is capped to a local credential on a machine the requester already controls; the hostname itself still proves nothing.
There is no cross-forest or multi-domain support yet. The domain path currently assumes the server and its agents sit in one domain. A deployment spanning multiple domains or forests has to use the workgroup path today, or wait for that as a documented future capability.
Revocation has no external, standards-based check. The allow-list is authoritative for this product’s own server and agents, but there is no CRL or OCSP endpoint a different relying party could consult about an Autologon Manager certificate.