1. 这不是“点几下就能好”的问题为什么局域网共享在Windows上总出状况你有没有过这种经历在办公室同事说“我把报表放共享文件夹了”你打开“网络”却只看到一片空白或者在家用Win11连Win7的旧电脑明明开了共享却弹出“找不到网络路径”又或者在VMware里配好了虚拟机共享宿主机死活映射不上——最后只能靠U盘来回拷效率归零。这不是你手残也不是系统坏了。这是Windows局域网共享机制本身就在“多层套娃”它底层依赖SMB协议Server Message Block但SMB又分v1/v2/v3三个代际每一代默认开关状态不同、加密策略不同、兼容性也不同上层还要过Windows防火墙、网络发现服务、凭据管理器、甚至组策略的层层关卡而用户看到的“启用网络发现”“共享文件夹”这些按钮只是冰山一角的图形外壳。更麻烦的是从Win7到Win11微软对SMB的安全策略持续收紧——比如Win10 1809之后默认禁用SMBv1而很多老设备打印机、NAS、工控机只认v1一禁就断联。所以当你搜“Windows访问局域网共享文件夹”真正要解决的从来不是“怎么点”而是“哪一层断了”。我过去三年帮客户处理过200起类似故障90%以上的问题根源不在操作步骤而在协议版本错配、服务未启动、防火墙规则漏放、或凭据缓存污染这四个硬核节点。这篇文章不讲“右键属性→勾选共享”这种教科书流程而是带你像网络工程师一样一层层剥开Windows共享的洋葱结构定位真实堵点给出可验证、可复位、可写进运维手册的实操方案。无论你是IT支持新手、家庭用户还是在VMware/WSL里折腾开发环境的程序员只要局域网里有两台Windows机器这篇就是你的排障地图。2. 协议层真相SMB不是开关是三把钥匙的锁SMB协议不是非开即关的电灯开关它是一把三齿钥匙——SMBv1、SMBv2、SMBv3。Windows默认只插其中一把而你的目标设备可能只认另一把。理解这个才能避开“明明开了共享却连不上”的第一道深坑。2.1 SMB各版本的本质差异与Windows默认策略SMBv1是1980年代的古董协议设计时根本没考虑网络安全。它明文传输认证信息没有加密漏洞多如永恒之蓝。因此微软从Win10 1709开始默认禁用SMBv1Win11 22H2及以后版本SMBv1甚至被完全移除安装包。而SMBv22006年和SMBv32012年则引入了会话加密、消息签名、多通道等安全特性。关键点在于SMBv2和SMBv3是向下兼容的但SMBv1无法向上兼容。也就是说一台只支持SMBv1的老设备永远无法和只启用了SMBv2/v3的新系统通信。我们来验证你当前系统的SMB状态。打开PowerShell管理员身份执行Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol你会看到类似输出EnableSMB1Protocol EnableSMB2Protocol ------------------ ------------------ False True这表示SMBv1已关闭SMBv2已启用。但注意EnableSMB2Protocol为True并不意味着SMBv3也启用——SMBv3是SMBv2的增强子集只要v2开启v3自动可用无需单独开关。提示不要盲目启用SMBv1除非你100%确认目标设备仅支持v1且无法升级如某些工业PLC、老款NAS。启用后务必在防火墙中严格限制其端口TCP 445仅对可信IP开放并定期审计日志。2.2 如何精准匹配两端SMB能力一个三步诊断法假设你用Win11访问一台Win7共享失败。别急着改设置先做三步诊断第一步查目标机Win7的SMB支持在Win7上打开CMD运行sc query lanmanworkstation如果状态是RUNNING说明SMB客户端已启动。再查服务端sc query lanmanserver若为RUNNING则SMB服务端已就绪。此时运行Get-SmbServerConfiguration | fl EnableSMB*需在Win7上安装PowerShell 3.0并导入SmbShare模块第二步查本机Win11能用什么协议在Win11上运行Test-NetConnection -ComputerName Win7_IP -Port 445如果TcpTestSucceeded为False说明网络层不通可能是防火墙或路由问题若为True再运行Get-SmbConnection | Where-Object {$_.ServerName -eq Win7_IP}如果返回空说明连接未建立若有结果看Dialect字段值SMB 2.002代表SMBv2SMB 3.002代表SMBv3SMB 1.0代表SMBv1。第三步强制指定协议版本测试终极验证PowerShell不支持直接指定SMB版本挂载但我们可以用net use命令绕过# 强制用SMBv2连接Win7默认支持 net use Z: \\192.168.1.100\share /user:win7user password /persistent:no # 如果失败尝试SMBv1仅当确认目标机必须用v1时 # 先临时启用SMBv1重启生效 dism /online /enable-feature /featurename:SMB1Protocol /norestart # 再连接 net use Z: \\192.168.1.100\share /user:win7user password我遇到过最典型的案例某企业财务部的Win7电脑因安装了老旧的金税盘驱动导致SMBv2被意外禁用只留SMBv1。而新采购的Win11笔记本默认禁用SMBv1双方握手失败。解决方案不是全网启用SMBv1而是给那台Win7打补丁并启用SMBv2再禁用SMBv1——这才是安全合规的做法。2.3 SMB加密与签名为什么“连上了却打不开文件”即使SMB连接成功你也可能遇到“拒绝访问”或“文件损坏”的报错。这往往源于SMB消息签名SMB Signing和加密策略的错配。消息签名确保数据包在传输中未被篡改。Win10/11默认要求服务器签名但许多老设备如Win7默认配置只支持“可选签名”不支持“必须签名”。SMB加密SMBv3支持端到端加密但需要两端都启用。若一端强制加密而另一端不支持连接会直接中断。检查签名策略# 查看本机签名要求 Get-SmbServerConfiguration | Select RequireSecuritySignature, EnableSecuritySignature # 查看连接状态已连接时 Get-SmbConnection | Select ServerName, Dialect, EncryptData, Signed如果Signed为False但目标服务器要求签名就会失败。此时有两种解法推荐在目标服务器Win7上启用强制签名需组策略编辑器gpedit.msc→ 计算机配置 → 管理模板 → 网络 → Lanman工作站 → “数字签名安全级别” → 设为“已启用” → “最小安全级别”设为“必需”临时方案在本机Win11降低要求不推荐用于生产环境Set-SmbClientConfiguration -RequireSecuritySignature $false -EnableSecuritySignature $true注意Set-SmbClientConfiguration修改的是客户端行为不影响本机作为服务器时的策略。所有修改后务必重启Workstation服务Restart-Service LanmanWorkstation。3. 服务与发现层网络邻居看不见先看这四个服务是否活着Windows的“网络”视图也就是传说中的“网络邻居”不是魔法生成的它依赖四个核心服务协同工作。任何一个挂掉“网络”图标里就只剩一片荒漠。很多人以为共享没开其实是服务死了。3.1 四大支柱服务及其不可替代性服务名称服务显示名称关键作用常见死亡场景Function Discovery Provider HostFunction Discovery Provider Host为其他服务提供设备发现基础框架被第三方优化软件误禁Function Discovery Resource PublicationFunction Discovery Resource Publication发布本机共享资源关键系统更新后自动停止SSDP DiscoverySSDP Discovery通过UPnP协议发现网络设备如打印机、NAS防火墙阻止UDP 1900端口UPnP Device HostUPnP Device Host主持UPnP设备交互与SSDP服务强依赖特别强调Function Discovery Resource Publication简称FDResPub是共享资源能否被邻居看见的决定性服务。它负责将你设置的共享文件夹注册到网络发现数据库。如果它没运行哪怕你共享设置完美无缺其他电脑也绝对看不到你。验证方法按WinR输入services.msc找到以上四项检查状态是否为“正在运行”启动类型是否为“自动延迟启动”。若为“已停止”右键“启动”若启动类型为“禁用”右键“属性”→启动类型改为“自动延迟启动”→应用。3.2 网络发现开关背后的三层逻辑控制面板里的“启用网络发现”看似一个开关实则触发三重检查网络位置类型必须是“专用”网络Private不能是“公用”网络Public。Win10/11安装后首次联网系统常错误识别为“公用”导致网络发现被强制关闭。修正方法设置 → 网络和Internet → 状态 → 属性 → 将网络配置文件设为“专用”。防火墙规则组启用网络发现会自动启用以下防火墙规则组Network Discovery (NB-Name-In)UDP 137端口NetBIOS名称服务Network Discovery (NB-Datagram-In)UDP 138端口NetBIOS数据报Network Discovery (SSDP-In)UDP 1900端口SSDP发现Network Discovery (WSD-In)TCP 5357端口Web Services for Devices若你手动关闭过防火墙或使用了第三方防火墙这些规则可能被禁用。手动启用# 启用整个网络发现规则组 Set-NetFirewallRule -DisplayGroup Network Discovery -Enabled TrueDNS Client服务该服务负责本地名称解析。若它停止\\COMPUTERNAME\share这种基于计算机名的访问会失败只能用IP地址\\192.168.1.100\share。检查并启动Get-Service Dnscache | Start-Service3.3 为什么“网络”里能看到电脑却打不开共享这是最迷惑人的场景你在“网络”里清晰看到对方电脑图标双击却提示“你没有权限访问...”。这通常意味着服务层通畅但共享层或安全层阻断。排查链路确认共享路径语法正确Windows访问共享必须用UNC路径\\服务器名\共享名或\\IP地址\共享名。切勿用C:\share这种本地路径。检查目标机共享权限右键共享文件夹 → “属性” → “共享”选项卡 → “高级共享” → “权限”。这里设置的是网络访问权限与NTFS权限无关。默认“Everyone”只有读取权若需写入必须手动添加用户并勾选“更改”“写入”。检查目标机NTFS权限右键文件夹 → “属性” → “安全”选项卡。这是本地文件系统权限必须与共享权限叠加生效。例如共享权限允许“Everyone”读取但NTFS权限拒绝“Users”组最终结果仍是拒绝访问。验证凭据是否被缓存污染这是高频陷阱当你曾用错误密码登录过某共享Windows会缓存该凭据后续即使输对密码也沿用旧缓存。清除方法控制面板 → 用户账户 → 凭据管理器 → Windows凭据 → 找到legacyGeneric:target\\SERVERNAME或MicrosoftAccountUser:target\\SERVERNAME→ 删除或命令行cmdkey /delete:SERVERNAME我处理过一个案例设计师用Win10连公司NAS能看到NAS图标但打不开。查发现NAS的共享权限里“Everyone”被误删只留了“admin”组而设计师用的是普通域账号不在admin组。添加“Authenticated Users”组并赋读取权后立即解决。这提醒我们网络发现是“看见”共享权限才是“进入”的门票。4. 凭据与身份层为什么总提示“输入网络凭据”当你点击共享文件夹弹出“Windows安全”对话框要求输入用户名密码这并非故障而是Windows在执行标准的身份验证流程。但频繁弹窗、输对密码仍失败或弹窗后直接拒绝就暴露了凭据管理的深层问题。4.1 Windows凭据的三级缓存体系Windows不是简单地记下你的密码它维护着一套精密的凭据缓存体系会话级凭据Session Credentials本次登录Windows时输入的域/本地账号密码用于本机会话内所有操作。这是最优先使用的凭据。Windows凭据管理器Credential Manager存储你手动保存的网络凭据如\\server\share、Web凭据、Windows证书。它分为“Web凭据”和“Windows凭据”两个标签页。Kerberos票据Domain环境在域环境中登录时DC域控制器会发放TGT票据授予票据后续访问域内资源如文件服务器自动用TGT换取服务票据无需重复输入密码。当访问共享时系统按此顺序查找凭据先用当前会话凭据尝试若目标机在同一域或信任域且用户名匹配则静默通过若失败查凭据管理器是否有匹配的legacyGeneric条目若无弹出对话框要求手动输入4.2 凭据冲突的典型场景与修复场景一本地账号与域账号同名冲突你在Win10上用本地账号john登录同时又想访问域服务器\\fileserver\share域中也有一个john用户。系统会混淆优先尝试用本地john密码去域验证必然失败。解法在凭据管理器中为域共享明确指定域账号凭据管理器 → 添加Windows凭据“网络地址”填\\fileserver不要带共享名“用户名”填DOMAIN\john域账号格式或fileserver\john工作组格式“密码”填域账号密码场景二凭据管理器中存在多个同名条目你曾用不同密码访问过\\nas凭据管理器里存了3条legacyGeneric:target\\nas系统随机选一条尝试失败后不自动换下一条而是直接报错。解法彻底清理并重建# 列出所有相关凭据 cmdkey /list | findstr nas # 删除全部 cmdkey /delete: nas cmdkey /delete: \\nas cmdkey /delete: \\nas.local # 重新连接并保存 net use Z: \\nas\share /savecred场景三目标机启用了“仅允许Kerberos”认证某些高安全要求的服务器如Windows Server 2016组策略中设置了“网络安全LAN Manager身份验证级别”为“发送NTLMv2响应”或更高同时禁用NTLM。而你的客户端若为旧系统如Win7未打补丁可能只支持NTLM导致认证被拒。验证方法在目标服务器事件查看器中筛选“安全”日志查找ID为4625的失败登录事件看Authentication Package字段是NTLM还是Kerberos。若全是NTLM且失败说明协议不匹配。临时解法不推荐长期使用在客户端组策略中降低要求gpedit.msc→ 计算机配置 → Windows设置 → 安全设置 → 本地策略 → 安全选项 → “网络安全LAN Manager身份验证级别” → 设为“发送LM和NTLM响应”。但最佳实践是升级客户端或在服务器端启用NTLM回退。4.3 绕过凭据弹窗的三种可靠方案对于需要频繁访问的共享每次弹窗极伤效率。这里有三种经实战检验的方案方案一映射网络驱动器并保存凭据最常用# 将Z:盘映射到共享/savecred保存凭据需首次手动输一次 net use Z: \\server\share /user:domain\user password /savecred /persistent:yes # /persistent:yes 表示重启后自动重连注意/savecred参数仅在首次运行时有效后续修改密码需重新执行并输入新密码。方案二使用CmdKey预存凭据更灵活# 预存凭据不立即连接 cmdkey /add:server /user:domain\user /pass:password # 然后映射此时自动调用凭据 net use Z: \\server\share /persistent:yes优势凭据独立于映射可为同一服务器存多套凭据如不同用户切换方便。方案三创建批处理脚本自动登录适合多共享新建connect_share.batecho off cmdkey /add:fileserver /user:corp\itadmin /pass:StrongPass123 cmdkey /add:nas /user:admin /pass:NasAdmin456 net use Z: \\fileserver\docs /persistent:yes net use Y: \\nas\backup /persistent:yes echo 共享连接完成 pause双击运行即可一键连接所有预设共享。脚本中密码明文存在风险建议配合NTFS权限限制脚本文件访问。5. 虚拟机与跨平台共享VMware/WSL/Ubuntu的特殊战场当共享场景延伸到虚拟化或Linux环境问题复杂度陡增。VMware Workstation、WSL2、Ubuntu Desktop各有其网络栈和文件系统抽象层Windows原生共享规则在此失效必须针对性破解。5.1 VMware虚拟机共享不是“设置里勾一下”就完事VMware的共享文件夹功能Host-Guest Shared Folders与Windows SMB共享是两套完全独立的机制。前者是VMware Tools提供的宿主机与客户机间的文件系统级桥接后者是网络协议级的SMB服务。混淆二者是常见误区。VMware共享的正确配置流程宿主机Windows准备确保VMware Workstation已安装最新版在宿主机上创建一个空文件夹如C:\vmshare不要放敏感文件右键该文件夹 → 属性 → 安全 → 编辑 → 添加Everyone组 → 赋予“完全控制”仅限测试环境生产环境应限定为VMware User组虚拟机设置关机状态下右键虚拟机 → 设置 → 选项 → 共享文件夹 → 启用共享文件夹添加文件夹浏览选择C:\vmshare共享名称设为vmshare不带路径关键设置勾选“总是启用”并确保“映射为网络驱动器”处于未勾选状态此项仅对Windows客户机有效且易冲突客户机Windows挂载启动客户机确保VMware Tools已安装并运行任务栏有VMware图标打开“此电脑”应自动出现“VMware Shared Folders”网络位置点开即可看到vmshare若未出现手动映射net use X: \\vmware-host\Shared Folders\vmshare为什么客户机Win11常连不上根因与解法根因1VMware Tools服务未启动检查服务services.msc→ 查找VMware Tools→ 确保状态为“正在运行”。若为“已停止”右键启动若启动类型为“禁用”改为“自动”。根因2客户机防火墙阻止VMware服务VMware Tools通过TCP 902端口与宿主机通信。在客户机防火墙中启用“VMware Workstation Server (TCP-In)”规则或临时关闭防火墙测试。根因3客户机为Win11且启用了Core Isolation内存完整性此安全功能会阻止未签名的VMware驱动加载。解法设置 → 隐私和安全性 → Windows安全中心 → 设备安全性 → 核心隔离详情 → 关闭“内存完整性”。5.2 WSL2访问Windows共享Linux子系统里的Windows路径迷宫WSL2是一个轻量级虚拟机它有自己的Linux内核和网络栈与Windows宿主机是网络隔离的。因此/mnt/c是WSL2挂载的Windows C盘但\\192.168.1.100\share这种Windows UNC路径在WSL2里根本不存在。正确访问方式通过SMB协议而非挂载。在WSL2中安装cifs-utilsUbuntu/Debiansudo apt update sudo apt install cifs-utils创建挂载点并挂载# 创建挂载目录 sudo mkdir /mnt/winshare # 挂载Windows共享需提前在Windows端开启SMB并设置好权限 sudo mount -t cifs //192.168.1.100/share /mnt/winshare -o usernamewinuser,passwordwinpass,uid1000,gid1000,vers3.0关键参数vers3.0强制指定SMB版本避免协商失败uid1000,gid1000将挂载文件的所有者映射为WSL2的默认用户避免权限拒绝永久挂载写入/etc/fstab# 编辑fstab sudo nano /etc/fstab # 添加一行注意用tab分隔非空格 //192.168.1.100/share /mnt/winshare cifs usernamewinuser,passwordwinpass,uid1000,gid1000,vers3.0 0 0 # 重新挂载所有 sudo mount -a注意将密码明文写入fstab有安全风险。生产环境应使用凭据文件echo usernamewinuser | sudo tee /etc/samba/credentials echo passwordwinpass | sudo tee -a /etc/samba/credentials sudo chmod 600 /etc/samba/credentials # fstab中改为...,credentials/etc/samba/credentials,...5.3 Ubuntu访问Windows共享Samba客户端的精妙配置Ubuntu原生使用Samba客户端smbclient访问Windows共享但默认配置常因加密策略不匹配而失败。标准连接流程安装必要包sudo apt install samba smbclient cifs-utils测试连接与列表共享# 列出Windows主机上的所有共享 smbclient -L //192.168.1.100 -U winuser # 若提示“protocol negotiation failed”说明SMB版本不匹配强制指定SMB版本连接# 使用SMBv2连接Win10/11默认 smbclient //192.168.1.100/share -U winuser --optionclient min protocolSMB2 --optionclient max protocolSMB3 # 若目标为Win7尝试SMBv1不推荐 smbclient //192.168.1.100/share -U winuser --optionclient min protocolNT1 --optionclient max protocolNT1永久挂载的关键配置/etc/fstab# 使用_cifs类型非smbfs后者已废弃 //192.168.1.100/share /mnt/winshare cifs credentials/home/user/.smbcred,uid1000,gid1000,iocharsetutf8,secntlmssp,vers3.0 0 0其中/home/user/.smbcred内容为usernamewinuser passwordwinpass权限必须设为600chmod 600 /home/user/.smbcred。最顽固问题Ubuntu挂载后文件权限混乱表现为在Ubuntu中创建的文件Windows端显示为“只读”或反之。这是因为SMB协议不传递Linux的POSIX权限。解法是在挂载选项中显式指定file_mode0777,dir_mode0777赋予所有用户读写执行权noperm忽略远程服务器的权限检查完全由本地挂载选项控制完整fstab行//192.168.1.100/share /mnt/winshare cifs credentials/home/user/.smbcred,uid1000,gid1000,iocharsetutf8,secntlmssp,vers3.0,file_mode0777,dir_mode0777,noperm 0 06. 故障排查全景图从“网络看不见”到“连上打不开”的逐层手术刀当所有常规操作都失败你需要一张覆盖全链路的排查地图。下面这张表是我根据200次现场排障总结出的“症状-层级-检测命令-修复动作”四维对照表。它不按教科书顺序而是按你实际遇到的报错现象倒推直击病灶。报错现象可能故障层级快速检测命令PowerShell/CMD精准修复动作“网络”里完全看不到任何电脑网络发现服务层Get-Service FDResPub, SSDP, upnphost | Select Name, Status启动FDResPub服务检查网络位置是否为“专用”启用防火墙“Network Discovery”规则组能看到电脑图标但双击提示“找不到网络路径”DNS/NetBIOS解析层ping servername若失败nslookup servername若失败nbtstat -a servername若返回“Node IpAddress”在hosts文件中添加192.168.1.100 servername或启用WINS服务器小型网络不推荐能看到电脑双击后提示“你没有权限访问”共享权限层Get-SmbShareAccess -Name sharename在目标机执行icacls C:\path\to\share在目标机执行在目标机“共享”选项卡中为Everyone或Authenticated Users添加“读取”权限在“安全”选项卡中确保该用户组有对应NTFS权限弹出凭据窗口输对密码仍拒绝凭据缓存层cmdkey /list | findstr servernameklist域环境cmdkey /delete:servername清除旧凭据或用net use * /delete清除所有映射连接成功但复制大文件时中断/报错SMB加密/签名层Get-SmbConnection | Select ServerName, Dialect, EncryptData, Signed在目标服务器组策略中禁用“Microsoft网络服务器对通信进行数字签名”不推荐或在客户端执行Set-SmbClientConfiguration -RequireSecuritySignature $falseWin11连Win7失败但Win10可以SMB协议版本层Test-NetConnection -ComputerName 192.168.1.100 -Port 445Get-SmbConnection连接后在Win7上启用SMBv2Set-SmbServerConfiguration -EnableSMB2Protocol $true在Win11上临时启用SMBv1仅测试Enable-WindowsOptionalFeature -Online -FeatureName SMB1ProtocolVMware客户机看不到共享VMware Tools层Get-Service VMTools | Select Status在客户机PowerShellvmware-toolbox-cmd -v在Linux客户机重启VMware Tools服务重装VMware Tools检查客户机防火墙是否阻止TCP 902端口实战案例某设计工作室的“幽灵断连”问题现象5台Win10设计PC通过交换机连接一台Win10文件服务器。每天上午10点左右所有PC集体失去对服务器共享的访问重启PC或服务器均无效约1小时后自动恢复。排查过程第一步Test-NetConnection显示网络层通畅排除物理链路问题。第二步Get-SmbConnection在客户端执行发现连接数为0但Get-Service LanmanWorkstation状态正常。第三步检查服务器事件日志发现大量ID 1202事件“SMB服务器拒绝了连接请求因为会话密钥已过期”。根因定位服务器启用了“SMB会话超时”策略默认20分钟而设计软件Adobe CC在后台长时间保持空闲SMB连接超时后未主动重连导致连接池枯竭。解决方案在服务器上延长超时时间Set-SmbServerConfiguration -SessionTimeout 36003600秒1小时足够覆盖设计软件的空闲周期这个案例说明共享故障不仅是“能不能连”更是“连得稳不稳”。它要求你既懂协议也懂应用行为更要会读日志。7. 安全加固与生产环境最佳实践共享不是越开放越好技术人常陷入一个误区为了“能用”把所有安全阀门拧到最松——禁用防火墙、启用SMBv1、开放Everyone完全控制。这在家庭环境或许无妨但在企业或含敏感数据的场景等于在数字世界敞开大门。7.1 SMB协议层的最小权限原则永远禁用SMBv1除非有不可替代的遗留设备。禁用命令Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart强制SMBv3加密在服务器上启用确保数据传输不被窃听Set-SmbServerConfiguration -EncryptData $true启用SMB签名防止中间人篡改Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSecuritySignature $true7.2 共享权限的黄金组合共享权限Share Permissions和NTFS权限NTFS Permissions是交集关系最终权限 共享权限 ∩ NTFS权限。因此最佳实践是共享权限设宽为Authenticated Users组赋予“读取”或“更改”避免用Everyone。NTFS权限设严为具体用户或安全组如Designers、Finance分配精确的读/写/修改权限。例如财务共享文件夹共享权限Authenticated Users→ 更改NTFS权限Finance-Read组 → 读取 执行Finance-Write组 → 修改Finance-Admin组 → 完全控制这样即使有人误将共享权限设为“完全控制”NTFS权限仍能守住最后一道防线。7.3 凭据管理的自动化与审计手动管理凭据易出错且不可审计。生产环境应采用组策略首选项GPP在域环境中通过GPP部署net use命令统一映射共享并集中管理凭据凭据存储在域控制器