How to Enable Anonymous SMB File Sharing Between Windows 7 and XP Without Authentication Prompts


4 views

When attempting to set up anonymous SMB file sharing between Windows 7 (as server) and legacy Windows XP clients without authentication prompts, we encounter fundamental protocol differences. Windows 7's default security policies prevent null sessions - the very mechanism XP clients rely on for automatic anonymous access.

Add these registry entries on the Windows 7 server (WIN7SVR):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"restrictanonymous"=dword:00000000
"restrictanonymoussam"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters]
"NullSessionShares"=hex(7):73,00,68,00,61,00,72,00,65,00,6e,00,61,00,6d,00,65,00,\
  00,00,00,00
"NullSessionPipes"=hex(7):73,00,72,00,76,00,73,00,76,00,63,00,00,00,00,00

Execute these commands in an elevated command prompt:

# Enable null session access
secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose

# Configure share permissions
net share sharename=C:\shared /GRANT:Everyone,READ

From XP clients, verify connectivity using these commands:

# Check null session capability
net use \\WIN7SVR\IPC$ "" /u:""

# Mount share persistently
net use X: \\WIN7SVR\sharename /PERSISTENT:YES

While convenient, this configuration reduces security. Consider these compensating controls:

  • Enable SMB signing via GPO
  • Restrict access via firewall rules
  • Monitor share access attempts

If XP clients still prompt for credentials:

# Reset security policies
gpupdate /force

# Verify share permissions
icacls C:\shared /grant Everyone:(R)

When configuring Windows 7 as a file server for mixed Windows 7/XP environments, we face authentication protocol mismatches. While Windows 7 clients handle Guest access seamlessly, XP machines still prompt for credentials due to:

  • Different SMB protocol implementations (SMB 2.x vs 1.0)
  • Stricter default security policies in Windows 7
  • XP's inability to properly negotiate anonymous sessions

First, enable null session support through registry edits on the Windows 7 server:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"RestrictAnonymous"=dword:00000000
"RestrictAnonymousSam"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters]
"NullSessionShares"=hex(7):73,00,68,00,61,00,72,00,65,00,6e,00,61,00,6d,00,65,\
00,00,00,00,00

For each shared folder:

  1. Right-click folder → Properties → Sharing → Advanced Sharing
  2. Set Share Permissions to:
    • Everyone: Read
    • ANONYMOUS LOGON: Read
  3. Set NTFS permissions to:
    • Everyone: Read & Execute
    • Guest: Read & Execute

Run gpedit.msc and configure:

Computer Configuration → Windows Settings → Security Settings → Local Policies:
1. Security Options:
   - "Network access: Let Everyone permissions apply to anonymous users" → Enabled
   - "Network access: Shares that can be accessed anonymously" → Add share names
   - "Network access: Restrict anonymous access to Named Pipes and Shares" → Disabled

2. User Rights Assignment:
   - "Access this computer from the network" → Add "ANONYMOUS LOGON"

From XP clients, test with:

net use \\WIN7SVR\sharename "" /user:Guest

Or via PowerShell (if available):

$cred = New-Object System.Management.Automation.PSCredential ("Guest", (new-object System.Security.SecureString))
New-PSDrive -Name X -PSProvider FileSystem -Root \\WIN7SVR\sharename -Credential $cred
Error Solution
0x80070035 Enable SMB1 on Windows 7: dism /online /enable-feature /featurename:smb1protocol
Access Denied Verify both share and NTFS permissions include Guest/Anonymous
Network Path Not Found Ensure Network Discovery is enabled on both machines

While convenient, anonymous access has risks. Consider implementing these compensating controls:

  • Restrict access via firewall rules to specific client IPs
  • Enable SMB signing: Set-SmbServerConfiguration -RequireSecuritySignature $true
  • Monitor access attempts with Windows Event Log auditing