Kioptrix smbmap “NT_STATUS_LOGON_FAILURE” triage: username format + domain blank test

Stop Chasing SMB Mysteries: Mastering NT_STATUS_LOGON_FAILURE

The fastest way to waste an afternoon is treating smbmap NT_STATUS_LOGON_FAILURE like a network mystery. Port 445 is fine; the target is simply rejecting how you’re presenting identity.

NT_STATUS_LOGON_FAILURE is an authentication status, not a timeout or routing problem. It typically points to credential context issues (domain vs. local), username formats (SAM vs. UPN), or policy denials. Changing five flags at once teaches you nothing—except humility.

• ⚡ Get a fast signal without triggering account lockouts.
• 🔍 Prove identity context before chasing SMB signing or NTLM policy.
• 📝 Leave with evidence defenders can actually reproduce.

Use a five-minute, single-variable format ladder—including the explicit blank-domain test (-d '')—to quickly learn whether the host expects local SAM or Active Directory validation without noisy recursion. One variable. One host. Clean notes.

---

Who this is for / not for

Who this is for

• Authorized pentesters, internal security engineers, IT admins validating SMB access
• People who can safely test credentials without triggering lockouts

Who this is not for

• Anyone without explicit written authorization
• Anyone uncertain about account lockout thresholds or change-control windows

Operator confession: the first time I saw NT_STATUS_LOGON_FAILURE on a client job, I “fixed” it by changing five things at once and then proudly learned nothing. This post is the antidote: one variable at a time, evidence you can defend, and no helpdesk bonfires. If you need a clean framework for scope and sequencing before you touch a tool, start with a security testing strategy that prevents chaotic testing.

NT_STATUS_LOGON_FAILURE decoded: what it actually means here

The server is reachable; your auth is rejected

NT_STATUS_LOGON_FAILURE is not the same vibe as timeouts, resets, or “connection refused.” It’s the system telling you: “I heard you. I negotiated enough SMB to understand your request. And I am saying no.” In other words, the transport and basic protocol negotiation worked. You made it to the bouncer. Your name just didn’t match the guest list.

The practical implication: don’t burn time “fixing routing” if port 445 is open and the error is a logon failure. Your first win is usually identity context: domain vs local, NetBIOS vs DNS, UPN vs SAM, and “are we talking to the box we think we’re talking to?”

Open loop: one tiny character can flip the outcome

A backslash (\) is not decoration. An at-sign (@) isn’t just email cosplay. A dot prefix (.\) is a steering wheel. Those tiny characters tell the target whether to validate against local SAM, Active Directory, or a workgroup-style identity store. One character can swap the entire authentication path.

Show me the nerdy details

SMB authentication often funnels into either Kerberos (domain context, SPNs, tickets) or NTLM (challenge-response). Your username format helps the client/server pick which identity provider to query and how to package the logon attempt. When you “add a domain,” you can accidentally force the server to validate against a domain controller it can’t reach or a domain name it doesn’t recognize, producing the same user-facing failure even when the password is correct.

First triage pass: confirm you’re testing the right SMB surface

Target identity check: DC vs member server vs NAS

Same credentials, different outcomes, and it’s not personal. A domain controller, a member server, and a NAS appliance can all speak SMB while validating identities differently. Some NAS boxes fake a “domain” label that behaves more like a workgroup. Some member servers can’t reach the DC due to segmentation (or the DC is in a different site), so they reject domain logons even though the password is correct.

Quick mental model:

• DC: expects AD-centric identity; tends to be strict and noisy in logs
• Member server: can validate via AD but may have local SAM accounts too
• NAS/workgroup: may not behave like AD at all, even if it claims it does

I once spent 40 minutes “fixing credentials” on what I thought was a file server. It was a load balancer VIP pointing at a storage cluster node with its own local users. The password was fine. My assumptions weren’t.

SMB version/signing reality check (before you change anything)

Modern Windows environments increasingly harden SMB and NTLM. Microsoft’s SMB security hardening guidance describes options to block NTLM authentication for outbound SMB connections and other protections that can change what “used to work.” When SMB signing or NTLM policies are tightened, tooling can collapse multiple distinct failures into “logon failure” symptoms. The fix might be “use the right auth path,” not “try the password louder.” If you suspect your enumeration is being distorted by version/dialect visibility, compare with why smbclient can’t show a Samba version so you don’t over-trust a single banner.

Micro-check: “Are you sure you’re not talking to the wrong box?”

• Is this IP a VIP, NAT, or load balancer address?
• Does DNS resolve to the same host you think you’re hitting?
• Are there multiple interfaces and you’re arriving via a management subnet?

Practical tip: if you have authorization, pair your SMB test with a lightweight host identity check (banner, hostname, or SMB server name) so you’re not authenticating into a mirage.

Username format matrix: the 6 variants that solve most failures

This is the heart of the fix. When you see NT_STATUS_LOGON_FAILURE, run a format ladder like a grown-up: same host, same password, one formatting change per attempt. Don’t improvise. Improv is for jazz, not authentication.

Try 1: DOMAIN\username

When it works best: classic AD logon using a NetBIOS domain (often short, uppercase in documentation, but case-insensitive in practice). If the environment is “traditional Windows domain,” this is the first format many operators reach for.

Try 2: username@domain.tld

When UPN is required or more reliable: UPN format can be the cleanest route in multi-domain forests, renamed domains, or environments where the NetBIOS name is obscure. If you’ve ever muttered “what even is the NetBIOS name,” try UPN sooner.

Try 3: .\username (local account)

When the host expects local SAM authentication: This explicitly tells Windows, “validate me locally.” It’s useful on member servers with local break-glass accounts, lab boxes, or appliances presenting SMB via Windows services.

Try 4: plain username with domain omitted

When SMB defaults to a local context or cached auth: Some servers interpret a bare username in a local-first way, especially outside strict AD patterns. It’s also a useful setup for the blank-domain test you’ll run next.

Try 5: NetBIOS domain vs DNS domain (they’re not synonyms)

These are the classics that waste afternoons:

• ACME\jane (NetBIOS domain)
• acme.local\jane (often wrong; looks plausible, isn’t a SAM-style domain)
• jane@acme.com (UPN; might be correct even if the DNS domain differs)

In many orgs, the DNS domain, email domain, and NetBIOS domain are related but not identical. Your job is not to guess beautifully. Your job is to test systematically.

Try 6: machine-local quirks (NAS appliances, workgroups)

Workgroup-mode patterns can look like “domain failures” because there is no domain controller to consult. Some devices accept WORKGROUP\user, some accept just user, and some want their own “local realm” label. When you’re dealing with a NAS, assume it might be doing its own thing until proven otherwise.

Domain blank test: explicit empty domain versus client defaults

The blank-domain test is the simplest “tell” for local-vs-domain expectations, and it’s criminally underused. It’s not a trick. It’s controlled science: remove domain context and see what changes.

What “blank domain” changes under the hood

For SMBMap, specify username and domain separately: -u USER -d NETBIOSDOMAIN. Omitting -d selects the installed version’s default; current upstream uses WORKGROUP, so omission is not a blank-domain test. Use -d '' for an explicitly empty domain when an approved test budget permits it. Neither result alone proves whether validation was local or domain-based.

Practical test sequence: keep everything constant except domain

Run two attempts that are identical except for domain context:

• Attempt A: with domain explicitly set (for example, -d ACME)
• Attempt B: explicitly empty domain (-d ''); record the installed version’s default separately.

If Attempt B succeeds or produces a meaningfully different response, you just learned something valuable: domain context is steering validation, and you can now narrow your investigation instead of thrashing.

Curiosity gap: the surprising case where removing info fixes auth

This happens more than people admit. Adding a domain can be “more correct” on paper while being wrong in practice: it can push the server down a path it cannot complete (wrong domain name, unreachable DC, restricted NTLM policy), resulting in failure even with correct credentials.

Show me the nerdy details

In hardened environments, outbound NTLM for SMB can be blocked or limited, and signing requirements can affect negotiated behavior. Tooling may report a generic authentication failure even when the underlying reason is “this auth method is not permitted for this connection.” That’s why you isolate variables: format and domain context first, then policy-level factors (NTLM blocking, signing requirements, logon rights).

smbmap command patterns: minimal, controlled, non-chaotic tests

Your goal is to learn quickly without being noisy. That means: shares-only first, no recursion, no “let’s crawl the whole filesystem and see what happens.” The best pentest operators I know move like surgeons, not leaf blowers.

Baseline read-only probe (avoid noisy recursion)

Start with the least intrusive operation allowed by scope. Share enumeration demonstrates an SMB response, but it can succeed as Guest or Anonymous and does not establish that the supplied credentials were accepted. Verify session identity or server audit evidence before calling authentication successful.

One change at a time: the “single-variable” rule

If you change the username format and the domain and the target host and a flag, you didn’t run a test. You performed a magic trick on yourself.

Keep a tiny “variable freeze” checklist:

• Same host (same IP/DNS)
• Same password (exact same quoting)
• Same smbmap options (except the one you’re testing)
• Same time window (avoid crossing policy changes / lockout resets)

Pattern interrupt: Let’s be honest… you’re probably changing three things at once

I’ve done it too: you edit the domain, swap the username, add a flag you saw in a blog post, and then you stare at a new error like it’s a tarot card. The fix is boring and powerful: treat each attempt like a lab run. Label it. Log it. Move on. If you want a guardrail for “stop tweaking, start proving,” borrow the OSCP rabbit hole rule and apply it to SMB triage.

The lockout landmine: don’t turn triage into an incident

There are two ways to lose trust on a professional engagement: exfiltrate something you shouldn’t, or lock out half the sales team at 9:07 AM. The second one is surprisingly easy. (If your engagement docs don’t explicitly cover lockout risk and operational guardrails, fix that upstream with a pentest limitation of liability section that matches reality.)

Know the lockout policy before you brute-force formats

Account lockout thresholds and existing failed-attempt counts vary. If the policy, current account state, or approved remaining budget is unknown, pause authentication retries and confirm them with the owner. There is no universally safe allowance of three or five failures.

Safe cadence: spacing attempts and stopping early

A simple playbook that keeps you alive:

• Run additional authentication attempts only within an owner-approved budget that accounts for existing failures and automatic retries.
• Space attempts (don’t rapid-fire)
• Pause if you see any sign of throttling, delays, or weirdness
• Do not “spray” the same account across many hosts quickly

Why retry budgets must include existing failures

Counter resets, replication timing, and multi-host testing can stack failures in unexpected ways. You think you did “just one more test,” but the domain thinks you did four, and the helpdesk thinks you did it on purpose.

Show me the nerdy details

Lockout counting can be affected by where authentication is validated (local vs domain), how many systems receive attempts, and how quickly failures replicate. Even when you test “one host at a time,” the account might be validated by a domain controller that aggregates failures across multiple sources, especially if you’re also doing other authentication checks in parallel (SMB + WinRM + RDP). Treat the account as a shared global resource, not a local toy.

Common mistakes that cause false “LOGON_FAILURE” (and how to dodge them)

Mistake: Wrong domain flavor (NetBIOS vs DNS vs UPN)

This is the number-one “I swear the creds are right” trap. A domain can have a NetBIOS name (ACME), a DNS name (acme.local), and an email/UPN suffix (acme.com) that do not align the way your intuition wants them to. Dodge it by testing both DOMAIN\user and user@domain in a controlled ladder.

Mistake: Hitting a host that can’t validate the identity source

A member server that can’t reach a domain controller might reject AD logons. A segmented network can produce “auth failures” that are really “validation failures.” If the same creds work on one server but not another, don’t immediately assume password issues. Assume host role + reachability + policy.

Mistake: Special characters + shell escaping (your password got mangled)

If your password contains characters like !, $, quotes, or backslashes, your shell might interpret them. Your “correct password” may not be the password your tool actually sent. The fix is unglamorous: quote properly, escape where needed, and verify the exact string you’re passing. If you’re building a repeatable lab workflow, standardize this in your notes using Kali Linux lab logging so “my shell ate my password” doesn’t become a recurring villain.

Mistake: Assuming SMB creds equal WinRM/RDP creds

Windows logon rights differ by service. A user can be allowed to log on interactively (RDP) but denied network logon (SMB), or vice versa. That’s why “the password works in RDP” doesn’t automatically exonerate your SMB test.

Pattern interrupt: Here’s what no one tells you… “correct password” can still be denied

Two classic policy reasons:

• “Deny access to this computer from the network” can block SMB even with correct credentials
• Share-level ACLs can produce confusing access outcomes after authentication succeeds

When the format tests fail: the next three checks that save hours

If you’ve run your format ladder (including blank domain) and everything still fails, don’t despair. This is where disciplined operators stop guessing and start narrowing.

Check 1: Is the account allowed for network logon?

Look for restrictions like:

• “Log on to” limits (allowed workstations only)
• Time-of-day restrictions
• Group policy that denies network logon to specific groups

These can produce “logon failure” symptoms even when credentials are valid. For a pentest, the action is usually: document the behavior, confirm with stakeholders, and avoid repeated attempts that look like brute force.

Check 2: SMB signing/NTLM restrictions

In modern Windows, SMB hardening can influence whether NTLM is permitted for certain SMB connections. Microsoft documentation describes SMB client protections that can prevent NTLM authentication for outbound connections, which can show up as authentication failure from your tool’s perspective. If you suspect policy hardening, the fix is often “use the approved auth path” (Kerberos where possible, correct realm context, correct hostnames), not “try 20 variants.”

Check 3: Are you seeing a different error masked as logon failure?

Tools don’t always preserve nuance. A blocked auth method, an unreachable validation source, or a policy-based denial can collapse into a generic failure. If you have defender collaboration, correlate with logs (Security event IDs, SMB server logs) rather than asking the network the same question 30 times. If you’re building a broader signal-quality habit, the mindset from reducing Nmap service detection false positives applies: don’t confuse tool output with ground truth.

Show me the nerdy details

Some environments implement protections against NTLM relay and credential misuse that change server behavior. Depending on client/server versions and policy, you might see “access denied” or “logon failure” where older systems would have allowed a weaker auth negotiation. If your engagement permits, validate with a known-good Windows client in the same segment using the same identity context; differences often reveal policy gating rather than credential errors.

Short Story: I once watched a junior tester “prove” a password was wrong because smbmap kept returning NT_STATUS_LOGON_FAILURE. They tried fifteen variations in five minutes, on three servers, during business hours. The account locked. The client’s CFO couldn’t access a share needed for payroll. Suddenly the most important incident was not the pentest finding, but the tester’s timeline. We went back, slowed down, and ran a single-variable ladder on one host.

The magic fix was embarrassingly small: the user was a local break-glass account, and the server wanted .\username with no domain at all. The password was correct the entire time. What failed was our respect for systems that count. The report still shipped. The relationship needed longer to recover. (If you want a clean post-mortem structure for moments like this, keep a copy of how to read a penetration test report handy so the “what happened” and “what it means” don’t blur.)

Evidence-driven triage notes: what to record for a clean write-up

If you want defenders to trust your conclusion, don’t hand them vibes. Hand them a reproducible record. Your notes should make it obvious you tested carefully and minimized impact. (And if you’re training juniors, it’s worth standardizing these notes right next to your Kali pentest report template so “evidence first” becomes muscle memory.)

Capture the exact tuple: host + user format + domain context + time

• Host: IP/DNS, plus what you believe it is (DC/member/NAS)
• User format: exact string (e.g., .\jane vs ACME\jane)
• Domain context: explicit domain, blank domain, or omitted
• Timestamp: include timezone if relevant

Keep a “format ladder” log so you don’t retest the same thing

Make a four-row table in your notes and fill it like a pilot checklist. It prevents accidental duplication and keeps you from “trying the same thing again, but angrier.” If you want a ready-made place to store these tiny tables, slot them into your Obsidian OSCP enumeration template.

Attempt #	User format	Domain context	Result	Time
1	.\user	no -d	(log)	(time)
2	user	no -d	(log)	(time)
3	DOMAIN\user	-d DOMAIN	(log)	(time)
4	user@domain.tld	(UPN)	(log)	(time)

Curiosity gap: the one datapoint that makes defenders trust your report

Write down your lockout awareness and impact minimization:

• “Paused authentication retries because the lockout policy or remaining budget was unknown.”
• “Shares-only probes; no recursion or brute forcing.”
• “Single host for format ladder; no spraying across fleet.”

This is the difference between “professional test” and “someone ran a tool.” If you need a defensible way to package that story for stakeholders, align it with penetration test report reading so your findings land as decisions, not drama.

Next step (one concrete action)

Run a controlled “format ladder” on one host (shares-only), stopping before lockout risk

Do this on one host first. Keep it boring. Keep it defensible.

• Test selection: choose the owner-confirmed local machine or NetBIOS domain context; compare an explicit empty domain only if needed and approved. SMBMap separates -u and -d; do not assume Windows-style combined username notation is parsed.
• Stop rule: pause retries until policy and remaining budget are confirmed.
• Record: host + format + domain context + timestamp for each attempt

FAQ

Why does smbmap say NT_STATUS_LOGON_FAILURE even when the password is correct?

Because “correct password” is only one part of the equation. The host may be rejecting the identity context (domain vs local), denying network logon rights, or refusing an auth method (for example, environments hardened against certain NTLM behaviors). Tool output can flatten multiple causes into a single failure message.

What username format should I try first for an AD environment: DOMAIN\user or user@domain?

For SMBMap, use the account’s confirmed context with separate -u USER -d NETBIOSDOMAIN arguments. Windows DOMAIN\user and UPN notation describe identities, but client parsing is tool-specific. Do not assume passing either combined string to -u selects the intended domain.

How do I test a blank domain in smbmap without breaking the command?

After checking the installed SMBMap help and an approved authentication budget, compare the known domain using -u USER -d NETBIOSDOMAIN with an explicitly empty domain using -d ''. Omitting -d uses a default (currently WORKGROUP upstream), not an empty domain. Keep all other inputs constant.

What’s the difference between NetBIOS domain and DNS domain for SMB authentication?

NetBIOS domain names are often short (like ACME) and commonly used in the DOMAIN\user format. DNS domains look like acme.local and may not map cleanly to SAM-style domain strings. UPN suffixes (email-style) can be different again. That’s why “it looks right” can still be wrong.

Can a local account authenticate over SMB using .\username?

A local account may authenticate if the host permits network logon, but .\username is Windows notation and is not a universal SMBMap selector. Use the installed client’s documented local context and an owner-confirmed machine/domain value; verify the accepted identity.

Does SMB share access require different permissions than local logon or RDP?

Often, yes. SMB access can be governed by network logon rights, share permissions, and NTFS permissions, while RDP is governed by interactive logon rights and Remote Desktop Users group membership. A credential that works in one context can be denied in another without contradicting itself.

How many failed attempts risk account lockout in typical US enterprise settings?

There is no universal safe number of failures. If lockout policy, existing failed-attempt count, or the authorized remaining budget is unknown, pause retries and confirm these with the owner before another attempt.

Conclusion

Let’s close the loop from the hook: when smbmap throws NT_STATUS_LOGON_FAILURE, it’s rarely a dramatic network mystery. It’s usually a quiet identity mismatch, made louder by haste. The fix is not more attempts. The fix is better attempts: a format ladder, a blank-domain diagnostic, and lockout-safe pacing that keeps the business running while you learn.

Here’s a compact “what you did” infographic you can drop into your report (or your brain) as a final sanity check. If you want your write-up to read like an investigation instead of a tool dump, align this flow with a report structure defenders can verify.

Your next action: identify the installed SMBMap version/default domain, confirm the account’s intended local or domain context and approved retry budget, then run only the necessary shares-only check. Preserve status and accepted identity evidence separately.

Original review: 2026-02-24.

Technical guidance updated: 2026-10-13. Corrected SMBMap’s explicit blank-domain test, tool-specific username handling, authentication evidence, and lockout retry guidance.