Azure Web App部署后访问本地共享文件夹触发System.UnauthorizedAccessException

Let's walk through why your Azure-hosted Web App is hitting this permission error, even though your impersonation code works locally and for VPN-connected non-domain machines. Here are the key areas to check and fix:

1. Verify Network Connectivity Between Azure Web App and On-Prem Network #

First, make sure your Azure Web App can actually reach the on-prem shared folder at \\192.168.74.10\Shared\LIS\For Upload\Reports:

• Confirm you've set up Azure VPN Gateway or ExpressRoute to bridge your Azure VNet and local network.
• Enable VNet Integration for your Web App, so its traffic routes through the connected VNet instead of public internet (Azure Web App sandbox blocks public SMB access by default).
• Test connectivity directly from the Web App's environment:
  1. Go to your Web App's Kudu console (via https://<your-app-name>.scm.azurewebsites.net)
  2. Open the PowerShell tab and run:

     Test-NetConnection 192.168.74.10 -Port 445
     

  If this fails, fix your network routing/firewall rules first (SMB uses port 445).

2. Fix Impersonation Limitations in Azure Web App Sandbox #

Your WrappedImpersonationContext uses LogonType.NewCredentials, which doesn't play well with the Azure Web App sandbox. The sandbox restricts certain Win32 API behaviors, and NewCredentials is designed for creating new credential sets rather than accessing network resources:

• Modify the Enter() method to use LogonType.Network instead:

  bool logonSuccessfull = LogonUser(_username, _domain, _password, LogonType.Network, LogonProvider.WinNT50, ref _token);
  

• Add debug logging to confirm impersonation is working:

  Debug.WriteLine($"Current identity after impersonation: {WindowsIdentity.GetCurrent().Name}");
  

  Check the Kudu logs to ensure the identity switches to your target ServerUser account.

3. Double-Check Shared Folder Permissions #

Even if you set permissions for Network Service, IUSR, etc., these don't matter when using impersonation. Focus on the account you're impersonating (ServerUser):

• Share Permissions: On your on-prem server, right-click the shared folder → Properties → Sharing → Advanced Sharing → Permissions. Give ServerUser Full Control.
• NTFS Permissions: Go to Security tab of the folder properties. Add ServerUser and grant Full Control (including read/write/delete access).
  Don't forget to apply these permissions to all subfolders and files.

4. Validate Credential and Domain Configuration #

Ensure the credentials in your Web App's app settings are correct:

• If ServerDomain is a local account on the on-prem server, use . as the domain (your code already handles this, but double-check).
• Confirm the ServerUser account is not locked out and has a valid password that matches what's stored in app settings.

5. Alternative: Use Cloud-Native File Access #

If impersonation continues to fail due to sandbox restrictions, consider a more cloud-friendly approach:

• Azure File Sync: Sync your on-prem shared folder to Azure Files, then have your Web App access Azure Files directly (no cross-network SMB required).
• Azure Relay: Set up a Relay connection to bridge your on-prem folder and Azure Web App, avoiding sandbox limitations entirely.

Debugging Tip #

Add error logging for the LogonUser call to get specific Win32 error codes, which will help pinpoint why impersonation is failing:

if (!logonSuccessfull)
{
    int errorCode = Marshal.GetLastWin32Error();
    Debug.WriteLine($"LogonUser failed with error code: {errorCode}");
    throw new Win32Exception(errorCode);
}

内容的提问来源于stack exchange，提问作者JohnnyBaltimore