Windows下C#以另一个用户身份执行文件操作不可直接实现
在C#中，
System.IO所有API（如
File.Copy、
Directory.CreateDirectory）都运行在当前进程的安全上下文中，不会自动切换用户。你无法通过设置某个参数或调用某个
File方法就让
File.WriteAllText以域用户
DOMAINlice的身份写入远程共享——这违反Windows安全模型的基本约束。
必须借助Windows原生机制：CreateProcessAsUser 或 LogonUser + DuplicateToken
真正可行的路径只有一条：用P/Invoke调用Windows API，先用
LogonUser获取目标用户的
IntPtr令牌，再用
CreateProcessAsUser启动一个新进程（比如
cmd.exe或自定义的控制台程序），把文件操作逻辑放到那个进程中执行。.NET本身不封装这类能力，
WindowsIdentity.Impersonate()也仅支持**已登录且有交互会话**的用户（如本地管理员已登录桌面），对服务账户或未登录域用户无效。
常见错误现象：
LogonUser返回
false且
Marshal.GetLastWin32Error()为1327（“用户帐户限制阻止登录”）——多数因目标用户没被授予“以批处理作业登录”权限（
SeBatchLogonRight）。 必须在目标用户所在机器（或域控制器）上，用
secpol.msc或
gpedit.msc为其添加
SeBatchLogonRight调用
LogonUser时
dwLogonType必须为
LOGON32_LOGON_BATCH（值4），不能用
INTERACTIVE生成的令牌需用
DuplicateToken转为
TokenPrimary才能传给
CreateProcessAsUser不要尝试在主线程里
Impersonate()后调
File操作——它只影响线程本地的ACL检查，对网络路径、服务进程等场景完全无效
更现实的选择：用PsExec或PowerShell Remoting绕过代码复杂度
如果目标是自动化部署或管理任务，硬啃
LogonUser容易掉进权限、会话0隔离、UAC、令牌泄漏等坑里。实际工程中，90%的场景更适合用外部工具委托执行： 用
PsExec -u DOMAINuser -p password -h cmd /c "copy src.txt \\server\share\dest.txt"——
-h确保高完整性级别，避免UAC拦截 PowerShell中用
Invoke-Command -ComputerName server -Credential $cred { Copy-Item ... }，依赖WinRM，但权限模型清晰
若必须嵌入C#，可用Process.Start()调用
PsExec，捕获其
StandardOutput和
ExitCode判断成败，比自己P/Invoke稳定得多
注意：
PsExec默认启用
LocalAccountTokenFilterPolicy注册表项（需设为1），否则远程管理员组成员会被降权；PowerShell Remoting需提前在目标机运行
Enable-PSRemoting -Force。
网络路径访问失败？先确认是身份问题还是SMB协商问题
很多开发者以为“以另一用户操作文件”就是解决
UnauthorizedAccessException的银弹，但真实情况常是SMB协议层面卡住：比如目标共享启用了SMB签名强制，而客户端未配置；或服务器是Windows Server 2016+，默认禁用NTLMv1，但你的凭据仍走旧协议。 先用
net use Z: \\server\share /user:DOMAIN\user password手动测试——失败则不是C#代码问题，而是网络/域策略问题 检查
HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature是否与服务器匹配 临时禁用SMB签名（仅测试）：
Set-SmbServerConfiguration -RequireSecuritySignature $false -ForceC#中
\servershare路径必须用双反斜杠，单斜杠或正斜杠会导致
IOException而非权限错误
真正的难点从来不在“怎么写几行C#”，而在于厘清Windows身份验证链路：Kerberos票据生命周期、SPN注册、会话隔离层级、SMB协议版本协商——这些环节任一断裂，都会表现为“无法以另一用户操作文件”，但修复方式跟C#代码毫无关系。
