Discover LDAP naming contexts and authenticated search

Needs: Reachable directory; anonymous query permission or valid bind identity; required signing/TLS and naming context

Discover naming contexts

Prerequisite: LDAP reachability. Coverage: RootDSE only; this can work even when directory searches require authentication. Decisive output: defaultNamingContext and dnsHostName.

# Baseline: discover naming contexts
ldapsearch -x -LLL -H ldap://TARGET:389 -s base -b '' \
  defaultNamingContext rootDomainNamingContext configurationNamingContext dnsHostName

# LDAPS and certificate-name inspection
openssl s_client -connect TARGET:636 -servername DC_HOST </dev/null
ldapsearch -x -LLL -H ldaps://DC_HOST:636 -s base -b '' defaultNamingContext dnsHostName

Anonymous directory search

Prerequisite: known base DN and server permitting anonymous search. Failure cue: Inappropriate authentication or Insufficient access closes only the anonymous path.

# Anonymous directory search
ldapsearch -x -LLL -H ldap://DC_IP:389 -b 'DC=DOMAIN,DC=TLD' \
  '(&(objectCategory=person)(objectClass=user))' \
  sAMAccountName userPrincipalName memberOf description

# Anonymous directory search
ldapsearch -x -LLL -H ldap://DC_IP:389 -b 'DC=DOMAIN,DC=TLD' \
  '(objectClass=group)' cn member description

Authenticated search

Prerequisite: a valid directory identity. Decisive output: objects/attributes unavailable anonymously. Avoid placing a real password in shell history when an interactive prompt is available.

# Authenticated search
ldapsearch -x -LLL -H ldap://DC_HOST:389 \
  -D 'USER@DOMAIN.TLD' -W -b 'DC=DOMAIN,DC=TLD' \
  '(&(objectCategory=person)(objectClass=user))' \
  sAMAccountName userPrincipalName memberOf description servicePrincipalName userAccountControl

# Search computers, groups and SPN-bearing accounts separately
ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN.TLD' -W \
  -b 'DC=DOMAIN,DC=TLD' '(objectClass=computer)' \
  dNSHostName operatingSystem operatingSystemVersion servicePrincipalName

ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN.TLD' -W \
  -b 'DC=DOMAIN,DC=TLD' '(objectClass=group)' cn member

ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN.TLD' -W \
  -b 'DC=DOMAIN,DC=TLD' '(&(objectCategory=person)(servicePrincipalName=*))' \
  sAMAccountName servicePrincipalName memberOf

# Establish
getent hosts DC_HOST
nc -nvz DC_IP 88
date -u
nmap -Pn -sV -p 88,389,445,464,636,3268,3269 DC_IP -oN dc-services.txt

Interpretation: resolve DOMAIN and DC_HOST consistently, keep clock skew within Kerberos tolerance, and ensure the KDC is reached through the selected route. KDC_ERR_C_PRINCIPAL_UNKNOWN points to identity/domain naming; KRB_AP_ERR_SKEW points to time; KDC_ERR_PREAUTH_FAILED normally points to authentication material.

New users, groups, computers, SPNs or domain names → domain mapping.

A user confirmed without preauthentication → Kerberos and identity transitions.

Valid credentials → rerun authenticated LDAP plus SMB/share/remote-access enumeration.

Certificate templates/AD CS clues → AD CS and object-control abuse.

Verify → Record DC, base DN, bind identity and actual returned attributes; RootDSE alone is not a complete directory dump.

If it fails → Stronger-auth-required may mean TLS/signing policy; invalid credentials or an empty base require different fixes. More detail ↓

If → then

Domain credentials or a domain-joined foothold → Establish domain identity, DC, DNS, time and route
Needs: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew
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
A user-owned SPN and a useful service-account relationship → Request a selected service ticket for offline service-account recovery
Needs: A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy

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

Explanation & examples

Discover LDAP naming contexts and authenticated search

USE WHEN: LDAP/Kerberos listeners or a probable AD domain
STARTING ACCESS: A confirmed reachable application; anonymous context or one identified credential
RESULT: A directory base DN and permitted account/group/computer attributes

Recognize the clue

Identify the directory endpoint and query RootDSE before a subtree search under a known bind identity.

ldapsearch -x -LLL -H ldap://DC_IP -s base -b '' defaultNamingContext namingContexts

SYNTHETIC EXAMPLE OUTPUT

dn:
defaultNamingContext: DC=DOMAIN,DC=TLD

Means: RootDSE supplies the search base; it does not grant arbitrary anonymous subtree access.

Confirm: Check bind identity, transport/signing requirements and read visibility on the selected objects.

After validation: A correctly authenticated scoped search returns expected objects: continue domain mapping.
Ruled out in this context: Anonymous subtree search is denied: reject anonymous enumeration while retaining a known-authenticated option.
Still inconclusive: An empty result may be the wrong base/filter or ACL visibility; compare a known object.

Troubleshooting: Stronger-auth-required may mean TLS/signing policy; invalid credentials or an empty base require different fixes.

Additional prerequisite checks

ldapsearch -x -H ldap://DC_IP -s base -b '' namingContexts defaultNamingContext

Recognition: LDAP commonly appears on TCP/389 or TCP/636; Global Catalog on TCP/3268 or 3269; Kerberos on TCP/UDP 88. Applications may listen elsewhere, so follow protocol evidence rather than port labels.

Baseline: discover naming contexts

Prerequisite: LDAP reachability. Coverage: RootDSE only; this can work even when directory searches require authentication. Decisive output: defaultNamingContext and dnsHostName.

Convert DC=corp,DC=example into corp.example for DNS/Kerberos work. Preserve the server's exact hostname because Kerberos is name-sensitive.

LDAPS and certificate-name inspection

A certificate can disclose domain/DC names. A TLS validation error is a client trust/name issue, not proof that LDAP is unavailable.

Anonymous directory search

Prerequisite: known base DN and server permitting anonymous search. Failure cue: Inappropriate authentication or Insufficient access closes only the anonymous path.

Authenticated search

Prerequisite: a valid directory identity. Decisive output: objects/attributes unavailable anonymously. Avoid placing a real password in shell history when an interactive prompt is available.

Search computers, groups and SPN-bearing accounts separately

Kerberos prerequisites before an attack

Kerberos failures are often name/time/route failures rather than credential failures. Establish:

Interpretation: resolve DOMAIN and DC_HOST consistently, keep clock skew within Kerberos tolerance, and ensure the KDC is reached through the selected route. KDC_ERR_C_PRINCIPAL_UNKNOWN points to identity/domain naming; KRB_AP_ERR_SKEW points to time; KDC_ERR_PREAUTH_FAILED normally points to authentication material.

Handoff

New users, groups, computers, SPNs or domain names → domain mapping.
A user confirmed without preauthentication → Kerberos and identity transitions.
Valid credentials → rerun authenticated LDAP plus SMB/share/remote-access enumeration.
Certificate templates/AD CS clues → AD CS and object-control abuse.

Why it works

RootDSE can disclose naming contexts without permitting subtree enumeration. A bind identity, search base and attribute/object ACLs independently constrain results.

Worked example · hypothetical

Observation: RootDSE returns a base DN. Test: attempt the permitted scoped search with the appropriate bind. Illustrative output: anonymous search is denied but a domain bind succeeds. Interpretation: continue authenticated domain mapping.

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

Study guide ↗Full procedure ↗Cheatsheet ↗