Establish domain identity, DC, DNS, time and route

Needs: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew

Domain-joined Windows source

REM Domain-joined Windows source
whoami /all
echo %USERDNSDOMAIN%
echo %USERDOMAIN%
echo %LOGONSERVER%
nltest /dsgetdc:DOMAIN
nltest /dclist:DOMAIN
w32tm /query /status

Domain-joined Windows source

# Domain-joined Windows source
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.DOMAIN
Resolve-DnsName -Type SRV _kerberos._tcp.DOMAIN

Decisive output: domain FQDN, DC FQDN/IP, current user SID/groups, DNS SRV answers and a plausible time source. USERDOMAIN can be a NetBIOS label; prefer the DNS domain for LDAP/Kerberos.

Kali/off-domain source

# Kali/off-domain source
dig +short SRV _ldap._tcp.dc._msdcs.DOMAIN @DC_IP
dig +short SRV _kerberos._tcp.DOMAIN @DC_IP
nxc smb DC_IP -d DOMAIN -u USER -p 'PASSWORD'
ldapsearch -x -LLL -H ldap://DC_HOST:389 -s base -b '' \
  defaultNamingContext configurationNamingContext rootDomainNamingContext dnsHostName

Remote Windows session and double-hop caveat

REM Remote Windows session and double-hop caveat
whoami /all
klist
dir \\DC_HOST\SYSVOL

Remote Windows session and double-hop caveat

A supplied credential may create the remote session without being delegated onward to the DC. If local identity commands work but access to a second host fails, distinguish a WinRM/PowerShell remoting credential-delegation problem from invalid credentials. An interactive RDP session, explicit credentials, /netonly network credentials or an off-domain LDAP client may create a different context; always record which identity is used locally and over the network.

# Remote Windows session and double-hop caveat
IDENTITY MAP: USER/COMPUTER -> DIRECT + NESTED GROUPS -> DIRECTORY RIGHTS
HOST MAP:     COMPUTER -> OS/ROLE -> LOCAL/REMOTE-ACCESS RIGHTS -> SESSIONS
ROUTE MAP:    SOURCE -> DNS/KDC/DC/HOST -> REQUIRED PORT/SERVICE
LEAD MAP:     EVIDENCE -> HYPOTHESIS -> MINIMUM VALIDATION -> NEXT BLOCK

# Remote Windows session and double-hop caveat
AS-REQ/AS-REP: user proves knowledge of long-term key -> receives TGT
TGS-REQ/TGS-REP: TGT requests SERVICE/HOST -> receives service ticket
AP-REQ: client presents service ticket -> service authenticates client
AUTHORIZATION: target service still evaluates the represented identity/claims

Before changing credentials or tools

# Before changing credentials or tools
getent hosts DC_HOST
nc -nvz DC_IP 88
date -u

Remote Windows session and double-hop caveat

REM Remote Windows session and double-hop caveat
w32tm /query /status
klist

Verify → Record represented identity, realm, selected DC, resolver, clock and real source route.

If it fails → Wrong domain, KDC timeout, clock skew and account denial are distinct failures. Do not repeatedly change passwords to fix a route problem. More detail ↓

If → then

A directory bind or domain-joined identity can read relevant objects → Enumerate directory objects with native, LDAP and PowerView approaches
Needs: Correct search base and authentication transport; object/attribute visibility and compatible local utilities
An IP connection works while hostname/Kerberos access fails → Preserve DNS, Kerberos names and time across a pivot
Needs: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time
A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization
Needs: Real source-to-service route, correct identity context and protocol-specific execution/logon rights

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

Explanation & examples

Establish domain identity, DC, DNS, time and route

USE WHEN: Domain credentials or a domain-joined foothold
STARTING ACCESS: A known domain identity or a directory endpoint that permits the selected anonymous query
RESULT: A verified domain context and working directory/authentication preflight

Recognize the clue

Start with the session identity and known credential scope; discover the realm/DC and inspect DNS, time and routes.

whoami /all
whoami /upn
nltest /dsgetdc:DOMAIN
w32tm /query /status

SYNTHETIC EXAMPLE OUTPUT

UPN: USER@DOMAIN
DC: \\DC_HOST
Domain name: DOMAIN
Clock source/status: inspect

Means: The named realm/DC and actual identity establish where directory/authentication checks must run.

Confirm: Check DC/service reachability, resolver/SPN naming and clock compatibility, not merely the password.

After validation: A normal bind/ticket request works in the intended realm: continue domain mapping.
Ruled out in this context: The credential belongs only to the target-local account: reject the assumed domain identity.
Still inconclusive: DC lookup/time failure leaves domain authentication untested.

Troubleshooting: Wrong domain, KDC timeout, clock skew and account denial are distinct failures. Do not repeatedly change passwords to fix a route problem.

Domain-joined Windows source

Decisive output: domain FQDN, DC FQDN/IP, current user SID/groups, DNS SRV answers and a plausible time source. USERDOMAIN can be a NetBIOS label; prefer the DNS domain for LDAP/Kerberos.

Kali/off-domain source

RootDSE is a directory-server metadata object. Reading it can reveal naming contexts even when anonymous subtree searches are denied. Convert corp.example to DC=corp,DC=example; do not guess the base DN when RootDSE can supply it.

Remote Windows session and double-hop caveat

A supplied credential may create the remote session without being delegated onward to the DC. If local identity commands work but access to a second host fails, distinguish a WinRM/PowerShell remoting credential-delegation problem from invalid credentials. An interactive RDP session, explicit credentials, /netonly network credentials or an off-domain LDAP client may create a different context; always record which identity is used locally and over the network.

Authentication, authorization, reachability and session presence are independent. A valid LDAP bind does not prove share access; SMB administration on one host does not prove directory privilege; a session edge does not prove retrievable credentials.

Before changing credentials or tools:

Record domain FQDN/realm, DC FQDN/IP, source DNS, current time, KDC route and exact target SPN. IP connectivity does not replace hostname/SPN correctness.

Why it works

Local process identity, network credential context and domain naming are separate. Kerberos depends on service names, time and KDC connectivity in addition to a valid password.

Worked example · hypothetical

Observation: a valid domain password fails in a ticket-based client. Test: inspect DC naming, DNS, route and time. Illustrative output: the KDC is unreachable through the current route. Interpretation: fix transport before judging the credential.

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

Study guide ↗Full procedure ↗Cheatsheet ↗