Starting point: “it is only a NAS share” becomes a client-wide exception

Guest access often survives because the dependency looks small: a scanner writes to an old NAS or a production terminal reads a configuration file. The problem surfaces after a Windows upgrade or security-baseline change, when the share stops opening. The quick workaround is to allow insecure guest logons on the affected client.

That setting changes the SMB client's trust model. A guest session is unauthenticated: the client establishes no named identity the server can authorize. Guest logons support neither SMB signing nor SMB encryption. This is not low-privileged user access; it is access without dependable identity, integrity, or confidentiality.

The operational history is usually more complicated than the single reported share:

  • Windows editions and generations have different default behavior for outbound guest access.
  • Local registry changes, old security templates, MDM profiles, and domain GPOs can contradict one another.
  • The same mapping may use a named credential on one device and guest on another.
  • Servers, scheduled tasks, scanners, laboratory devices, and workstations may all reach the appliance.
  • A third-party SMB server may map invalid credentials to guest, making a credential error look like successful authentication.
  • Support teams may have disabled signing or encryption to restore access without recording the exception.

An operating-system default is not a control; policy must be explicit. Client policy alone does not remove the share or exposure to non-Windows systems. Client enforcement and server cleanup are connected workstreams.

Target state: authenticated shares and an explicit deny policy

A defensible target state has observable properties:

  1. Managed Windows clients explicitly reject guest access. The baseline configures Enable insecure guest logons = Disabled; Not configured is not evidence.
  2. Shares require named authentication. Users, services, and devices have least-privileged identities.
  3. Signing and encryption remain independent requirements. They are never weakened domain-wide for one appliance.
  4. Guest shares are removed server-side. Each NAS, Samba host, Windows server, and embedded system is checked in its own management plane.
  5. Dependencies have an owner and migration path. Server, share, consumer, data class, and process are recorded before enforcement.
  6. Exceptions are transitional and client-scoped. An isolated endpoint is limited to the exact destination, with owner, expiry, and replacement milestone.
  7. Failures are actionable. Support can distinguish guest rejection from DNS, authorization, dialect, signing, encryption, firewall, and credential faults.
  8. The steady state is measured. Allowed sessions disappear and exception scope trends toward zero.

For users, replace guest access with an AD account or group authorized on the share. For appliances and jobs, use a service identity per device or workload. Deny interactive logon where applicable, vault and rotate its secret, and restrict it to one share and the required operations. A site-wide “scanner” account preserves much of the accountability problem.

If the device cannot authenticate at all, place a controlled transition service between it and the protected file service. For example, an isolated ingestion host can receive files from a tightly restricted legacy segment and move them onward under its own named identity after validation. This is still technical debt, but it confines the weak protocol edge instead of changing every employee workstation.

Implementation: remove dependencies before enforcing the baseline

1) Inventory client configuration and active connections read-only

Start with representative clients from every operating-system version, device class, site, and management channel. Include member servers: scheduled jobs and applications often make them SMB clients even though administrators think only about workstations.

The following local PowerShell inventory changes nothing. It reports the explicit policy value, the current SMB client configuration, and connections visible at the moment of collection:

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

$policyPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation'
$policyValue = Get-ItemPropertyValue `
  -LiteralPath $policyPath `
  -Name 'AllowInsecureGuestAuth' `
  -ErrorAction SilentlyContinue

$policyState = if ($null -eq $policyValue) {
  'Not explicitly configured'
} elseif ($policyValue -eq 0) {
  'Disabled'
} elseif ($policyValue -eq 1) {
  'Enabled'
} else {
  "Unexpected value: $policyValue"
}

$client = Get-SmbClientConfiguration

[pscustomobject]@{
  ComputerName                  = $env:COMPUTERNAME
  GuestLogonPolicy              = $policyState
  EffectiveGuestLogonsEnabled   = $client.EnableInsecureGuestLogons
  ClientRequiresSigning         = $client.RequireSecuritySignature
  ClientSigningEnabled          = $client.EnableSecuritySignature
}

Get-SmbConnection | Select-Object `
  ServerName,
  ShareName,
  UserName,
  Dialect,
  Signed,
  Encrypted,
  NumOpens

Collect structured results through the existing endpoint-management platform; do not deploy a new privileged scanner for this inventory. A missing policy value means only that policy is not explicit. Get-SmbConnection is a point-in-time view and misses disconnected mappings, sleeping devices, infrequent jobs, and short sessions. Correlate it with GPO and MDM reports, mappings, scripts, scheduled tasks, appliance inventories, TCP 445 telemetry, support history, and owner interviews. Inventory weakened signing or encryption settings separately; both issues require remediation.

2) Classify each dependency by owner, data, and replacement path

Create one record per real workflow, not merely per IP address. At minimum, capture:

  • initiating clients or service tiers and the SMB server, address, share, and dialect,
  • required file operations, data classification, and retention,
  • business owner, technical owner, support group, and usage pattern,
  • current authentication, signing, encryption, firmware, and vendor status,
  • proposed identity, target share, migration test, and deadline,
  • exception scope, approver, expiry, and replacement milestone.

“Scans” or “software packages” are not harmless labels. A writeable guest share distributes untrusted content; an anonymously readable share exposes data to any device that reaches it. Assess network reachability plus share and filesystem behavior.

Separate three outcomes early. Supported servers should be reconfigured. Unsupported but replaceable devices should be upgraded or retired. Devices that cannot be changed before the enforcement date need an isolated transition design. This prevents a vague “legacy exception” from absorbing every difficult case.

3) Configure authenticated access on the server

Fix the resource before teaching clients to tolerate it. On a supported NAS, Samba host, appliance, or file server:

  1. Update supported firmware and verify that SMB1 is not required.
  2. Create named users or integrate with AD where the product supports it securely.
  3. Grant access through small groups or workload identities, not a departmental password.
  4. Remove guest, public, and “map unknown users to guest” behavior.
  5. Apply least-privileged share and filesystem permissions.
  6. Enable signing and, where required, encryption.
  7. Restrict TCP 445 to documented clients or service subnets.
  8. Update mappings, applications, scanner destinations, and runbooks.
  9. Test authorized and unauthorized identities before removing the old share.

For scan-to-folder, use a device-specific identity and dedicated drop location; the device should neither browse unrelated documents nor overwrite application content. A downstream process can validate and move files under another identity. For package distribution, prefer a managed repository or web delivery.

AD integration is not automatically best for an unmaintained appliance. A unique local account with a long random secret, restricted path, narrow permissions, and rotation may be safer until replacement. Record the tradeoff.

4) Enforce the client baseline centrally and pilot it

Create a dedicated domain GPO, for example SEC-SMB-Client-Block-Insecure-Guest, and configure:

Computer Configuration
  Policies
    Administrative Templates
      Network
        Lanman Workstation
          Enable insecure guest logons = Disabled

Use current central ADMX templates. Link the GPO to a pilot OU or dedicated computer group with verified security filtering. Preserve normal GPO read permissions, inspect inheritance, and capture Resultant Set of Policy evidence for each pilot class.

The value must be Disabled, not Not configured. Defaults have changed across Windows editions and releases, local configuration may persist, and an upgrade can otherwise alter observed behavior. Explicit policy makes the intended state reviewable and stable.

Verify the winning GPO and SMB client configuration. Test real user and service contexts; an administrator opening a share does not represent a scheduled task. Expand in rings from IT and business pilots to workstations, special devices, member servers, and the remaining estate. Rollback means a bounded, approved exception—not editing the domain baseline during an incident.

For an isolated non-domain system where central management genuinely is unavailable, the equivalent local implementation is:

Set-SmbClientConfiguration `
  -EnableInsecureGuestLogons $false `
  -Confirm:$false

This is a fallback for a documented standalone system or lab, not a substitute for domain GPO. Do not distribute a reverse command as a help-desk fix.

Keep SMB signing and encryption baselines intact during this rollout. Because guest sessions support neither feature, requiring signing or encryption may also block the legacy connection. That failure is evidence of an incompatible service, not justification to lower those controls across the domain.

5) Use audit signals without overinterpreting them

Dedicated insecure-guest auditing is available only on Windows 11 version 24H2 and Windows Server 2025. It is disabled by default and must be enabled explicitly on systems used for discovery; never enable guest solely to audit it. Older systems need application tests, configuration and server evidence, and network telemetry.

For client events such as 31022, configure Computer Configuration > Policies > Administrative Templates > Network > Lanman Workstation > Audit insecure guest logon = Enabled. Managed Windows file servers need the separate setting under Lanman Server > Audit insecure guest logon = Enabled to emit server-side event 3023. Client and server audit policies are distinct; enabling one does not configure the other.

Collect the SMB client Security log centrally and interpret the relevant events by meaning:

  • 31018 reports that an administrator enabled AllowInsecureGuestAuth. It identifies an exposed configuration state or change; it does not prove that a guest session occurred.
  • 31022 reports that the client allowed an unauthenticated guest logon requested by a server. This is evidence of actual allowed use and needs a server, share, owner, and migration record.
  • 31017 reports a rejected insecure guest attempt. It is a dependency lead, not proof of prior allowed use, resource legitimacy, or the complete failure cause.
  • 3023 is server-side in Microsoft-Windows-SmbServer/Security and reports that an SMB client logged on as Guest. It is useful on managed Windows file servers, but third-party NAS devices will not produce this Windows event and may use different terminology.

Event volume is not a device count: reconnect loops inflate it, while monthly tasks can escape a short window. Preserve client and server details and correlate them with DNS, ownership, schedules, and exceptions.

Monitor policy drift separately. A new 31018 should trigger review even when no 31022 follows. After enforcement, recurring 31017 events should create a service-owner action rather than an automatic weakening of the client.

6) Contain unavoidable transition exceptions

Some production devices cannot be upgraded within the first change window. The exception must attach to the smallest possible client boundary, never to a user group, site, subnet, or the Default Domain Policy.

Prefer a hardened transition VM with no email, web browsing, or administrative use. Restrict outbound TCP 445 to exact legacy addresses and inbound management to an administration tier. Segment it, keep EDR and patching active, store no privileged interactive credentials, and move data onward under a named identity.

If the transition client must allow insecure guest logons, use a separate, higher-precedence GPO scoped only to its computer account. Because guest cannot use signing or encryption, any required compatibility reduction must also remain confined to that isolated client and exact network path. Never disable SMB signing or encryption across the domain, an entire workstation OU, or a broad server tier.

Every exception needs:

  • business and technical owners; exact clients, servers, share, direction, and ports,
  • data classification, permitted operations, firewall, and segmentation evidence,
  • monitoring, incident owner, approval, fixed expiry, and review cadence,
  • funded replacement and a tested removal plan.

An exception that automatically renews, permits arbitrary SMB destinations, or follows a user onto normal workstations is an alternative baseline, not a transition.

7) Validate workflows and security controls together

The pilot acceptance test must include more than “the drive opens.” For each dependency, verify:

  1. Approved identities reach only the intended server and share; unapproved identities are denied.
  2. Sessions are signed and encrypted where required.
  3. File operations match the documented need.
  4. Jobs and services work without interactive credential caching, including after secret rotation.
  5. The guest share is disabled server-side and inaccessible from non-Windows test systems.
  6. A controlled lab dependency is rejected by a client with the deny GPO.
  7. Support can identify the service owner from the failure.
  8. No fallback remains through WebDAV, SMB1, duplicate shares, or alternate names.

Capture effective GPO, connection properties, server authorization, firewall decision, and application result. A privileged test can hide permission defects and cached credentials; testing only the new share misses old mappings.

8) Retire exceptions and prove the steady state

After migration, remove old mappings and paths, disable the guest share, revoke temporary firewall rules, remove exception GPO scope, and delete local guest-enabling configuration.

Track deny-policy coverage, servers with guest disabled, observed 31022/3023 events, and exception clients. Completion means full intended coverage and zero unexplained allowed sessions. Stale rejected attempts still need owners and closure dates.

Include guest-access checks in new-device onboarding, NAS procurement, server build standards, application acceptance, and recurring GPO compliance. Otherwise, the same dependency returns with the next scanner, laboratory appliance, or unmanaged storage device.

Benefits

  • Named accountability: Access can be attributed to a user, service, or device-specific identity instead of a shared anonymous context.
  • Preserved SMB integrity: Client-wide signing requirements no longer have to compete with an incompatible guest workflow.
  • Reduced data exposure: Network reachability alone is insufficient to read or write the share.
  • Smaller relay and tampering surface: Clients reject a server that attempts to place them in an unauthenticated guest session.
  • Visible technical debt: Temporary legacy paths have exact scope, cost, expiry, and replacement work instead of an undocumented workaround.

Drawbacks and limits

  • Legacy workflows can stop immediately: Scanners, NAS devices, production equipment, and old applications may have no authenticated mode.
  • Discovery is incomplete by nature: Point-in-time connection data and a short audit window miss infrequent jobs and offline equipment.
  • Server remediation can be expensive: Firmware updates, replacement hardware, licensing, application changes, and vendor validation may be required.
  • Signing and encryption compatibility remains separate: Replacing guest access does not guarantee that the server supports the organization's transport baseline.
  • The client policy cannot clean the server: Anonymous data exposure can remain available to unmanaged, Linux, or embedded clients.
  • Transition services retain residual risk: Segmentation contains an unauthenticated edge but does not make that edge trustworthy.

Typical pitfalls

  • Leaving the policy unconfigured: Current defaults are mistaken for an enforceable domain baseline.
  • Enabling guest access after the first support ticket: One inaccessible NAS produces a permanent client-wide exception.
  • Disabling signing or encryption broadly: A compatibility failure on one share weakens unrelated SMB sessions across the estate.
  • Changing only one side: Client-only hardening leaves the share exposed; server-only cleanup leaves clients willing to accept guest elsewhere.
  • Misreading events: 31018 is configuration, 31017 is not a complete root cause, and Windows server event 3023 is not expected from a NAS.
  • Assuming no events means no dependency: Older clients, short collection periods, stopped log forwarding, and monthly jobs leave gaps.
  • Replacing guest with one shared account: Authentication returns, but attribution and compromise boundaries remain poor.
  • Scoping exceptions broadly: User scope or unrestricted TCP 445 carries the weak posture to normal devices and other destinations.
  • Forgetting saved mappings and alternate names: Old paths reconnect later and create intermittent failures after rollout.
  • Keeping exceptions without expiry: A project workaround quietly becomes the permanent architecture.

Project checklist

  • [ ] Export effective policy and SMB client configuration for representative workstations, special devices, and member servers.
  • [ ] Identify registry, GPO, MDM, image, and script sources for AllowInsecureGuestAuth.
  • [ ] Inventory connections, mappings, jobs, services, applications, scanners, NAS systems, and embedded devices.
  • [ ] Record server, share, clients, owner, data class, operations, frequency, and business criticality per workflow.
  • [ ] Confirm supported SMB dialect, named authentication, signing, encryption, firmware, and vendor status for each server.
  • [ ] Classify each dependency as reconfigure, replace, or isolate temporarily.
  • [ ] Create least-privileged identities; vault and rotate service secrets and deny unnecessary interactive logon.
  • [ ] Remove guest, public, anonymous, and unknown-user-to-guest mappings server-side.
  • [ ] Restrict TCP 445 to documented source and destination systems.
  • [ ] Keep SMB signing and encryption baselines unchanged across the domain.
  • [ ] Create a dedicated GPO and explicitly configure Enable insecure guest logons = Disabled.
  • [ ] Pilot in a controlled computer scope; verify filtering, inheritance, winning GPO, and effective SMB state.
  • [ ] Enable the Lanman Workstation guest-audit policy on supported Windows 11 24H2 and Windows Server 2025 discovery clients.
  • [ ] Enable the separate Lanman Server guest-audit policy on supported managed Windows file servers.
  • [ ] Distinguish client events 31017, 31018, and 31022; collect server event 3023 where applicable.
  • [ ] Supplement events with application tests, telemetry, support history, and third-party server logs.
  • [ ] Create an owner and migration record for every 31022, 3023, or recurring 31017 finding.
  • [ ] Test named and denied access, signing/encryption, file operations, jobs, services, and secret rotation.
  • [ ] Use a dedicated transition service when the legacy endpoint cannot authenticate.
  • [ ] Scope exceptions to exact computers and destinations; document controls, owner, expiry, and replacement.
  • [ ] Never place an insecure-guest exception in the Default Domain Policy or a broad workstation/server OU.
  • [ ] Roll out in rings with service-owner communication and a predefined support path.
  • [ ] Remove old mappings, guest shares, temporary firewall rules, and exception GPO scope after migration.
  • [ ] Report deny-policy coverage, server cleanup, allowed guest events, and active exceptions.
  • [ ] Add authenticated SMB checks to procurement, onboarding, and recurring compliance reviews.