From Windows Hello to AD Resources: PRT, Trust and Ticket Paths

1. Core mechanism

12.04 introduced device join state and Windows Hello keys. This lesson follows the path from a user key to an AD resource, preserving the TGT, service-ticket and resource-decision distinction from 06.02.

Interfaces and specifications

• The WHfB user private key stays on the device; a PIN or biometric gesture enables local use.
• A PRT belongs to Entra cloud/broker context; it is not an AD service ticket presented to SMB.
• The cloud Kerberos trust partial TGT is an input to obtaining a full AD TGT at a writable on-prem DC.
• Key trust relies on public-key lookup and DC certificate validation; certificate trust uses user/DC certificate chains.
• Service-ticket issuance, service authentication validation and resource authorization are distinct stages.

Device identity is not the user credential

Entra joined or hybrid joined describes the device relationship. The user’s WHfB key is a separate credential. The gesture enables key use; sending the PIN to a remote DC as a password is not this model.

CloudAP and the broker manage cloud sign-in context. The user key and device transport key also have different roles. Track each key through its owner and protected data rather than treating every “token” as the same object.

Cloud trust: two authorities and two stages

In the provisioned cloud-trust example, Entra authentication succeeds and a PRT plus Entra Kerberos partial TGT are available. The partial TGT does not replace the full AD authorization context. The client locates a writable DC, which validates the partial TGT and issues a full AD TGT.

A service ticket is then requested for the resource SPN. The service validates it and evaluates the file right under its own resource conditions. In the fresh-ticket scenario, unavailable DC connectivity can stop the on-prem path while cloud success remains unchanged. Existing tickets or sessions represent different starting states.

Where do key trust and certificate trust differ?

Key trust uses the registered user public key in AD and validation of the DC certificate. Hybrid deployment has a public-key synchronization dependency. Do not confuse key lookup with a requirement for a CA-issued user authentication certificate.

Certificate trust adds a user certificate and issuer trust, validity/revocation and account-mapping checks. Cloud trust reduces PKI and user-key-sync requirements; it does not eliminate the on-prem DC or resource permission boundaries.

Cloud succeeds and the file fails: where do you start?

First establish effective trust policy and whether the context is fresh or reused. Then distinguish partial/full TGT, writable DC reachability, service ticket and target decision using separate observations. A device join label cannot verify this entire chain.

Microsoft Entra Kerberos uses an RODC-like object trust boundary in AD; it is not a separate branch RODC host. Preserve privileged-account restrictions. Verify client/DC versions and patch prerequisites against current deployment requirements; the exercise is not a lab result.

State and data flow

1. A local gesture enables use of the WHfB user key on the device.
2. The trust type selects the cloud, key or certificate route and prerequisites.
3. In the cloud route, the PRT and partial TGT are separate cloud objects.
4. After the required validation, a writable AD DC issues a full AD TGT.
5. A service ticket is obtained for the resource SPN and validated by the service.
6. The resource READ decision is a separate authorization boundary.

2. Exploitation

Broken trust assumption

Treating cloud sign-in or device join success as a guarantee of on-prem identity and resource permission.

Technical prerequisites

• An impact claim requires the relevant target, effective right and observed context.

Exploitation mechanism

Registration authority, trust objects and resource ACLs have different owners. Do not confuse an overly broad writer scope at one boundary with another authority’s decision. Bound risk to established registration and permission scope.

A cloud outcome does not substitute for an AD decision

A present PRT establishes cloud broker context. It does not establish a full AD TGT or a ticket for a particular resource SPN. A resource-permission claim needs the target context and requested right.

Consider administration boundaries together

Record change ownership and effective permissions for user-key registration and Entra Kerberos trust administration. Removing privileged-account protection is not a normal troubleshooting step; first identify the authority where progress stopped.

3. Defense & Detection

Telemetry scope

• Record join, effective trust policy, provisioning, cloud context, partial/full TGT and target decision separately. Do not combine observations from different times into one sign-in outcome.

Events and relevant fields

• Event records reflect their producer’s decision under applicable generation and collection conditions; they do not establish the entire access chain.

Preserve the scope of evidence

Record join, effective trust policy, provisioning, cloud context, partial/full TGT and target decision separately. Do not combine observations from different times into one sign-in outcome.

Do not treat an absent event as negative evidence without generation and collection coverage. Verify new behavior at its responsible owner.

Detection logic · XPath

*[System[(EventID=4768 or EventID=4769 or EventID=4624)]]

Query assumptions

• This selects candidate events only in applicable Windows Security logs. The lesson JSON worksheet is not a Windows event.
• Record join, effective trust policy, provisioning, cloud context, partial/full TGT and target decision separately. Do not combine observations from different times into one sign-in outcome.

False positives

• Legitimate changes, context/cache reuse or temporary connectivity issues can produce the same symptom; this selection does not classify an attack.

Hardening

• Verify trust-policy precedence and client/DC prerequisites.
• Distinguish first use from cached/existing context; locate the writable-DC dependency on the ticket path.
• Restrict key-registration and trust-administration rights and preserve privileged-account restrictions.

Read the examples

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "N03",
  "clientRelease": "Windows 11 24H2 (exercise profile; exact build unspecified)",
  "join": "Entra hybrid joined",
  "trust": "cloud Kerberos trust",
  "cloudBrokerContext": "granted",
  "partialTGT": "available",
  "writableDCReachable": false,
  "fullADTGT": "not-observed",
  "targetServiceTicket": "not-observed",
  "existingTargetSession": false
}

Two reality checks

Assumption: A PRT means the AD share ticket is available.

In fact: A PRT is cloud/broker context. A full AD TGT, resource service ticket and READ permission are separate conditions.

Assumption: Cloud trust removes the on-prem DC dependency.

In fact: This fresh-ticket path requires a writable DC to exchange the partial TGT for a full AD TGT. Existing context is a different starting state.

Sources

• WHfB authentication operation
  Microsoft Entra authentication; on-premises cloud/key/certificate trust flows
• Primary Refresh Token
  Key terminology; issuance/sign-in/renewal; CloudAP/WAM; device keys
• WHfB hybrid cloud Kerberos trust
  Prerequisites; Microsoft Entra Kerberos; policy; deployment validation; first sign-in
• WHfB deployment planning
  Deployment/trust types; PKI requirements; OS requirements table
• KB5014754 certificate mapping
  Timeline; strong/weak mapping; KDC event guidance; Schannel distinction