Tracing a File Share That Fails From Only One Server

September 2, 2026 · InfraScout Team

A domain-based DFS namespace opens fine from one domain controller. From the other, the namespace root fails, yet every link below it opens without complaint. There's no obvious error to search for, and "works here, fails there" is the kind of symptom that can eat an afternoon.

This post walks through how you hand that symptom to InfraScout and come out, a short session later, with an explanation backed by traces, event logs, directory data, and the DFS referral cache. The scenario is a composite of a pattern we see regularly. The punchline is that nothing is broken: security hardening is doing its job.

The question you ask

Describe the symptom, name the working host as well as the failing one, and say how much the AI may change.

From one of our domain controllers, the root of our domain-based DFS namespace
fails to open. From the other domain controller it works, and the links under
the root work from both. Trace both servers while I reproduce the problem and
tell me why. Stay read-only, and ask me before you start any capture.

The AI lists your agents, confirms that both domain controllers advertise the ETW tracing capability, and reads their stored host baselines. Then it posts a short plan and asks you two questions before touching anything: are you ready to reproduce right after the capture starts, and should it trace both hosts, using the working one as a reference? Starting a capture changes state on the host, even if harmlessly, so it waits for your yes.

Paired traces with curated profiles

The AI opens one session per host and, on each, starts two Data Collection Sets in parallel. The SMB client access profile covers signing, dialect negotiation, and access-denied detail. The authentication troubleshooting profile covers the logon path across Kerberos, NTLM, Netlogon, Schannel, and certificate validation. Both are curated provider bundles with a hard five-minute cap, so you don't pick providers by hand and nothing keeps recording if the conversation stalls.

Tracing the working host is what makes the comparison possible. A single trace from the failing server shows you errors. Two traces show you which errors matter.

A coordinated reproduction

The AI tells you exactly what to open, in which order, on both hosts: the namespace root, then a link, on the failing server first and then on the working one. It asks you to note rough times so it can line the events up later. You reproduce and say you're done. That's your whole hands-on part.

Reading past the noise

The first, unfiltered read of the traces is mostly noise: certificate chain validation, telemetry TLS connections, token broker chatter. A domain controller is busy even when nobody is using it. The AI re-reads both traces filtered to warnings and errors, and two signals stand out on the failing host: a repeating SMB session-setup error, and an NTLM logon failure with the status "account restriction."

That status is a strong hint. An account restriction on an NTLM logon usually means the account isn't allowed to use NTLM at all.

Correlating the evidence

With a lead in hand, the AI checks it from several independent sources, all read-only.

On the peer domain controller, the Security log shows failed-logon events 4625 for the admin account, using NTLM, with STATUS_ACCOUNT_RESTRICTION and the failing server as the source workstation. Elsewhere, the same account has successful Kerberos logons (4624). The account itself is fine. Only the NTLM attempts fail.

A read-only LDAP query shows the admin account is a member of Protected Users. Another shows that the service principal names on both domain controllers are complete for their fully qualified and short names, so a missing SPN on either server isn't the problem.

Read-only PowerShell fills in the rest. dfsutil /pktinfo shows the referral cache on the failing host holds entries for the links, but none for the bare namespace root. DNS resolution of the domain name returns both domain controllers' addresses, from both hosts.

Why the links behave differently

In a domain-based namespace, the client first asks a domain controller for a referral, then connects to the target it was given. Referrals are cached, and dfsutil /pktinfo dumps that cache. Links point to real server names, which have SPNs. The namespace root is reached through the bare domain name, which has no SPN of its own.

The question that cracked it

The evidence points at NTLM being blocked, and you ask the obvious question: Protected Users blocks NTLM everywhere, so why does the root still open from the other domain controller?

That question leads to the explanation that fits all the evidence. When you open the bare domain name, the client resolves it to one of the domain controllers. On the working server, the name most likely resolves to the server itself first, and a connection to yourself doesn't need network authentication. On the failing server, it most likely resolves to the peer. Kerberos needs an SPN for the exact name the client connects to, and the bare domain name has none. The client falls back to NTLM, Protected Users refuses it, and the peer logs the 4625 you already saw. Links work from both hosts because they resolve to server names with proper SPNs, so Kerberos succeeds.

The AI presents this as the most likely explanation, not as proven fact: the resolution order and the fallback aren't visible in any single trace, but no piece of the evidence contradicts it. It also drops an earlier hypothesis, that a short-name referral was at fault, because the referral cache and traces didn't support it.

It draws the flow for you in chat as a sequence diagram, with a chart of the filtered error events per host, and saves the pattern to memory so the next investigation starts from it.

The outcome and the workaround

The failure is explained, and the fix is to change how you connect, not to weaken the hardening. Open the namespace through its link paths or through server FQDN-based paths, or test with an account that isn't in Protected Users when you need to reach the bare root from a domain controller.

The AI stops all traces, submits both sessions for review, and raises no formal finding. This is Protected Users behaving as designed, and a finding would ask someone to "fix" a control that's working.

Other usual suspects

When a share works from one host but not another and authentication isn't the cause, check these first:

• A referral pointing to the wrong or an unreachable target.
• Site costing that sends one host to a distant or offline target.
• NTFS permissions that disagree with share permissions.
• A stale referral cache that still points at an old target.

Where you stay in control

The whole investigation took only a short session, most of it hands-off. Your part came down to one approval, one reproduction, and one clarifying question.

The captures were the only step that touched the hosts, and they used curated profiles with a capped duration, started only after you agreed. Everything else was read-only: event logs, LDAP, PowerShell, and the referral cache. The AI stopped every trace when it was done, treated all tool output as untrusted data, and handed both sessions to a reviewer.

Next steps

To run paired captures like these, start with Data Collection Sets for the available profiles, and check agent capabilities to confirm your hosts support tracing. The agent tools reference covers reading and stopping a capture, and Sessions explains how each investigation is recorded and reviewed.