企业官网建设流程全解析

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开始，默认禁用SMBv1；Win11 22H2及以后版本，SMBv1甚至被完全移除安装包。而SMBv2（2006年）和SMBv3（2012年）则引入了会话加密、消息签名、多通道等安全特性。关键点在于：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代表SMBv2，SMB 3.002代表SMBv3，SMB 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但目标服务器要求签名，就会失败。此时有两种解法：

1. 推荐：在目标服务器（Win7）上启用强制签名（需组策略编辑器）：
   • gpedit.msc→ 计算机配置 → 管理模板 → 网络 → Lanman工作站 → “数字签名安全级别” → 设为“已启用” → “最小安全级别”设为“必需”
2. 临时方案：在本机（Win11）降低要求（不推荐用于生产环境）：

   Set-SmbClientConfiguration -RequireSecuritySignature $false -EnableSecuritySignature $true

注意：Set-SmbClientConfiguration修改的是客户端行为，不影响本机作为服务器时的策略。所有修改后，务必重启Workstation服务：Restart-Service LanmanWorkstation。

3. 服务与发现层：网络邻居看不见？先看这四个服务是否活着

Windows的“网络”视图（也就是传说中的“网络邻居”）不是魔法生成的，它依赖四个核心服务协同工作。任何一个挂掉，“网络”图标里就只剩一片荒漠。很多人以为共享没开，其实是服务死了。

3.1 四大支柱服务及其不可替代性

特别强调：Function Discovery Resource Publication（简称FDResPub）是共享资源能否被邻居看见的决定性服务。它负责将你设置的共享文件夹注册到网络发现数据库。如果它没运行，哪怕你共享设置完美无缺，其他电脑也绝对看不到你。

验证方法：按Win+R，输入services.msc，找到以上四项，检查状态是否为“正在运行”，启动类型是否为“自动（延迟启动）”。若为“已停止”，右键“启动”；若启动类型为“禁用”，右键“属性”→启动类型改为“自动（延迟启动）”→应用。

3.2 网络发现开关背后的三层逻辑

控制面板里的“启用网络发现”看似一个开关，实则触发三重检查：

1. 网络位置类型：必须是“专用”网络（Private），不能是“公用”网络（Public）。Win10/11安装后首次联网，系统常错误识别为“公用”，导致网络发现被强制关闭。修正方法：设置 → 网络和Internet → 状态 → 属性 → 将网络配置文件设为“专用”。

2. 防火墙规则组：启用网络发现会自动启用以下防火墙规则组：

   • 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 True

3. DNS Client服务：该服务负责本地名称解析。若它停止，\\COMPUTERNAME\share这种基于计算机名的访问会失败，只能用IP地址（\\192.168.1.100\share）。检查并启动：

   Get-Service Dnscache | Start-Service

3.3 为什么“网络”里能看到电脑却打不开共享？

这是最迷惑人的场景：你在“网络”里清晰看到对方电脑图标，双击却提示“你没有权限访问...”。这通常意味着服务层通畅，但共享层或安全层阻断。

排查链路：

1. 确认共享路径语法正确：Windows访问共享必须用UNC路径（\\服务器名\共享名或\\IP地址\共享名）。切勿用C:\share这种本地路径。
2. 检查目标机共享权限：右键共享文件夹 → “属性” → “共享”选项卡 → “高级共享” → “权限”。这里设置的是网络访问权限，与NTFS权限无关。默认“Everyone”只有读取权，若需写入，必须手动添加用户并勾选“更改”“写入”。
3. 检查目标机NTFS权限：右键文件夹 → “属性” → “安全”选项卡。这是本地文件系统权限，必须与共享权限叠加生效。例如：共享权限允许“Everyone”读取，但NTFS权限拒绝“Users”组，最终结果仍是拒绝访问。
4. 验证凭据是否被缓存污染：这是高频陷阱！当你曾用错误密码登录过某共享，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不是简单地记下你的密码，它维护着一套精密的凭据缓存体系：

1. 会话级凭据（Session Credentials）：本次登录Windows时输入的域/本地账号密码，用于本机会话内所有操作。这是最优先使用的凭据。
2. Windows凭据管理器（Credential Manager）：存储你手动保存的网络凭据（如\\server\share）、Web凭据、Windows证书。它分为“Web凭据”和“Windows凭据”两个标签页。
3. 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.bat：

@echo 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共享的正确配置流程：

1. 宿主机（Windows）准备：

   • 确保VMware Workstation已安装最新版
   • 在宿主机上创建一个空文件夹（如C:\vmshare），不要放敏感文件
   • 右键该文件夹 → 属性 → 安全 → 编辑 → 添加Everyone组 → 赋予“完全控制”（仅限测试环境；生产环境应限定为VMware User组）

2. 虚拟机设置：

   • 关机状态下，右键虚拟机 → 设置 → 选项 → 共享文件夹 → 启用共享文件夹
   • 添加文件夹：浏览选择C:\vmshare，共享名称设为vmshare（不带路径）
   • 关键设置：勾选“总是启用”，并确保“映射为网络驱动器”处于未勾选状态（此项仅对Windows客户机有效，且易冲突）

3. 客户机（Windows）挂载：

   • 启动客户机，确保VMware Tools已安装并运行（任务栏有VMware图标）
   • 打开“此电脑”，应自动出现“VMware Shared Folders”网络位置，点开即可看到vmshare
   • 若未出现，手动映射：net use X: \\vmware-host\Shared Folders\vmshare

为什么客户机Win11常连不上？根因与解法：

• 根因1：VMware 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协议，而非挂载。

1. 在WSL2中安装cifs-utils（Ubuntu/Debian）：

   sudo apt update && sudo apt install cifs-utils

2. 创建挂载点并挂载：

   # 创建挂载目录 sudo mkdir /mnt/winshare # 挂载Windows共享（需提前在Windows端开启SMB并设置好权限） sudo mount -t cifs //192.168.1.100/share /mnt/winshare -o username=winuser,password=winpass,uid=1000,gid=1000,vers=3.0

   关键参数：

   • vers=3.0：强制指定SMB版本，避免协商失败
   • uid=1000,gid=1000：将挂载文件的所有者映射为WSL2的默认用户（避免权限拒绝）

3. 永久挂载（写入/etc/fstab）：

   # 编辑fstab sudo nano /etc/fstab # 添加一行（注意用tab分隔，非空格） //192.168.1.100/share /mnt/winshare cifs username=winuser,password=winpass,uid=1000,gid=1000,vers=3.0 0 0 # 重新挂载所有 sudo mount -a

注意：将密码明文写入fstab有安全风险。生产环境应使用凭据文件：

echo "username=winuser" | sudo tee /etc/samba/credentials echo "password=winpass" | 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共享，但默认配置常因加密策略不匹配而失败。

标准连接流程：

1. 安装必要包：

   sudo apt install samba smbclient cifs-utils

2. 测试连接与列表共享：

   # 列出Windows主机上的所有共享 smbclient -L //192.168.1.100 -U winuser # 若提示“protocol negotiation failed”，说明SMB版本不匹配

3. 强制指定SMB版本连接：

   # 使用SMBv2连接（Win10/11默认） smbclient //192.168.1.100/share -U winuser --option='client min protocol=SMB2' --option='client max protocol=SMB3' # 若目标为Win7，尝试SMBv1（不推荐） smbclient //192.168.1.100/share -U winuser --option='client min protocol=NT1' --option='client max protocol=NT1'

永久挂载的关键配置（/etc/fstab）：

# 使用_cifs类型（非smbfs，后者已废弃） //192.168.1.100/share /mnt/winshare cifs credentials=/home/user/.smbcred,uid=1000,gid=1000,iocharset=utf8,sec=ntlmssp,vers=3.0 0 0

其中/home/user/.smbcred内容为：

username=winuser password=winpass

权限必须设为600：chmod 600 /home/user/.smbcred。

最顽固问题：Ubuntu挂载后文件权限混乱
表现为：在Ubuntu中创建的文件，Windows端显示为“只读”；或反之。这是因为SMB协议不传递Linux的POSIX权限。解法是在挂载选项中显式指定：

• file_mode=0777,dir_mode=0777：赋予所有用户读写执行权
• noperm：忽略远程服务器的权限检查，完全由本地挂载选项控制

完整fstab行：

//192.168.1.100/share /mnt/winshare cifs credentials=/home/user/.smbcred,uid=1000,gid=1000,iocharset=utf8,sec=ntlmssp,vers=3.0,file_mode=0777,dir_mode=0777,noperm 0 0

6. 故障排查全景图：从“网络看不见”到“连上打不开”的逐层手术刀

当所有常规操作都失败，你需要一张覆盖全链路的排查地图。下面这张表，是我根据200+次现场排障总结出的“症状-层级-检测命令-修复动作”四维对照表。它不按教科书顺序，而是按你实际遇到的报错现象倒推，直击病灶。

实战案例：某设计工作室的“幽灵断连”问题

现象：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 3600

  （3600秒=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 $true

7.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命令，统一映射共享，并集中管理凭据（凭据存储在域控制器