In a non-domain environment with Windows Server 2008 R2, I've discovered an unexpected behavior in how SMB shares handle authentication when the "Password protected sharing" setting is in its default state versus when manually modified. Here's what every sysadmin should know.

The system exhibits three distinct behaviors based on the share configuration:

// Scenario 1: Password protected sharing ON (modified)
// Attempting \\SERVERNAME\ShareName results in:
// "Logon failure: the user has not been granted the requested logon type"

// Scenario 2: Password protected sharing OFF
// Anonymous shares work, restricted shares show:
// "You do not have permission to access \\SERVERNAME\ShareName"

// Scenario 3: Default state (never modified)
// After 30-second delay, shows authentication dialog

Through registry analysis, I found these critical differences:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"ForceGuest"=dword:00000000  // Default state differs from UI setting
"RestrictAnonymous"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"RestrictNullSessAccess"=dword:00000001

The default state actually configures multiple security policies that aren't all reset when toggling the UI setting.

1. Fresh install Windows Server 2008 R2
2. Create test share with permissions:

   net share TestShare=C:\Temp /GRANT:Everyone,READ

3. Attempt connection from client without local credentials
4. Observe authentication prompt
5. Toggle "Password protected sharing" in Advanced Sharing Settings
6. Retest to see behavior change

Using Process Monitor, we can trace what changes when modifying the setting:

1. RegSetValue HKLM\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest
2. Modifies HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\RestrictNullSessAccess
3. Updates SECURITY policy database entries

The default state actually sets a special combination of:

• Network access: Let Everyone permissions apply to anonymous users (disabled when toggled)
• Network security: Restrict NTLM authentication policies

To maintain consistent behavior while allowing anonymous access:

# PowerShell script to enforce desired state
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "ForceGuest" -Value 0
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name "RestrictNullSessAccess" -Value 0
secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose

After applying these changes, reboot the server for consistent authentication behavior regardless of the UI setting state.

When coding applications that interact with SMB shares:

// C# example showing proper credential handling
NetworkCredential credentials = new NetworkCredential("", "", "");
// Empty strings prompt for credentials on default-configured servers

try {
    using (new NetworkConnection(@"\\server\share", credentials)) {
        // File operations here
    }
} catch (UnauthorizedAccessException ex) {
    // Handle different auth failure modes
}

Understanding these nuances helps build more resilient file operations in mixed environments.

---

During recent Windows Server 2008 R2 file share troubleshooting in a workgroup environment (non-domain joined), I uncovered a peculiar authentication pattern that defies Microsoft's documented behavior for the "Password protected sharing" setting. Here's what's happening:

// Expected behavior matrix
+---------------------------+-------------------------------+-------------------------------+
|                           | Password Protected: ON        | Password Protected: OFF        |
+---------------------------+-------------------------------+-------------------------------+
| Matching Local Credentials| Success                       | Success                        |
| No Local Credentials      | "Logon failure" after 30s     | Anonymous access or permission |
|                           |                               | error (if share restricted)    |
+---------------------------+-------------------------------+-------------------------------+

The surprise comes when examining the default unchanged state of a fresh Windows Server 2008 R2 installation. When "Password protected sharing" appears enabled in GUI but hasn't been manually toggled:

• Connection attempts show authentication dialog after 30s delay
• Behavior differs from both toggled ON/OFF states
• Persists until first GUI setting change

Using procmon during setting changes reveals these critical registry modifications:

// Registry changes when toggling the setting
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
   ForceGuest (REG_DWORD) 
     0 = Password protected ON
     1 = Password protected OFF

// Hidden secondary change (explains the anomaly)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
   RestrictNullSessAccess (REG_DWORD)
     1 = Default state (shows prompt)
     0 = Modified state (immediate rejection)

To validate this behavior:

1. Fresh install Windows Server 2008 R2 (no updates)
2. Create test share: net share TestShare=C:\Test /GRANT:Everyone,READ
3. From client: net use \\Server\TestShare /user:"" ""

For consistent behavior across servers, use this PowerShell script to enforce proper registry states:

# Set both registry keys for proper password protected sharing
Function Set-SmbAuthBehavior {
    param (
        [bool]$PasswordProtected
    )
    
    $lsaPath = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
    $lanmanPath = "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"
    
    Set-ItemProperty -Path $lsaPath -Name "ForceGuest" -Value ([int](!$PasswordProtected))
    Set-ItemProperty -Path $lanmanPath -Name "RestrictNullSessAccess" -Value ([int]$PasswordProtected)
    
    # Restart required services
    Restart-Service -Name "LanmanServer" -Force
    Restart-Service -Name "Netlogon" -Force
}

# Usage examples:
# Set-SmbAuthBehavior -PasswordProtected $true  # For strict auth
# Set-SmbAuthBehavior -PasswordProtected $false # For anonymous access

This behavior impacts:

• Automated deployment scripts expecting consistent auth behavior
• CI/CD pipelines accessing build artifacts
• Cross-platform applications using SMB protocol

For Python developers working with SMB, consider adding explicit auth handling:

import smbclient

# Explicit auth configuration
smbclient.register_session(
    server="yourserver",
    username="",  # Empty for anonymous
    password="",
    require_secure_negotiate=False  # For legacy servers
)

try:
    with smbclient.open_file(r"\\server\share\file.txt") as f:
        print(f.read())
except smbclient.exceptions.SMBException as e:
    print(f"SMB Error: {e}")

When troubleshooting SMB auth issues:

1. Verify both registry keys (ForceGuest and RestrictNullSessAccess)
2. Check server firewall rules (netsh advfirewall firewall show rule name=all)
3. Test with fresh client connection (net use * /d /y clears cached creds)