SMB and the workstation/server services

The classic Windows architecture diagram groups a small set of components as integral subsystems, distinct from the Win32/POSIX/OS2 "environment subsystems" above them: the Workstation service, the Server service, and Security. Security has its own entire level in this course. This chapter is the other two — the machinery behind every \\server\share path, every mapped network drive, and a large share of lateral movement in any real Windows network.

Why a remote file looks exactly like a local one

Opening a file on a mapped network drive, from an application's point of view, looks identical to opening a local one — same CreateFile call, same NtCreateFile path into the kernel, described back in Ntdll & the user/kernel boundary. That's not an accident or a coincidence of API design — it's the direct result of a specific piece of kernel-mode infrastructure making it true.

The client side: MUP and the redirector

When an application opens a path starting with \\, the request reaches the MUP (Multiple UNC Provider) — a component whose entire job is figuring out which registered redirector should actually handle a given UNC path. For SMB shares, that's the SMB redirector (historically implemented across drivers in the mrxsmb family), which then:

1. Establishes (or reuses) a session to the remote server, including authentication — using the caller's own access token, the same identity every other access check in this course is built around.
2. Translates the application's file operation (read, write, query metadata) into SMB protocol messages sent over the network.
3. Returns the result through the exact same I/O completion path any local file operation would use, via the I/O Manager.

The user-mode Workstation service (LanmanWorkstation, running as an ordinary Windows service — see Services & background infrastructure) configures and coordinates this redirector; it isn't on the data path for every single read and write, which stays in kernel mode for performance.

The server side: sharing your own files out

The other direction — making a local folder available as \\this-machine\share to other computers — runs through the Server service (LanmanServer) and its kernel-mode driver (srv2.sys in modern Windows). When a remote client's SMB request arrives, the server driver:

1. Authenticates the incoming request against the local security database or domain, producing an access token the same way any interactive logon would (covered in LSASS, SAM, and local security policy).
2. Runs the exact same kind of access check against the target file's security descriptor that a local user would go through — remote access through SMB is not a separate, weaker security model; it's the same one, with the token sourced over the network instead of from an interactive logon.
3. Performs the actual file operation against the local file system through the I/O Manager, and returns the result as an SMB response.

Why this is one connected system, not "a protocol bolted on"

The architecturally important point this chapter is really making: SMB isn't a separate subsystem sitting off to the side of "real" Windows internals — it's wired directly into the same I/O Manager path, the same security model, and the same service infrastructure every other chapter in this course describes. A remote file share behaves like local storage, fails like local storage (the same kind of access-denied errors, for the same reasons), and shows up in the same diagnostic tools, precisely because it's built out of the same components, not a parallel, separate stack.

SMB itself: a protocol that's changed a great deal

The wire protocol has evolved substantially — modern Windows defaults to SMB2/SMB3, not the much older SMB1 (which is disabled by default on current Windows specifically because of well-documented security weaknesses exploited by real-world malware). SMB3 added end-to-end encryption and multichannel — using multiple network connections simultaneously for a single session, for both resilience and throughput — neither of which existed in the protocol's earlier versions.

A worked example: why "access denied" on a share isn't always what it seems

A user with apparently correct permissions being denied access to a network share can have several distinct causes, mirroring the full chain above: the redirector failing to establish a session at all (a network or authentication problem, before any file-level check happens), the Server service's own share-level permissions (configured separately from, and in addition to, the underlying file system's own ACL), or an ordinary access check failure at the file system level itself, identical to what would happen accessing the same file locally. Diagnosing this correctly means figuring out which of these three genuinely different layers actually produced the denial.

A common mistake

Treating SMB troubleshooting as a specialized, separate skill from "ordinary" Windows internals skips past how much of it is just the rest of this course, applied over a network. An access-denied error on a share is still fundamentally a Security Reference Monitor decision; a slow file copy over SMB still involves the Cache Manager and the same paging machinery as local I/O. The network transport is genuinely new; almost everything past that transport is the same machinery this entire course has already covered.

Where this connects

• The I/O Manager is the path every SMB file operation, client or server side, is routed through underneath.
• Access tokens and Access checks & the Security Reference Monitor are exactly what authorizes (or denies) a remote request, the same way they would a local one.
• The TCP/IP stack is what SMB's protocol messages actually travel over.