SMB NULL Session Authentication: How to Disable Null Sessions and Guest Access on Windows and Samba

SMB NULL session authentication means a Windows or Samba host accepts an SMB connection with an empty username and password and lets it open named pipes or list accounts and shares. Fix it by enabling RestrictAnonymous, RestrictAnonymousSAM and RestrictNullSessAccess, emptying the anonymous pipe and share lists, disabling the Guest account, and setting restrict anonymous = 2 on Samba.

What the scanner is actually detecting

Two related conditions usually appear together. NULL session: the scanner connects with no username or password and still reaches something useful. Guest mapping: the scanner sends a random, nonexistent username and the server logs it on as Guest.

Per Tenable, 26920 succeeds when it can log into the browser or spoolss pipes with a NULL session, and 26919 fires when a random account is accepted as a guest or guest-like user. Both apply to Windows and Samba.

Real-world risk

A NULL session on its own does not give an attacker code execution. It gives reconnaissance: depending on configuration, an unauthenticated user can list account names, groups and shares, which Microsoft notes can feed password guessing and social engineering.

Guest mapping is usually more serious. Microsoft states that any share whose permissions allow Guest, the Guests group or Everyone becomes reachable over the network, so on a loosely permissioned file server a random username can read or modify data. Real severity depends on your share ACLs, not the finding title.

How to confirm it on the host

On the Windows host

Read the values that control anonymous access (run in an elevated PowerShell session):

Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlLsa' |
  Select-Object RestrictAnonymous, RestrictAnonymousSAM, EveryoneIncludesAnonymous, ForceGuest

Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters' |
  Select-Object RestrictNullSessAccess, NullSessionPipes, NullSessionShares

Get-LocalUser | Where-Object { $_.SID.Value -like '*-501' } | Select-Object Name, Enabled

The last command finds the Guest account by its well-known RID (501), even if renamed. Where Get-LocalUser is missing, use WMI (Get-CimInstance needs PowerShell 3.0 or later; on PowerShell 2.0 use Get-WmiObject):

# PowerShell 3.0 and later
Get-CimInstance Win32_UserAccount -Filter "LocalAccount=TRUE AND SID LIKE '%-501'" | Select-Object Name, Disabled

# PowerShell 2.0
Get-WmiObject Win32_UserAccount -Filter "LocalAccount=TRUE AND SID LIKE '%-501'" | Select-Object Name, Disabled

On domain controllers, look up the domain Guest account instead (needs the ActiveDirectory module):

Get-ADUser -Identity "$((Get-ADDomain).DomainSID)-501" -Properties Enabled | Select-Object Name, Enabled

From another machine

Reproduce the scanner’s checks from a Linux host with the Samba client tools:

# NULL session: empty username, no password
smbclient -L //192.0.2.10 -N
rpcclient -U "" -N 192.0.2.10 -c "srvinfo;enumdomusers"

# Guest mapping (what Nessus 26919 tests): a random, nonexistent account
smbclient -L //192.0.2.10 -U 'nosuchuser8231%RandomPass1'

If any of these return a share list, server information or user names, the finding is real on that host.

How to fix it

Windows: Group Policy (domain-joined hosts)

All of these live under Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options. On domain-joined machines, set them in a GPO rather than the registry, which Group Policy overwrites at the next refresh.

The anonymous pipe list only takes effect when “Restrict anonymous access to Named Pipes and Shares” is also enabled, so configure both. For the domain Guest account, set Accounts: Guest account status in a GPO linked at the domain root (for example Default Domain Policy), or use Disable-ADAccount as shown below; a GPO linked to the Domain Controllers OU will not apply it. If settings do not land, check GPO precedence and why a policy is not applying.

Windows: registry (standalone or workgroup hosts)

Save the Get-ItemProperty output first (the prior values you need for rollback), then export the keys as a fallback. Run this block in an elevated Command Prompt (cmd.exe), not PowerShell: Windows PowerShell 5.1 drops the empty “” argument before reg.exe sees it, breaking the multi-string lines.

if not exist C:Temp mkdir C:Temp
reg export "HKLMSYSTEMCurrentControlSetControlLsa" C:Templsa-before.reg /y
reg export "HKLMSYSTEMCurrentControlSetServicesLanmanServerParameters" C:Templanmanserver-before.reg /y

reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v RestrictAnonymous /t REG_DWORD /d 1 /f
reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v RestrictAnonymousSAM /t REG_DWORD /d 1 /f
reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v EveryoneIncludesAnonymous /t REG_DWORD /d 0 /f
reg add "HKLMSYSTEMCurrentControlSetControlLsa" /v ForceGuest /t REG_DWORD /d 0 /f
reg add "HKLMSYSTEMCurrentControlSetServicesLanmanServerParameters" /v RestrictNullSessAccess /t REG_DWORD /d 1 /f
reg add "HKLMSYSTEMCurrentControlSetServicesLanmanServerParameters" /v NullSessionPipes /t REG_MULTI_SZ /d "" /f
reg add "HKLMSYSTEMCurrentControlSetServicesLanmanServerParameters" /v NullSessionShares /t REG_MULTI_SZ /d "" /f

In PowerShell, the export and DWORD lines work unchanged; replace the two multi-string lines with:

$p = 'HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters'
New-ItemProperty -Path $p -Name NullSessionPipes -PropertyType MultiString -Value @() -Force
New-ItemProperty -Path $p -Name NullSessionShares -PropertyType MultiString -Value @() -Force

Guest access (Nessus 26919) on Windows

Set the sharing model to Classic first, then disable Guest. Microsoft warns that with Guest disabled and the model still on “Guest only”, SMB network logons that use local accounts fail (domain-account logons are not affected by this setting).

Get-LocalUser | Where-Object { $_.SID.Value -like '*-501' } | Disable-LocalUser

Without Get-LocalUser, run net user “<name from the WMI query>” /active:no. On a domain controller:

Disable-ADAccount -Identity "$((Get-ADDomain).DomainSID)-501"

Optionally, stop your own SMB clients falling back to guest against a misconfigured server (this does not clear the server finding). Microsoft lists Windows 10 or Windows Server 2019 and later as prerequisites:

Set-SmbClientConfiguration -EnableInsecureGuestLogons $false -Force

On older hosts, use the GPO Computer ConfigurationAdministrative TemplatesNetworkLanman WorkstationEnable insecure guest logons = Disabled (AllowInsecureGuestAuth) where it is available.

Domain controllers

Per Microsoft, the two “Do not allow anonymous enumeration” policies have no impact on domain controllers, and the Default Domain Controller Policy allows the netlogon, samr and lsarpc pipes anonymously. Do not blank that list without testing; Microsoft warns it can break trusts in older mixed environments. The lever that usually matters is the Pre-Windows 2000 Compatible Access group, which grants read access to all users and groups:

net localgroup "Pre-Windows 2000 Compatible Access"

If ANONYMOUS LOGON or Everyone is listed, plan their removal after checking for legacy dependencies, and document whatever anonymous pipes you keep as a formal exception.

Also set Network access: Allow anonymous SID/Name translation to Disabled in a GPO applied to your DCs; with lsarpc open, an enabled setting still lets RID cycling (rpcclient lookupsids) resolve account names. Microsoft’s reference is inconsistent about the DC default, so check each DC in its exported security policy, where LSAAnonymousNameLookup = 0 means Disabled. secedit writes the file as Unicode, which findstr cannot search, so use find (or Select-String in PowerShell) from an elevated Command Prompt:

if not exist C:Temp mkdir C:Temp
secedit /export /cfg C:Tempsecpol.inf /areas SECURITYPOLICY
find /i "LSAAnonymousNameLookup" C:Tempsecpol.inf

Samba, NAS and other non-Windows SMB servers

In the [global] section of smb.conf:

[global]
    restrict anonymous = 2
    map to guest = Never
    usershare allow guests = no

Then remove guest ok = yes (synonym: public = yes) from every share; per the Samba manual, a single guest share cancels the benefit of restrict anonymous = 2. Check and reload, keeping -v, since testparm otherwise omits default values such as map to guest = Never:

testparm -sv 2>/dev/null | grep -Ei 'restrict anonymous|map to guest|guest ok|public|usershare allow guests'
smbcontrol smbd reload-config

Some packaged templates ship with map to guest = bad user, which alone triggers 26919. For appliances you cannot configure, Tenable advises keeping the device unreachable from untrusted clients.

How to verify the fix and rescan

1. On domain members, run gpupdate /force, then gpresult /scope computer /h C:Tempgpresult.html /f (C:Temp must exist; /f overwrites an earlier report) and confirm the winning GPO for each Security Option.
2. Re-run the Get-ItemProperty checks and confirm the expected values.
3. Repeat the smbclient and rpcclient tests from another host. You may still see “Anonymous login successful”; what matters is that share listing, srvinfo and enumdomusers return NT_STATUS_ACCESS_DENIED rather than data, and that the random-user command fails with NT_STATUS_LOGON_FAILURE.
4. Rescan with the same scanner, policy and credentials, and confirm the plugin or QID no longer reports.

Microsoft lists no restart requirement for these policies. If the rescan still reports the finding while the registry is correct, compare the plugin output with the pipes and shares you kept.

What can break and how to roll back

• One-way trusts: administrators in a trusting domain can no longer enumerate accounts in the other domain.
• Anonymous share browsing: users must authenticate to list shares and printers.
• Legacy applications: anything using unauthenticated named pipes breaks once the pipe list is empty.
• Guest-only devices: old printers, scanners and NAS boxes that only support guest access lose their connection.

To roll back a registry change, restore each prior value you recorded with a targeted reg add, and remove values that did not exist before with reg delete, for example reg delete “HKLMSYSTEMCurrentControlSetServicesLanmanServerParameters” /v NullSessionShares /f. Use the exported files only as a last resort: reg import rewrites every value in the file, including unrelated Lsa settings hardened since the export, and never deletes values created after it. Re-enable Guest with Enable-LocalUser only if you must. Security Options values can remain (be tattooed) after a GPO stops applying, because they revert only if a previous value was recorded in the local security database, so set the previous value explicitly rather than just unlinking the GPO. On Samba, restore the previous smb.conf and reload.

Common false positive reasons

• Domain controllers by design. Default DC pipes and a populated Pre-Windows 2000 Compatible Access group often keep QID 70003 open on DCs after member servers are clean.
• Wrong device behind the IP. A NAS, printer or appliance with its own SMB stack, or a reassigned DHCP address, produces a finding no Windows GPO will clear.
• Intentional exceptions. A pipe or share you deliberately kept in NullSessionPipes or NullSessionShares keeps the finding open; document it as accepted risk.
• Settings reverted by policy. A local fix that a GPO overwrote looks like a false positive but is real.

For the wider baseline these settings belong to, see the Windows Server hardening checklist.

FAQ

Should I set RestrictAnonymous to 2 on Windows?

No. The Security Options policy can only set 0 or 1. Value 2 is a legacy Windows 2000 setting (KB 246261) that Microsoft warned could break down-level clients and trusts, especially on domain controllers. Rely on EveryoneIncludesAnonymous = 0 and RestrictNullSessAccess = 1 instead. On Samba, restrict anonymous = 2 is the correct value.

Why does the finding persist on my domain controllers?

The anonymous enumeration policies do not apply to DCs, and DCs allow some anonymous pipes by default. Review the Pre-Windows 2000 Compatible Access group and the anonymous SID/Name translation setting, then document the pipes you must keep.

Is this related to SMBv1?

No. NULL sessions and guest mapping are authentication issues and exist on SMB 2 and 3 as well. Protocol version and signing are covered in disabling SMBv1 and enforcing SMB signing.

Tracking this finding across many hosts

On a large estate this finding arrives from several scanners at once. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results come in as an uploaded .nessus export) and merges duplicates per scanner, so the same condition reported by two different scanners stays as two records. Its agents on Windows and Linux endpoints can deploy AI-written, host-specific remediation scripts after human approval, and for Nessus findings a per-finding retest confirms whether the host is actually closed.

Sources

• Tenable: SMB NULL Session Authentication (plugin 26920)
• Tenable: Unauthenticated SMB Access Permitted (plugin 26919)
• Microsoft Learn: Network access: Restrict anonymous access to Named Pipes and Shares
• Microsoft Learn: Network access: Named Pipes that can be accessed anonymously
• Microsoft Learn: Network access: Do not allow anonymous enumeration of SAM accounts and shares
• Microsoft Learn: Network access: Allow anonymous SID/Name translation
• Microsoft Learn: Security policy settings (merging on domain controllers, persistence)
• Microsoft Learn: Enable insecure guest logons in SMB2 and SMB3
• Samba: smb.conf(5) manual page
• Samba: testparm(1) manual page