徐小疼带团队这几年，我接手过不少Windows Server环境，最头疼的往往不是故障本身，而是账户权限一团乱麻：离职员工的账号没禁、普通用户居然在管理员组里挂着、谁都能远程桌面登录。Windows Server的用户管理和组管理，看似只是“建个账号、拉进组”，实际上直接决定了后面所有远程连接、服务权限、安全基线能否顺利落地。这篇就围绕“用户、组和远程连接”这三个动作，把底层逻辑、实操步骤和那些文档里不写的坑一次说透。无论你是刚接触Windows Server 2008 R2的运维新手，还是在Windows Server 2019/2022上做基础架构的同行，都应该能从这里获得一些可以马上动手借鉴的经验。
1. 先把账户和权限的关系弄清楚：用户的本质是一张带权限的通行证
1.1 用户账号在Windows Server里到底是种什么样的对象
很多刚入门的朋友把“用户账号”理解成单纯的登录名和密码，这个方向没错，但会忽略一个重要事实：Windows Server里的账号本质是一个安全主体（Security Principal），它带有唯一的SID（安全标识符），操作系统在授权时认的是SID，而不是用户名。
这就是为什么你重命名一个账号后，它的权限和配置文件还能保留，因为SID没变。反过来，如果你删了账号再用同样的用户名新建，看起来名字一样，权限却完全丢失了，因为新账号的SID是全新的。这个知识点在后续排障中会反复遇到，比如某个服务运行账户出了问题，第一反应应该是确认SID映射关系而不是只看名字。
Windows Server的用户账号主要分三类：
- 内置账号：最常见的是Administrator和Guest。Administrator是系统安装时创建的超级管理员，默认SID固定以-500结尾；Guest是给临时访问用的，默认禁用。
- 本地用户：只存在于某台独立的Windows Server本地SAM数据库中，只能在本地登录或访问本机资源，不参与域环境。
- 域用户：由Active Directory统一管理，账号信息存放在域控的NTDS.dit数据库中，可以在域内任意一台成员服务器上登录，前提是被赋予相应权限。
在单机、非域的工作组环境下，日常管理的都是本地用户和本地组。一旦上了域，最好用组策略和ADUC（Active Directory Users and Computers）统一管，本地SAM里的账号反而要越少越好，否则服务器本地管理员密码分散管理，本身就是隐患。
1.2 服务账号和交互式登录账号必须分开
这是一个经常被忽视的“用户管理”问题。在Windows Server上跑SQL Server、MySQL、IIS AppPool时，安装向导会提示“指定服务账户”。不少图省事的教程直接让你用本地System或者当前管理员账号。第一次帮公司搭测试环境时可以这么做，可真到生产环境，如果应用权限出了问题，你根本分不清是应用程序访问共享路径失败，还是数据库服务启动失败。
正确做法是给服务单独建一个“低权限用户”，比如svc_sql、svc_web，把它加入“作为服务登录”的用户权利列表中。具体操作用secpol.msc打开本地安全策略，在“本地策略—用户权限分配”里找到“作为服务登录”，把服务账户加进去。很多人只建了用户没加这项，结果服务启动报“登录失败”或拒绝访问，就是这个原因。
这类服务账号还要设置“密码永不过期”，并且通过服务管理器里的“恢复”选项配置失败重启，密码变更要走专门的密码轮换流程，而不是直接在“用户属性”里随手改。我见过太多因为随手改了服务账号密码，导致一堆服务第二天集体罢工的案例，所以在这点上值得多花五分钟规划清晰。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 组管理实战：用组来承载权限，而不是逐人授权
2.1 内置组到底能干什么，很多人其实没搞清
Windows Server装好后自带一批内置组，打开“计算机管理—本地用户和组—组”就能看到。先列一张常用对照表：
| 组名称 | 默认权限范围 | 使用建议 |
|---|---|---|
| Administrators | 本机最高权限，可以安装系统组件、修改安全策略、管理其他用户 | 成员越少越好，日常登录建议用普通用户，需要提权时再操作 |
| Users | 普通用户，能运行应用程序但不能修改系统设置 | 绝大多是业务人员和服务账号应在此组 |
| Remote Desktop Users | 仅拥有通过远程桌面登录本机的权限 | 这是控制RDP访问范围的关键组 |
| Network Configuration Operators | 可修改TCP/IP配置但不能安装驱动或修改安全策略 | 适合给网络管理类脚本/账户使用 |
| Performance Monitor Users | 可查看性能计数器，不能修改权限 | 给监控平台拉取指标时用 |
| Backup Operators | 可以绕过NTFS权限做备份和还原 | 给备份软件代理服务使用，能不用管理员就不用 |
很多人喜欢把普通业务用户直接加进Administrators，因为“省得调用UAC弹窗”，但这在服务器上是极其危险的动作。Windows Server不是个人开发机，任何通过弱口令打进来的攻击者，一旦拿到普通用户账号，如果这个账号已经在管理员组，他就能直接拿走整台机器。
正确的做法是：能进入Remote Desktop Users就绝不放Administrators；某些一次性操作需要管理员权限时，可以配合“运行方式”输入管理员凭证，而不是把这个普通用户本身提权。
2.2 创建自定义组的步骤和推荐命名
拿一台Windows Server 2016/2022为例，手动建组的路径是：把服务器管理器打开，在“工具—计算机管理—本地用户和组—组”上右键选择“新建组”。组名我建议带上前缀区分用途，比如：
- RD-Ops：允许远程桌面连接的运维人员
- App-SQL：运行SQL服务的专用账号
- App-Backup：只能做备份操作的账号组
新建组后把用户加进去，可以通过“属性—添加”逐个加，但如果用户成百上千，手动肯定不现实。管理员可以用PowerShell批量完成：
powershell复制# 创建组
New-LocalGroup -Name 'RD-Ops' -Description 'Remote Desktop Operators'
# 批量将用户加入组，先准备用户列表文件members.txt
$users = Get-Content C:\scripts\members.txt
foreach ($user in $users) {
Add-LocalGroupMember -Group 'RD-Ops' -Member $user
}
# 查看组成员
Get-LocalGroupMember -Group 'RD-Ops'
在域环境里则是把组放在某个OU下，用ADUC创建域本地组或全局组，成员来自多个域用户。命名规则建议区分“角色组”“权限组”和“嵌套层”，例如RDP-角色组可以包含普通账号，DBAdmins-权限组可以嵌套其他角色组，避免一个组既管登录又管数据库权限。
2.3 为什么用“组”而非直接给人授权
直接在某目录的NTFS权限里写“允许张三读写”，和把所有需要读写的人拉进一个组，再给组授读写权限，两者的区别在排障时尤其明显。用组授权后，张三离职你只需要把他从组中踢掉，所有文件权限立刻失效；如果你逐个设了用户权限，还得一遍一遍排查哪些目录还残留他的ACE条目。
同理，远程连接也不建议单独给某个账号增加“允许通过远程桌面服务登录”的权限，而是把它放进Remote Desktop Users或自定义分组。这种设计思路在Windows Server里叫“角色承载权限”，权限的边界永远在权限层定，用户层只负责“属于哪个组织”。维护者要换人时，整体信息一目了然。
2.4 密码策略和账户锁定策略，必须一开始就设置好
Windows Server默认密码策略其实不够严格，尤其对于需要暴露在公网的远程桌面服务器。打开secpol.msc，在“账户策略—密码策略”里我通常设置：
- 密码最长使用期限：90天
- 密码最小长度：12位（没有特殊符号要求的话再加长）
- 密码必须满足复杂性要求：启用
- 账户锁定阈值：5次无效登录后锁定30分钟
账户锁定策略是对抗RDP暴力破解最实用的一招，代价是可能出现外部扫描器把合法账户锁死的误伤情况。所以阈值不建议设成3次这么苛刻，5次比较均衡，同时要有账户锁定计数重置时间的配合。
在域环境中这些策略通常放在默认域策略里下发，本地策略会被组策略覆盖。如果本地设置了但实际不生效，需要先用rsop.msc确认是否有域策略接管。
3. 远程连接三条主路：RDP、OpenSSH、VSCode Remote-SSH
3.1 RDP远程桌面的开关与最小暴露原则
Windows Server的默认远程管理方式就是RDP，系统安装好后就可以在“系统属性—远程”里勾选“允许远程连接到此计算机”。不过这么直接暴露在公网风险很高，我建议至少遵循三个原则：
- 不让内置Administrator直接远程登录，新建一个担任日常运维的账号，加入Administrators或Remote Desktop Users组。
- 修改默认的3389端口到高位端口（如53389），作用不是防扫描，而是减少批量自动扫描工具的噪音。需要修改注册表：
HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber，改成十进制的新端口值，改完重启系统。 - 在Windows防火墙中只允许指定源IP访问RDP端口，而不是Any。
RDP默认只允许两个并发会话，并且同一时间一个用户只能有一个活跃会话。当你多次远程登录时，系统会提示“该用户已连接到另一会话，是否替换”，这对日常维护来说没问题，但如果有多名运维同事同时要用不同账号远程桌面，就需要考虑购买或配置远程桌面服务（RDS）授权。
3.2 在Windows Server上安装OpenSSH Server
越来越多的运维同事习惯了用SSH连Linux，其实Windows Server从2019开始就把OpenSSH做成了可选功能，在Server 2022和2025上安装更方便：
powershell复制Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic
如果是Windows Server 2008 R2这种老版本，OpenSSH就需要依赖第三方实现，我在老服务器上用过Win32-OpenSSH的移植版，也能跑，但补丁更新和兼容性都不如系统自带方案省心。
组件装完之后，用ssh命令连本机测试：
powershell复制ssh localhost
这里有个非常关键的坑：默认情况下Windows OpenSSH只允许Administrators组成员登录，而且远程连接用的公钥文件路径不是普通用户的authorized_keys，而是管理员用户的administrators_authorized_keys，并且该文件权限必须至少删除继承。你如果用普通用户连接，会直接被拒绝。要放开权限，可以在C:\ProgramData\ssh\sshd_config中加一行：
code复制AllowGroups ssh-users
先创建ssh-users本地组，再加入允许SSH登录的普通用户。然后重启sshd服务让配置生效。这一步是区分“装了SSH只是本机通”和“能让业务账号安全登录”的关键。
3.3 用VSCode Remote-SSH连上Windows Server写脚本/调服务
日常写PowerShell脚本或者Debug一段远端代码，老用远程桌面开一个完整图形界面太笨重。VSCode的Remote-SSH扩展很适合这种场景，操作路径：本机VSCode装好Remote-SSH扩展，按F1，选择“Remote-SSH: Connect to Host”，输入你的用户名@服务器IP。
能连上VSCode的前提是Windows Server上的OpenSSH已经被正常配置，且能够通过ssh命令完成登录。首次连接时VSCode会在远端用户目录下安装一个服务器代理，如果看到安装过程卡住，极大概率是远端用户的powershell.exe默认执行策略限制，把Windows PowerShell的ExecutionPolicy改成RemoteSigned即可：
powershell复制Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
连接后左下角会显示当前远程主机，打开文件夹时路径需要用Windows风格，例如C:\scripts。VSCode的集成终端也会默认切到PowerShell 7（如果服务器装了），这对日常维护体验提升非常明显。
3.4 跨网络或在内网时怎么规划SSH隧道
远程连接并不总是“直接IP通”这么简单。很多服务器躲在NAT后面，防火墙只放行特定管理IP。为了不把RDP直接暴露出去，我习惯用一台跳板机做SSH隧道。
场景如下：本机A需要连接内网Windows Server B的3389端口，但B不对公网开放，A只能先SSH到同样在内网的跳板机C。执行：
bash复制ssh -N -L 53389:10.0.0.8:3389 user@jump
隧道建立后，本地RDP客户端连接127.0.0.1:53389，流量会通过C转发到B。这个做法的好处是B上不用开任何额外入站规则，只需要允许从C到B的3389访问，日志里也看不到公网IP的狂轰滥炸。
VSCode Remote-SSH同样支持代理跳转，只需要在.ssh/config里写：
code复制Host win-target
HostName 10.0.0.8
User admin001
ProxyJump user@jump-host
这样就可以做到本机打开VSCode直接编辑内网Windows Server上的文件，和编辑本地目录没什么区别。
4. 权限、会话、协议：远程连接最容易踩的几个坑及排查思路
4.1 为什么Administrators组成员能远程，普通用户却不能
直接说一个现象：你用普通账号能本地登录服务器，但远程桌面时提示“不允许使用您提供的凭据登录”。原因很简单——RDP登录不仅需要密码正确，还需要该用户拥有“允许通过远程桌面服务登录”的用户权利。Administrators组成员默认自带这个权利，普通用户则需要被加进Remote Desktop Users组。
还记得第2节里说的自定义组管理吗？有些人图省事，把远程维护用户直接塞进Administrators，就是为了绕开这层授权。但更规范的做法是打开“本地安全策略—本地策略—用户权限分配—通过远程桌面服务登录”，把Remote Desktop Users组和服务使用的临时维护组都加进去，再打开“拒绝通过远程桌面服务登录”，把系统自带Guest、匿名登录等统统拒绝。
这里需要提醒：添加组的动作在域环境中会被组策略覆盖，有时候你用管理员在五台服务器上手动加了同一个组，而域策略里只允许“Domain Admins”和“Remote Desktop Users”登录，那么其他组仍然是无效的，所以排查时要先确认当前生效策略。
4.2 关闭显示器后远程分辨率变化：根因跟你想的不一样
很多人在Windows Server上插着一个物理显示器时远程分辨率都正常，一旦把显示器关掉或者搬走，再连RDP就发现桌面分辨率被锁死在1024×768，而且“显示设置”里能选的分辨率选项也很少。这个问题的根源在于显卡驱动认为没有物理显示器连着，于是自动切换到一种极简显示模式。
排查思路先看显卡驱动。如果是老服务器用的集成显卡或普通亮机卡，Windows Server没有安装厂商官方驱动，系统只能用Microsoft基本显示适配器，这种驱动无法生成本机没有连接的虚拟显示器，因此RDP的分辨率会受很大限制。
解决方案通常有两种：
- 装好显卡官方驱动程序，再检查“电源选项”里有没有允许关闭显示器后自动降低分辨率的相关设置。
- 使用虚拟显示器驱动程序，让显卡始终认为有一台物理显示器在线，从而保留高分频率输出能力。
在下发RDP时还有一个比较隐蔽的细节：mstsc启动会话前，可以在“显示”选项卡里设置“远程桌面大小”。很多人以为连接后改分辨率就行，其实RDP的显示尺寸通常受客户端启动参数限制。你可以把需要固定分辨率的连接保存为.rdp文件，用记事本打开，显式写入：
code复制desktopwidth:i:1920
desktopheight:i:1080
再用mstsc /edit导入这个文件。这样每次都能以指定分辨率建立会话，比进入会话后手动调整要稳定得多。某些情况下远程会话的分辨率还会受到带宽限制而自动调低，在客户端连接属性里把“体验”调成“局域网”通常能减少这种自动退化。
4.3 远程桌面会话被占用和“应用”“剪贴板”失灵的排查
公司里经常有人抱怨连RDP时提示“账户正在被使用”，或者输入用户名密码后始终转圈进不去。排查时先用qwinsta命令看一下当前会话列表：
code复制qwinsta
会输出会话ID、会话用户名、状态（Active或者Disc）。如果发现某个凭据还有遗留会话在后台，可以强制注销：
code复制logoff 1
其中1替换成实际会话ID。在Windows Server上RDP并发会话数有许可限制，未作RDS授权时，默认允许2个并发会话；如果产生了僵尸会话，就可能出现能连上但马上又断开或黑屏的现象。此时把所有会话踢掉再连通常是立竿见影的。
远程桌面里面“剪贴板不共享”多半是组策略在捣鬼。使用gpedit.msc打开组策略，定位到“计算机配置—管理模板—Windows组件—远程桌面服务—远程桌面会话主机—设备和资源重定向”，确保“不允许剪贴板重定向”为“未配置”或“已禁用”。在比较严格的安全策略中这会默认禁用，所以别一上来就觉得是客户端问题。
4.4 TLS/SSL协议错误代码70的快速排查思路
有同事会遇到Windows Server 2012/2016事件日志里出现“严重警告代码70。在TLS/SSL协议中，代码70代表协议错误”，通常对应客户端和服务器在SSL/TLS握手阶段没法找到共同支持的协议版本或密码套件。
这种问题最典型的场景是：某台老Windows Server只默认启用TLS 1.0，而现代客户端（比如更新后的Windows 10/11或新版浏览器）已经禁用了TLS 1.0。反过来也可能，新版服务器已关闭TLS 1.0/1.1，但老应用还在坚持用旧协议。
排查路线建议：
- 确认时间同步。证书校验失败非常依赖系统时间，服务器时间偏差超过数分钟就会导致握手失败。
- 用工具（Nmap自带的ssl-enum-ciphers脚本或者PowerShell的TLS检测脚本）扫描目标端口支持的TLS版本。
- 在服务器上通过注册表或IIS Crypto工具启用匹配的TLS版本，并且确保公共密码套件存在。手动改注册表很容易因键值不对导致系统级问题，不建议没备份就乱改。
要注意：这类调整影响的是整个系统或IIS的通信基线，不是可以一个网站一个网站单独热切换的小配置。改动前先维护窗口，并且在非业务时段做验证。
5. 从Windows Server 2008到2025：版本的差异对这套方案的影响
5.1 管理入口上的代差
Windows Server 2008 R2还沿用了大量“传统控制台”思维，用户组管理主要通过lusrmgr.msc或Server Manager完成。Windows Server 2012开始，微软把更多重心放在了PowerShell和服务器管理器图形界面上，但lusrmgr.msc依然存在。2016/2019后的服务器系统安装界面默认还比较干净，Admin Center也逐渐成为Web管理主流。
版本差异的影响不在于“能不能建用户”，而在于管理工具的可用语法。比如New-LocalUser、Get-LocalGroupMember这些PowerShell cmdlet是在Windows Server 2016及以后的版本才正式提供；如果你管理的是2008 R2，脚本里用这些cmdlet就会直接报错。旧版服务器通常要退回net user、wmic useraccount或者用.NET的DirectoryEntry来创建用户。
所以我在混用新老Windows Server环境时，会严格遵守一条习惯：要么全部用远程桌面或OpenSSH登录之后手动操作，要么在脚本最开头判断PowerShell版本，选择兼容的账户管理方式，而不是理所当然认为新cmdlet在2008也能跑。
5.2 OpenSSH和远程管理组件在老版本上的取舍
新版本Windows Server可以把OpenSSH当作系统能力直接安装，而Windows Server 2008 R2/2012 R2没有这个内置能力。我过去在2012 R2上用的是Win32-OpenSSH的二进制包，部署起来也不复杂，但需要注意：
- 依赖的服务路径、默认shell配置格式跟新版略有差别
- 微软审核和功能完善度不如系统自带组件
- 操作系统版本本身已经过了微软的支持周期，安装新的SSH不能解决系统层漏洞
如果是老服务器，我的建议是尽量使用网络隔离、防火墙和跳板机保护；如果非要SSH，也优先在系统支持周期内为老服务建立内部镜像源，做好签名校验，防止下载来的OpenSSH包被篡改。
5.3 Windows Server 2022/2025带来的安全默认值变化
Windows Server 2022默认就比老版本多了不少安全强化，比如禁用SMBv1、默认启用VBS（基于虚拟化的安全）等。Windows Server 2025的安全中心进一步整合了终端保护和威胁检测功能，对系统账户的管理也提出了更高要求。
同时，新系统的组策略和脚本工作流越来越偏向用Set-LocalUser、Add-LocalGroupMember这样的结构化PowerShell命令。在自动化的配置管理平台（比如Ansible、SaltStack）中，针对Windows的模块往往也已迁移到PowerShell Remoting（WinRM）或OpenSSH两种通道。使用Ansible管理Windows Server时，远程连接通常依赖WinRM而不是SSH，这一点很多从Linux转过来的人会绕弯路。
如果你继续用“手动远程桌面+图形界面”去逐个点几百台服务器，效率会非常低。在我管理的环境里，账户批量操作和组策略调整几乎全部写成了PowerShell脚本，通过Ingress机器远程执行，RDP只在某些GUI排障时使用。这样才能发挥设置Windows Server用户、组和远程连接这套基础体系的最大价值。
6. 我日常维护账号和远程连接时的几个安全习惯
这些都不是什么高深技术，但踩过坑之后才觉得每一条都值得刻在运维规范里：
- 每个服务账号都设置“密码永不过期”，但必须有密码保管记录。密码保管记录保存在公司密码管理库里，权限按需开通，人员变动立即吊销。
- 只允许运维人员使用普通账号登录并远程桌面，使用管理员权限时通过
runas或UAC二次确认，绝不把普通账号直接加进Administrators。 - 远程桌面端口不默认3389，但不是为了让攻击者找不到，而是让日志更干净。真正的安全靠的是防火墙源IP限制、账号锁定策略和集中审计。
- OpenSSH配置好后把默认shell切到PowerShell，并且用本地安全策略限制
sshd服务只允许指定组登录。公钥比密码登录更适合自动化批量操作，至少在VSCode和跳板机上我都用密钥方式，避免密码散落在多个终端。 - 每季度检查一次内置管理员账号和Guest状态。内置Administrator最好改名，Guest保持禁用状态。检查项可以做成脚本输出到平台，而不是等到被安全扫描报告追踪了再处理。
有一次同事因为手里的服务器管理员密码过期，凌晨连不上服务器，业务报表一直传不上去，最后是机房现场通过IPMI重启并按下F8进入安全模式才把密码重置掉。那之后我就强制要求新建服务器时不能把内置管理员账户设为“密码永不过期”，同时给每个管理人员个人运维账号单独授权，互不共用。相互间不要用同一个管理员账号登录，出了问题连审计都无法定位，这是我们所有人都应该避开的雷。