Sources, review date and section shortcuts
Reviewed: October 19, 2026. A connected rpcclient prompt does not establish permission for SAMR user enumeration or other RPC operations.
Primary documentation · Related practical guide
Go straight to: Decision check · Main workflow · Further detail
Open the RPC operation coverage table for this guide’s task-specific fields and next action.
Match the call to its interface and object
Record the exact RPC call, target, session identity, binding context and returned status. Permission is evaluated for individual interfaces and operations. A successful name lookup or server-info response establishes only that narrow result, and output can contain server-supplied hints. Use read-only calls within scope and stop when an authorization boundary is clear rather than cycling through names to bypass it. Reference and scope.
Beyond the enumdomusers Dead End
When rpcclient connects but enumdomusers fails, you have not hit a dead end—you’ve hit a badge reader. The session is real; the door is just the wrong one.
While most testers resort to tool-hopping and “retry-spamming,” the target is often just enforcing partial SMB/RPC rights. This post introduces the “Leak Ladder”: six low-noise commands to extract defensible signals without triggering a recon fireworks show.
- ✔️ Confirm host identity and share names.
- ✔️ Pull domain/local SID threads via
lsaquery. - ✔️ Test bounded
lookupsids. - ✔️ Verify group enumerability vs. user blocks.
Run it once. Log it once. Let the boundary speak.
If
rpcclient connects but enumdomusers fails, you often still have a valid session with partial RPC rights. Don’t brute-force. Pivot to lower-privilege calls that can still reveal domain/workgroup identity, policy hints, share names, SIDs, and account lockout posture. Use a small “leak ladder”: confirm server/domain context, grab SIDs and names where allowed, map shares, and document exact errors for your report.
Who this is for / not for
For: defenders validating exposure from anonymous/guest/low-priv sessions
If you’re blue team, you’re often asking a different question: “What can an unauthenticated or low-priv session learn about us?” That’s exactly what this Leak Ladder measures. It helps you label a finding accurately: least privilege enforced vs legacy info disclosure.
Not for: breaking into systems, evading controls, or testing without written permission
We’re staying in the lane: authorized contexts only, and no instructions aimed at bypassing controls. If a boundary holds, we document it. If something leaks, we document it. If you find yourself thinking “what if I just…,” that’s your cue to pause and check scope.
Quick scope check: what counts as “safe enumeration” in a report
Safe enumeration in most US engagements looks like this: read-only discovery, bounded volume, and no credential guessing. Practically, that means:
- No brute-force (passwords, hashes, RID sprays at scale).
- No high-volume loops that look like automated recon unless explicitly approved.
- Every command logged with timestamp, target, and exact error.
- Bound volume and retries
- Prefer read-only, low-impact calls
- Write down exact
NT_STATUS_*strings
Apply in 60 seconds: Add a “Noise Budget” note in your log: max 1 retry per command unless scope says otherwise.
The failure pattern: “Connects” isn’t “Enumerates”
What rpcclient success actually proves (and what it doesn’t)
When rpcclient connects, it proves something beautifully boring: you reached the service, negotiated the session, and your auth context (even if guest/anonymous) was accepted enough to open a channel. That’s it. It does not prove you have rights to enumerate domain users, read SAM-like lists, or query sensitive policy. Think of it as being let into a building lobby. Elevators still need badges.
Why enumdomusers is a privilege boundary, not a reliability test
enumdomusers sits behind access checks that are commonly tightened by modern baselines. On hardened systems, “list all users” is treated as sensitive metadata. That’s not a bug. That’s the system doing its job. Your goal is not to force it open. Your goal is to measure what’s still exposed without pushing the target into defensive posture.
The three usual culprits: auth context, RPC access rights, and domain role
- Auth context mismatch: You’re “guest” when you thought you were a user, or you’re sending a domain format the server rejects.
- RPC rights: Session is valid but lacks rights for domain user enumeration.
- Domain role mismatch: You’re asking a member server questions that only a DC (or the right authority) can answer.
Show me the nerdy details
RPC operations have separate access checks. NT_STATUS_ACCESS_DENIED identifies a denied operation or bind at the observed stage; it does not by itself establish the accepted identity or prove the whole environment is hardened. NT_STATUS_RPC_PROCNUM_OUT_OF_RANGE indicates an unavailable procedure/interface-version mismatch, not a permission verdict or DC-role proof.
Leak Ladder Step 1: Confirm identity and role (without touching users)
This step is where you stop guessing and start measuring. The objective: confirm what you’re actually talking to, and what it’s willing to reveal without poking user lists. Two commands, low drama.
Command 1: srvinfo (server flavor, domain/workgroup hints)
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'srvinfo'Command 2: netshareenum (share names that reveal app + org structure)
Share names are the quiet gossip of SMB. Even when ACLs block access, names can leak: department structure, backup habits, app servers, legacy migrations, vendor tooling. netshareenum is a classic “low-priv, high-context” call when it’s allowed.
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'netshareenum'Mini interpretation table: what “IPC$ only” vs “many shares” implies
| What you see | What it usually implies | Report phrasing idea |
|---|---|---|
Only IPC$ | Tighter config, limited disclosure, or restricted interface access | “Share name enumeration appeared restricted to default administrative endpoints.” |
| Multiple named shares | Info disclosure surface exists even if share access is denied | “Unauthenticated/low-priv session could enumerate share names, exposing internal structure.” |
Leak Ladder Step 2: Pull the SID thread you can actually tug 🧵
If user listing is blocked, SIDs are often still the thread you can tug without tearing the sweater. This is where you learn “who the authority is” and whether name resolution is possible at all.
Command 3: lsaquery (domain name and SID context)
lsaquery can expose the name and SID of the policy domain available to that endpoint. This provides naming context; it does not alone prove DC/member role, trust configuration, password policy or account lockout thresholds. Confirm those using the appropriate permitted query or owner documentation.
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'lsaquery'Command 4: lookupsids <SID-range> (turn SIDs into names when allowed)
If you have a domain SID (or local SID context), you can attempt small, bounded lookups. The goal is not to spray. The goal is to test whether SID-to-name translation is permitted and capture what’s revealed at low volume.
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'lookupsids S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX-500 S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX-501'Here’s what no one tells you…
Even failed lookups can be meaningful. If the target returns consistent errors for certain SID patterns but behaves differently for others, it can hint at what’s resolvable in that context. The ethical line is simple: document that behavior, don’t weaponize it. In a report, you’re proving exposure and control boundaries, not chasing cleverness for sport.
lsaqueryanswers “what authority is this?”lookupsidsanswers “can I translate identity at all?”- Bound lookups keep your signal clean
Apply in 60 seconds: Limit yourself to 2–6 SID lookups total on first pass, then stop and assess.
Leak Ladder Step 3: When users won’t list, groups sometimes will
User enumeration is often blocked first. Group metadata sometimes lingers longer, especially in environments that hardened one side of the house but forgot the back window. This matters because groups leak roles, and roles are what you write impact statements about.
Command 5: enumdomgroups (group names often leak role structure)
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'enumdomgroups'Follow-up: querygroup <rid> or querygroupmem <rid> when permitted
If you get a RID and the scope allows, you can try a single follow-up query. If it’s blocked, log the block. If it’s allowed, you’ve got excellent evidence of what can be enumerated at your current privilege level.
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'querygroup <RID>; querygroupmem <RID>'Curiosity gap: why “HelpDesk” and “SQLAdmins” matter more than usernames
Because group names translate cleanly into business risk language. “A low-priv session can identify privileged operational groups” is a crisp finding. It suggests targeted social engineering risk, credential stuffing prioritization (which you should not do without explicit permission), and highlights how role metadata increases attack planning efficiency. You’re not claiming compromise. You’re documenting exposure.
Leak Ladder Step 4: Local SAM vs domain: pick the right door
This is the part where a lot of “enumdomusers fails” complaints are actually target selection bugs. You’re asking the wrong authority the right question, and it answers by shrugging.
If it’s a member server: what “domain calls” will fail even with a session
A member server may expose its own local SAM through SAMR if permissions allow; it is not the authority for the Active Directory user database. The name enumdomusers does not make every query a DC-only operation. Record the returned SAM/domain SID and target role, then interpret the operation and error together.
If it’s a DC: why anonymous binds behave differently
Domain controllers typically have different exposure profiles based on policy and baseline. Some legacy environments still allow more anonymous metadata than they should. Hardened environments often block aggressively. Either way, your job is measurement: “what did we see,” “what was blocked,” and “what does that mean.”
Let’s be honest…
Most “it worked yesterday” stories are really “yesterday I targeted a different host” stories. The fastest sanity check is boring: confirm hostname/role from srvinfo, compare to your notes, and make sure you didn’t quietly switch from DC to member server (or the reverse) while multitasking.
- Member server ≠ domain authority
- DC behavior varies heavily with policy
srvinfofirst keeps you honest
Apply in 60 seconds: Add a one-line “Target role hypothesis” note after srvinfo and don’t change it without evidence.
Leak Ladder Step 5: Policy breadcrumbs that still matter to US reports
This section is about writing a report that survives scrutiny. US stakeholders rarely care that enumdomusers failed. They care whether the environment is enforcing least privilege, and whether any metadata exposure increases risk. (If you want a clean way to frame that story for non-technical stakeholders, this pairs well with how to read a penetration test report.)
What you can infer about lockout and password posture (without guessing passwords)
Do not infer password or account lockout policy from lsaquery or from denied enumeration. Record only the metadata returned and the exact blocked operation; establish policy through an authorized policy query or owner-provided settings. A single denial demonstrates that call’s boundary, not overall least-privilege compliance.
How to record “least privilege enforced” vs “legacy exposure” cleanly
- Least privilege enforced: Connect succeeds, user enumeration blocked, group/share/policy calls mostly denied or minimal.
- Legacy exposure: Share names, domain SID, group names, or name resolution are available to low-priv contexts.
Curiosity gap: the single error string that changes your next 30 minutes
If you see consistent NT_STATUS_ACCESS_DENIED on enumeration calls, treat it as a clean boundary and shift to documenting. If instead you see status strings that suggest “wrong authority” or “not supported” behavior (for example, procedure mismatch patterns), your next 30 minutes should be about confirming target role and interface expectations, not “trying harder.” Your energy belongs where the evidence is.
The 6 commands, packaged as a copy-paste playbook (report-friendly)
This is the practical heart of the post: a minimal-noise sequence that collects identity, exposure, and boundaries. You can paste this into your engagement notes and run it with restraint.
The “minimal noise” sequence (with expected outputs)
# 0) Start clean: one session, one variable at a time
# Replace DOMAIN/USER with the authorized username; enter the password at the prompt.
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'srvinfo'
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'netshareenum'
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'lsaquery'
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'lookupsids S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX-500 S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX-501'
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'enumdomgroups'
rpcclient -U 'DOMAIN/USER' <TARGET> -c 'querygroup <RID>'What “good” looks like (for reporting): you get a couple of clear outputs, and a couple of clear denials. That combination tells a story: what’s exposed, what’s protected, and where least privilege is holding.
Error dictionary: common NT_STATUS_* results and what they imply
| Status | Meaning in this scenario | Operator move |
|---|---|---|
NT_STATUS_ACCESS_DENIED | Session is valid, privilege boundary enforced | Stop retrying; log as control evidence (you can mirror the same crisp language used in SMBMap Access Denied write-ups) |
NT_STATUS_LOGON_FAILURE | Credential context rejected (format, domain, password) | Fix identity context; don’t brute-force (see SMBMap NT_STATUS_LOGON_FAILURE for reporting-friendly phrasing) |
NT_STATUS_RPC_PROCNUM_OUT_OF_RANGE | Call not supported on that interface/role | Re-check target role; confirm you’re asking the right door |
NT_STATUS_INVALID_PARAMETER | Malformed SID/RID or command usage mismatch | Correct inputs; keep attempts bounded |
Evidence checklist: screenshots/notes that make findings defensible
- Target: IP/hostname, timestamp, and your auth context label (e.g., “guest”, “low-priv domain user”).
srvinfooutput (or error) verbatim.netshareenumoutput including share names.lsaqueryoutput (domain SID if present) or the exact denial string.enumdomgroupsoutput (group names) or the exact denial string.- A one-line conclusion: “Partial RPC session; user enumeration blocked; metadata X/Y exposed.”
Common mistakes (loss-prevention)
Mistake 2: Hammering retries and triggering monitoring/lockouts
Repeated attempts can trip detections or cause unnecessary alarms for defenders. Even in a friendly internal engagement, nobody loves a surprise “why is SIEM screaming?” meeting. Keep retries minimal, and keep your narrative clean: one attempt, one optional retry if the command is flaky, then move on.
Mistake 3: Switching tools too fast and losing a clean causal trail
Tool-hopping is how reports become vague. If rpcclient shows a boundary, that boundary is evidence. Switching to a different tool without documenting that boundary makes it look like you’re chasing outcomes rather than measuring reality.
Mistake 4: Forgetting to log exact command + exact error (the audit killer)
“It failed” is not evidence. “rpcclient -c 'enumdomusers' returned NT_STATUS_ACCESS_DENIED at 2026-02-26 14:10 KST” is evidence. Your future self, your client, and your peer reviewer will all thank you. (If you want a repeatable way to keep evidence tidy across labs and engagements, borrow the structure from Kali Linux lab logging.)
Don’t do this: tactics that burn time or create risk
Don’t brute-force “to make it work” (your scope and ethics get messy)
If enumeration is blocked, brute-force doesn’t “fix” it. It changes the nature of the activity. It also risks account lockouts and incident response churn. If your scope explicitly permits credential testing, treat it as a separate phase with explicit controls and stakeholder awareness.
Don’t spray RID ranges blindly (signal-to-noise collapses)
High-volume RID cycling is how you turn a clean measurement into an ugly log trail. If you must do any SID/RID translation tests, keep them small and purposeful. Your goal here is to confirm whether translation is permitted, not to inventory a directory.
Don’t assume DC behavior on member servers (and vice versa)
Different roles answer differently. If you’re not sure what role you’re hitting, step back and confirm. Your confidence should be earned by output, not by vibes.
- One pass, bounded retries
- Document boundaries as wins
- Keep identity tests separate from enumeration
Apply in 60 seconds: Write “No brute-force, no loops” at the top of your notes before you begin.
The open-loop: what changed when it “worked yesterday”?
This is the part where your lab starts acting like a temperamental piano. Same fingers, different sound. The usual suspects are not magical: they’re policy and configuration drift.
SMB signing, guest policy, and hardening baselines that flip outcomes
Hardening changes can quietly tighten anonymous/guest exposure. A baseline update can turn “listable” into “blocked” overnight, especially in environments aligning to Microsoft security guidance for SMB. You don’t need to guess which GPO changed to write a good finding. You just need to capture “what was allowed” and “what is now blocked.”
Curiosity gap: a 10-second check that explains 80% of sudden failures
Run srvinfo, compare to last run, and verify you’re hitting the same host and role. Then check whether your auth context is identical. Those two checks explain most “worked yesterday” mysteries without any melodrama.
srvinfonetshareenumlsaquery → lookupsidsenumdomgroupsNT_STATUS_ACCESS_DENIED, treat it as a boundary and move into documentation mode.
Next step (one concrete action)
Run the six-command Leak Ladder once, capture outputs and errors verbatim, then write a five-sentence finding. This is the difference between “we tried stuff” and “we measured exposure.”
- Access level observed: “Session established as guest/low-priv user; enumeration partially permitted.”
- Data exposed: “Share names and group names were enumerable; domain SID was/was not revealed.”
- What was blocked: “User enumeration (
enumdomusers) returnedNT_STATUS_ACCESS_DENIED.” - Security impact: “Metadata disclosure increases attacker planning efficiency (role targeting, naming conventions, org structure).”
- Remediation: “Restrict anonymous/guest enumeration, align SMB hardening, and review policies controlling RPC exposure.”
- You’re still in low-volume, read-only calls
- Outputs are stable and consistent
- Scope explicitly covers metadata validation
- You’re tempted to loop, spray, or guess credentials
- Errors suggest you’re crossing privilege boundaries
- Defenders report alarms or instability
Neutral next action: Write “continue/stop” with a one-sentence justification in your notes before proceeding.
FAQ
Why can rpcclient connect but enumdomusers fail?
Because “connect” only proves you negotiated a session. enumdomusers is a higher-sensitivity call with stricter access checks. In many environments, you’ll get a valid session that can query server info or shares, while user enumeration is blocked by policy or role boundaries.
What does NT_STATUS_ACCESS_DENIED vs NT_STATUS_LOGON_FAILURE usually mean here?
NT_STATUS_ACCESS_DENIED means an observed operation was denied; identify whether it occurred during pipe opening, binding or a procedure call before inferring the cause. NT_STATUS_LOGON_FAILURE indicates rejected authentication context. Neither code alone proves which user was accepted.
Is enumdomusers supposed to work with guest or null sessions?
On hardened modern systems, usually not. Many organizations intentionally restrict user enumeration to authenticated contexts with appropriate rights. If it works anonymously, that can be reportable as metadata exposure depending on scope and environment expectations.
What’s the safest way to enumerate without triggering account lockout monitoring?
Keep volume low, avoid password guessing, avoid loops, and prefer read-only calls like srvinfo, netshareenum, and bounded SID translation tests when in scope. Log exact commands and stop after one optional retry if output is unstable.
Which rpcclient commands reveal domain SID or names without listing users?
lsaquery is the first place to look for domain/local policy context. If you obtain a domain SID, a small set of lookupsids translations can confirm whether name resolution is allowed at your privilege level, without attempting full user lists.
How do I tell if I’m talking to a DC, member server, or standalone host from rpcclient output?
Record identity hints and each exact RPC call/status independently. Access-denied or unsupported errors can guide a hypothesis about authority, role or permissions, but do not uniquely diagnose it. Corroborate with permitted asset context and preserve unresolved fields.
What should I put in a pentest report if only shares/groups were exposed?
Describe the session context (guest/low-priv), list the exposed metadata (share names, group names, domain SID if present), and clearly state what was blocked (user enumeration). Then explain the impact in plain English: metadata can accelerate attacker planning and targeting even without direct access to the underlying resources.
When should I stop and ask for explicit permission to continue enumeration?
Stop when the next step would involve loops, large-scale RID cycling, credential guessing, or anything that changes the risk profile of the engagement. Also stop if defenders report alarms, or if the target shows instability. Treat “permission to continue” as a safety rail, not a speed bump.
What’s the difference between local SAM enumeration and domain enumeration?
Local SAM enumeration concerns local accounts and groups on a host. Domain enumeration concerns directory identities managed by the domain authority (typically a DC). A member server can participate in a domain while still refusing to enumerate domain users because it isn’t the domain authority for that data.
Are there blue-team detections that commonly flag rpcclient usage?
Yes. Many organizations monitor SMB/RPC activity patterns that resemble reconnaissance, especially repeated enumeration calls or unusual authentication contexts. That’s another reason to keep volume low and actions tightly scoped, even in authorized engagements.
Conclusion
The curiosity loop from the top closes like this: when rpcclient connects but enumdomusers fails, you’re not “stuck.” You’re standing at a boundary that often still leaks meaningful metadata. The win is not forcing user lists. The win is producing a clean, report-ready story: what your session could learn, what it could not, and what that says about hardening and least privilege.
If you have 15 minutes, do the simplest thing that produces the best evidence: run the six-command Leak Ladder once, capture outputs and errors verbatim, and write the five-sentence finding. That’s the kind of output a client can act on, and the kind of testing a defender can reproduce without flinching.
Neutral next action: Write your noise budget at the top of your notes before running tools.
- Yes/No: Written authorization covers SMB/RPC enumeration on this host
- Yes/No: You are not guessing passwords or hashes
- Yes/No: You are not running loops or high-volume RID cycling
- Yes/No: You are logging exact commands and exact errors
- Yes/No: You will stop after the 6-command ladder unless scope says otherwise
Neutral next action: If any answer is “No,” pause and align scope before continuing.
Original review: 2026-02-26.
Technical guidance updated: 2026-10-13. Repaired copyable target/RID placeholders, replaced command-line passwords with interactive prompts, and clarified local SAM, LSA metadata and RPC error interpretation.
RPC operation coverage table
Use these fields to turn this guide into a record for your own task. Keep the actual scope, evidence and unresolved questions together.
On a small screen, scroll the table sideways to read all columns.
| Field | What to record | Your evidence / next check |
|---|---|---|
| Account context | Record the actual session identity and client revision. | To complete |
| Requested operation | Name the RPC call, target object and relevant interface. | To complete |
| Observed result | Keep success, denial and tool errors distinct. | To complete |
| Coverage limit | List operations not tested and evidence needed to resolve them. | To complete |
Next action: Treat a connected prompt as a starting condition rather than proof of enumeration rights.
Related task: Use rpcclient Access Denied: SAMR and LSARPC Boundaries for that separate part of the workflow.
Worksheet change record — October 20, 2026
Added four task-specific fields, a next action and a related guide. This is a blank editorial working aid, not a completed test or validated assessment. Existing source-review dates retain their own scope; this addition is not a new verification of every statement.