接手过不少 Windows 服务器的运维也带过不少刚入行的同事我发现大家对“用户管理”这件事的理解往往停留在“右键新建用户”这个层面。一旦遇到批量创建、权限继承、登录审计、配置漂移这种实际场景就很容易抓瞎。其实 Windows 用户管理是整个系统安全和管理的地基地基没打好后面装什么安全软件、做什么加固策略都是空中楼阁。这篇文章我会把 Windows 用户管理这件事彻底讲透从图形界面基础操作到命令行批量处理再到权限模型、安全日志、常见故障排查全部串起来讲一遍。内容不求标新立异但保证每一条都是实际环境里验证过的东西适合刚接触 Windows 运维的工程师也适合那些用了一两年电脑但从来没系统梳理过账号体系的人。1. 用户管理到底在管什么先搭一个清晰的认识框架1.1 账号、用户、主体这三个概念别搞混很多人一开始学 Windows 用户管理会被账号、用户、安全主体这几个词绕晕。这里我做一个最简单的类比账号是登录凭证用户是系统里代表你身份的对象安全主体是系统在做权限检查时真正识别的那一串唯一标识也就是 SID。同一个用户改用户名不会改变它的 SID所以文件权限依然有效但如果你把用户删了再重建一个同名用户对不起新用户的 SID 和旧用户完全不同之前分配给旧用户的文件权限、用户配置文件、证书乃至加密文件统统找不回来。这个认知特别重要。我遇到过不止一次有同事为了“清理无用账号”把某个用户的文件夹改了名或者在 AD 里直接删用户结果后续数据恢复和权限交接花了比新建用户多十倍的时间。我的原则很简单能用禁用/停用就不要删除用户必须要删除时先备份用户配置文件记录好 SID 和相关权限关系。只要理解了用户本质上是 SID 的映射绝大部分用户管理的问题都能想明白。1.2 本地用户、域用户、微软账号三种身份体系Windows 里的用户体系分三大类第一类是本地用户存储在单台机器的 SAM 数据库里只对本机生效第二类是域用户存储在 Active Directory 中可以实现全网统一认证第三类是微软在线账号用于个人设备登录 Windows 系统同时绑定云端服务。很多新手会混淆这三者尤其是配置共享文件夹时明明在本机建了用户另一台电脑访问却还是提示凭据不对就是因为访问方用的是域账号或者微软账号和你创建的本地用户根本不是一套认证源。工作场景中我的建议是能走域认证就走域认证工作站可以本地用户兜底家用娱乐设备用微软账号无所谓但生产服务器坚决不要使用微软在线账号登录。理由很简单本地用户适合单机管理域用户适合集中管控微软在线账号则不好审计、不易管理密码策略还会引入额外的网络依赖。把这三类用户的适用边界划清楚后面所有权限配置都不会跑偏。1.3 用户管理常见的五类业务场景总结下来用户管理基本逃不出五类场景一是账号全生命周期管理包括创建、密码设置、禁用、启用、删除二是密码与登录策略管理包括密码复杂度、有效期、锁定阈值三是组成员关系管理决定用户属于哪些权限组四是权限继承管理控制用户能访问哪些文件、执行哪些程序五是登录审计与安全事件追踪回答“谁在什么时候做了什么事情”。不同场景对应不同的工具和操作路径。例如账号生命周期管理用计算机管理或 PowerShell 就能搞定但审计追踪就可能需要开启安全日志并结合事件 ID 去分析。我每次给客户做 Windows 用户管理方案都会先画清楚这五个场景的责任矩阵否则做一半就变成了零散的救火。下文我就顺着这五个场景展开讲清楚每一步可以怎么做以及为什么要这么做。2. 图形界面操作从创建用户到设置策略2.1 创建本地用户的三种常用入口Windows 创建本地用户最直观的方式是“计算机管理”面板。右键“此电脑”选择“管理”展开“系统工具 - 本地用户和组 - 用户”在空白处点击“新用户”填上用户名、全名、描述以及初始密码勾选“用户下次登录时须更改密码”点击创建即可。这种方式适合一台一台手动创建胜在清晰直观每一步操作都有明确的提示。另一种方式是通过“设置 - 账户 - 家庭和其他用户”把新用户添加到这台电脑。这个入口在 Windows 10/11 上更贴近普通用户但它更适合创建“标准用户”若要精确控制“管理员”权限、设置密码永不过期还需要到“本地用户和组”或命令行里进一步调整所以我在生产环境里还是更推荐第一种入口。第三种方式是控制面板里的“用户账户”它适合家庭电脑快速建账户功能相对基础。我个人很少用因为它能设置的项目太少操作完还是要去系统深层设置里补策略。选择哪个入口不重要重要的是你要知道每个入口背后的元数据是一样的最终都殊途同归写入 SAM 数据库选工具的核心依据是是否需要批量操作、是否需要脚本可重复执行。2.2 密码策略和账户锁定策略设置密码策略是用户管理里最容易被忽视的一道关卡。很多人建完用户就不管密码策略了结果就是账号密码永远不过期、复杂度为零、登录失败也无任何锁定阈值这等于把大门钥匙挂在门口。正确的做法是先在“本地安全策略”里找到“账户策略 - 密码策略”配置密码长度最小值、密码复杂度要求、密码最短和最长使用期限。具体数值需要根据业务等级判断一般办公环境我建议密码最小长度至少 8 位最长使用期限 90 天面向外部网络的机器建议把密码长度提到 12 位以上并开启复杂度要求。账户锁定策略同样在“本地安全策略”中默认情况下 Windows 的账户锁定阈值为 0意思是永远不会锁定。对于暴露在公网的服务器这非常危险等于允许攻击者无限次暴力猜密码。我一般建议把“账户锁定阈值”设为 5 次“锁定时间”设为 30 分钟“重置账户锁定计数器”设为 30 分钟。这样既能阻止暴力破解又不会因为用户连续输错几次密码就导致永久锁死、管理成本飙升。不推荐把所有机器的锁定策略都配置成 5 次锁死。对于只做后台管理的跳板机锁定阈值可以放宽到 10 次因为内部员工偶尔手滑输错密码很常见对于 RDP 对外映射的业务服务器阈值则要严格毕竟它面对的威胁面更大。安全是平衡的艺术不是越严格越好。2.3 创建用户时那些容易被忽略的选项在“新用户”对话框里有几个选项值得留意。第一个是“用户下次登录时须更改密码”建议全新账号创建时勾选保证初始密码只有管理员知道、首次登录由用户自己修改第二个是“用户不能更改密码”适用于服务账号避免运维过程中密码被别人误改第三个是“密码永不过期”也常用于服务账号因为很多服务如果遇到密码过期会自动停止夜班被叫起来改密码的滋味谁经历谁知道。但我强烈建议服务账号的密码永不过期必须配合严格的管理措施比如周期手动轮换或引入密码管理平台否则等于留下一个长期有效的后门。创建用户时还要注意“隶属于”选项默认情况下新用户属于 Users 组也就是标准用户。如果你需要管理员权限可以在创建后把用户加入 Administrators 组但我还是建议按最小权限原则来不要随手把所有账号都加到管理员组。很多业务软件安装时会要求管理员权限装完以后权限就应该收回来长期保留高权限账号就是在给自己埋雷。3. 命令行和脚本化批量用户管理的高效姿势3.1 net user最基础的命令行用户管理命令当要管理的机器不止一两台时图形界面点来点去效率太低这时候就要上命令行。net user 是 Windows 自带的老牌命令功能虽然基础但极其实用。比如查看本机所有用户列表直接执行 net user查看某个用户的详细信息包括上次登录时间、密码有效期、用户组成员等执行 net user 用户名创建新用户的命令是 net user 用户名 密码 /add把用户加入管理员组的命令是 net localgroup administrators 用户名 /add。写过批处理的朋友一定用过这些命令但我见过很多人只知其一不知其二。例如 net user 设置密码策略时可以通过 /expires 参数指定账户过期时间这个在管理临时账号、外包账号时特别好用。我写过一个离职交接脚本用 net user 把临时账号的过期时间自动设置为项目结束日期到期后账号自动失效不会出现“人都走了三个月账号还能登录”的尴尬。还要提醒一句net user 创建的用户默认会被要求按照系统密码策略设置密码如果你给了太简单的密码命令会执行失败。所以用 net user 批量建号之前先确认本机密码策略不要等到脚本跑一半报错才回头查。3.2 PowerShell比 net user 更现代的用户管理方式Windows 10 和 Windows Server 2016 之后的系统PowerShell 已经成为管理主力用户管理也不例外。本地用户相关的模块主要在 Microsoft.PowerShell.LocalAccounts 中常用的命令包括# 查看所有本地用户 Get-LocalUser # 创建本地用户 New-LocalUser -Name zhangsan -FullName 张三 -Password (Read-Host -AsSecureString) # 禁用用户 Disable-LocalUser -Name zhangsan # 将用户加入管理员组 Add-LocalGroupMember -Group Administrators -Member zhangsan与 net user 相比PowerShell 的优势是结构化输出。比如 Get-LocalUser 输出的对象可以直接丢进 Excel 或者进一步筛选按 Enabled、LastLogon 等字段排序快速定位长期未登录的账号非常适合做账号清理。批量创建用户时我通常是准备一个 CSV 文件上面写好用户名、姓名、初始密码、组成员关系然后一行 Import-Csv 配合 ForEach-Object 循环完成全部创建整个操作可以重复执行也不会出错。PowerShell 脚本还有一个很大的好处就是可以把用户管理流程固化成标准操作文档。比如“每季度清理三个月内未登录的账号”手动操作很痛苦交给脚本去跑、生成报告既降低运维压力又减少人为失误。我自己维护了一套用户巡查脚本每周自动检查账号状态变化非常省心。3.3 批量导入导出用户和组关系的技巧如果你需要把一批用户从一台 Windows 迁移到另一台 Windows或是在新服务器上批量创建同样结构的本地账号只靠命令行一条条敲也不高效。我的做法是先用 PowerShell 导出当前的用户和组关系再在目标机器上导回。导出用户列表很简单Get-LocalUser | Select-Object Name, FullName, Enabled, LastLogon, PasswordExpires | Export-Csv -Path C:\users_backup.csv -NoTypeInformation -Encoding UTF8导出组成员关系需要遍历一下Get-LocalGroup | ForEach-Object { $group $_ Get-LocalGroupMember -Group $group.Name | ForEach-Object { [PSCustomObject]{ Group $group.Name Member $_.Name } } } | Export-Csv -Path C:\group_members.csv -NoTypeInformation -Encoding UTF8导入时要注意数据清洗先确认目标机器上没有同名用户再将 CSV 逐行读取创建用户。交叉操作时我非常强调先导出数据、再目标机重建、最后核对权限这一步顺序。因为用户迁移最大的风险不是账号创建失败而是账号创建成功后用户配置文件没有跟过去导致桌面、文档、环境变量全部丢失。所以迁移用户前先复制好用户配置文件目录再考虑用户账号的创建流程才算完整。3.4 脚本运行策略解决“闪退”和“权限不足”很多人在 Windows 上写 PowerShell 脚本会踩到两个坑第一个是脚本双击后闪退第二个是执行提示“禁止运行脚本”。闪退的原因通常是没有把执行策略设置为 RemoteSigned 或者脚本本身输出后窗口自动关闭。我的做法是不用双击运行而是在 PowerShell 窗口里用绝对路径调用脚本或者在脚本末尾加 Read-Host 让窗口停住便于看报错。权限不足的问题更常见。普通 PowerShell 窗口权限不够时即使你是管理员很多用户管理命令也会被拒绝。这其实是因为 UAC 用户账户控制导致的安全机制不是命令真的不能执行。解决方法是右键 PowerShell选择“以管理员身份运行”再执行命令。还不行的话可以检查一下当前用户是否真的在 Administrators 组里。我见过不少同事用 cmd 运行 PowerShell 脚本一旦遇到报错就去改脚本实际上问题是执行策略。这里给一个相对通用的初始化命令Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser这条命令允许运行本地脚本而对于从网络下载的脚本要求有数字签名兼顾了便利与安全。比直接改成 Unrestricted 安全得多不建议为图省事把执行策略完全放开。4. 权限模型建好用户后最重要的一件事4.1 本地组和内置组的权限矩阵用户建好后真正的重头戏是授权。Windows 的权限模型本质上是“用户 - 组 - 权限”三级结构直接给用户授权当然可以但管理起来非常痛苦。正确做法是把用户加入合适的组通过组权限来统一管理。Windows 内置了很多组例如 Administrators 组拥有系统最高权限Users 组是普通用户只能运行程序和管理个人文件Guests 组用于临时访问Remote Desktop Users 组允许用户通过 RDP 登录Backup Operators 组可以备份和还原文件绕开部分文件权限。还有一个容易被忽略的组是 Network Configuration Operators成员可以修改 TCP/IP 设置但不具备管理员权限。如果你有需求让某个同事负责调试网络参数又不想给他管理员权限加入这个组是合适的选择。权限分配的细节需要结合实际场景但核心原则始终是最小权限原则给用户够用的权限不添加多余授权。4.2 NTFS 权限和共享权限的叠加规则共享文件夹是 Windows 用户管理的高频场景但也是权限问题的高发区。很多人配置共享目录后发现另一方既能看到又不能访问或者能访问但无法写入原因通常是 NTFS 权限和共享权限的叠加结果混淆了。简单的叠加规则是最终有效权限是共享权限和 NTFS 权限的交集也就是取更严格的那个。举例来说如果共享权限设置为 Everyone 完全控制但 NTFS 权限只给某个用户读取权限那么用户最终得到的就只有读取权限反之如果共享权限只设了读取NTFS 权限给了完全控制最终也还是读取。所以在配置共享目录时我建议共享权限直接设为 Everyone 完全控制具体限制全部通过 NTFS 权限来控制这样逻辑统一、排查也容易不会出现两个体系互相打架的问题。另外要注意“继承”机制。在 NTFS 安全选项卡里默认子文件夹会继承父文件夹的权限这在多数情况下是方便的但在权限收敛时容易出问题。比如你给某用户设置了顶级目录“拒绝写入”该用户访问子目录时依然无法写入即使子目录里明明给了他“完全控制”。排查权限问题时先看清楚“高级安全设置”里的“禁用继承”和“启用继承”状态再判断到底是权限不够还是继承冲突导致的。4.3 服务账号和计划任务账号的授权差异除了人类用户Windows 上还有一类特殊的用户服务账号。服务账号通常需要以特定身份运行 Windows 服务或计划任务例如 SQL Server 服务、备份任务等。这类账号和普通用户最大的不同在于它往往需要“作为服务登录”权限并且不应该有交互式登录权限。为服务账号授权时很多人会在本地安全策略里直接赋予“作为服务登录”但更干净的做法是用组策略或服务管理器手动指定登录身份。在服务属性里选择“此账户”输入服务账号然后系统会自动为该账号分配“作为服务登录”的权限。这里要特别提醒服务账号建议设为密码永不过期并且定期通过统一入口修改密码修改后所有使用该账号的服务都要重新登录一次否则服务会因密码错误而崩溃。与普通用户相比服务账号还应该尽量避免加入管理员组。很多软件安装向导会建议你用管理员账号运行服务这是图省事的方案不推荐生产环境这样干。一台服务器上可以建立多个最小权限服务账号分别对应不同服务即使某个服务被攻破影响范围也被局限这是一种成本很低却非常有效的安全习惯。5. 安全日志和登录审计用户管理的最后一公里5.1 开启登录审核策略用户管理如果没有审计就像装了监控摄像头却不插电。Windows 的默认安全日志里其实会记录很多登录事件但默认不开启足够详细的审核策略。我们需要在“本地安全策略 - 本地策略 - 审核策略”中打开“审核登录事件”的“成功”和“失败”建议同时打开“审核账户登录事件”和“审核账户管理”。启用审核后系统会在安全日志里记录每次登录尝试、账号锁定、创建新用户、修改密码等关键操作。很多人会问这些日志存在哪里答案在“事件查看器 - Windows 日志 - 安全”。每次尝试登录都会生成 4624 成功登录事件或 4625 失败登录事件创建用户会生成 4720 事件删除用户是 4726 事件修改用户是 4738 事件重置密码是 4724 事件。把这些事件 ID 记熟你排查用户异常行为的效率会大幅提升。开启审核策略后安全日志会快速增长建议为大日志量做好规划。默认事件日志最大大小可能只有几十 MB在暴力破解或频繁登录时很快会被覆盖导致丢失关键证据。我会把安全日志最大大小调大比如 1 GB并设置“覆盖事件”策略避免日志占满磁盘导致系统严重卡顿或服务异常。具体的调法可以在“事件查看器”的日志属性里设置也可以用 wevtutil 命令配置。5.2 常见安全日志事件 ID 速查4624登录成功。这个事件会记录登录类型、账户名、源 IP是分析远程访问的核心数据。4625登录失败。包含失败原因、错误代码、账户名、源 IP暴力破解的典型特征都在这。4634登录会话被注销。4720创建用户账户谁创建了用户、创建了什么用户一目了然。4724尝试重置密码。需要关注发起者是不是管理员账号防止内鬼操作。4726删除用户账户。4738用户账户被修改比如更改组关系、账户到期时间等。4740账户被锁定通常与密码尝试次数超限有关。4768Kerberos 身份验证票据请求域环境里更常见。这些事件 ID 可以在 Windows 官方文档或事件目录网站查到记住常见几个就够用了。我排查暴力破解时最常用的组合是 4625 加 4624先用 4625 确认有没有大量来源 IP 的失败登录再检查 4624 是否出现了来自同一 IP 的成功登录一旦出现就说明密码已经被猜中必须立刻重置账号密码并封禁来源 IP。5.3 快速揪出暴力破解和异常登录的方法在实际运维中服务器被暴力破解是很常见的事情。Windows 安全日志能不能用关键在于你会不会筛选。我最常用的方法是打开 PowerShell用 Get-WinEvent 筛选安全日志中的 4625 事件按时间分组查看来源 IP 和登录次数Get-WinEvent -FilterHashtable {LogNameSecurity; ID4625} | Select-Object TimeCreated, {nAccount;e{$_.Properties[5].Value}}, {nSourceIP;e{$_.Properties[18].Value}} | Group-Object SourceIP | Sort-Object Count -Descending | Select-Object -First 10 Count, Name其中属性索引位置在不同 Windows 版本中可能会偏移实际使用时要先打印一条事件的 Message 确认位置。这个脚本能快速列出哪个 IP 在反复尝试登录也就能针对性地配置防火墙策略或 IP 阻止规则。除了即时排查我还会在关键服务器上做每周一次的登录审计报告重点检查是否有非工作时间登录、是否存在同一个账户从多台机器同时登录、是否有新建的账号关联到异常事件。这些审计工作并不复杂贵在坚持这也是用户管理从“能用”走向“可靠”的关键一步。6. 常见问题速查这些坑我都替你踩过6.1 用户被锁定到底是该等还是该手动解锁Windows 账户被锁定是高频问题。如果配置了账户锁定阈值连续输错密码就会锁定用户。看到用户报“账户已被锁定”我一般先查安全日志 4740 事件确认锁定的触发源和触发次数。有时候并非真的有人在攻击只是用户在手机、电脑、远程桌面等多端同时登录把旧密码输错了几次系统就会误判。处理方式分两种如果是临时误锁且你确认账号没有被暴力破解直接用管理员身份执行 net user 用户名 /active:yes 可以结束锁定状态这个命令本质是“激活用户”但可以用来解除账户锁定如果确认存在暴力破解建议先保持锁定状态排查来源 IP再重置密码最后才解锁。这里补充一点容易被忽视的知识Windows 的“账户锁定阈值”重置计数器默认从第一次失败开始计时所以偶尔输错一次密码不会立即锁定这与 Linux 里的 pam_faillock 行为类似。理解了这一点就不会频繁收到“为什么才输错三次就锁死”的疑问了。6.2 删除用户后残留的用户配置文件删除用户是高风险操作但很多管理员图省事直接右键删除用户。删除后你会发现在 C 盘用户文件夹下还留着这个用户的目录里面包含桌面文件、文档、收藏夹、IE 缓存等。这个残留目录不会自动清除时间长了会占用磁盘空间也可能暴露敏感数据。正确做法是删除用户之前先压缩并备份用户配置文件目录确认不再需要后再手动删除残留文件夹。但注意即使手动删除注册表里 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList 下的用户 Profile 信息仍可能存在需要一并清理否则下次创建同名用户时会报“配置文件找不到”的错。在域环境里删除用户还要考虑漫游配置文件。如果你只删了 AD 账号没处理文件服务器上的用户共享目录就相当于删了“门禁”但没拆“房间”数据依然存在、权限可能错乱。所以我的原则一直是先交接数据再删除账号最后处理残留配置顺序对了后面基本不会出大问题。6.3 同名用户重建后权限全部丢失前面提到过 SID 的问题这里再展开讲一个非常经典的故障某员工离职管理员把他的账号和用户文件夹全部删除三个月后公司又招了一个同名同姓的新员工管理员直接新建了一个同名用户。结果新员工发现无法访问原来同事留下来的项目文件即使管理员认为“同名用户当然能有同样权限”。原因就是 SID 变了。Windows 权限列表里存储的是旧用户的 SID而不是用户名。新建用户时系统会生成一个新的 SIDWindows 不会因为用户名相同就匹配旧权限。解决办法有两种一是恢复旧 SID操作复杂且不建议二是在创建用户后把新用户的 SID 添加到旧文件路径的明文权限里把文件归属权重新授予新用户。实操上我会在交接项目文件时先将文件的所有者改为某个长期稳定账号比如部门主管账号再对新员工临时授权这样就不会丢失所有权。避免同名用户权限问题最有效的办法是用户账号作为资产也纳入资产管理流程不随意删除而是禁用、归档直到数据完全清洗后再删除。这也是为什么很多正规企业要求用户账号保留至少六个月再清理的原因。6.4 已禁用的管理员账号为什么还能远程登录还有一种容易让人困惑的现象明明在“本地用户和组”里禁用了某个管理员账号但对方还能通过远程桌面登录。这类问题通常出现在打开了系统内置 administrator 账号的情况下系统内置 Administrator 账号即使显示“禁用”某些场景下仍然可以用于紧急恢复登录尤其是在安全模式下或者 network 登录模式下。另一个可能性是对方使用的不是被禁用的那个本地账号而是域账号或其他本地管理员组账号。排查时不能只看账号本身的启用状态要看它属于哪些组以及 RDP 登录用户列表里是否仍然包含这个账号。比较好的做法是用“本地安全策略 - 用户权限分配”里查找“允许通过远程桌面服务登录”把不必要的账号全部移除只保留明确的远程维护账号这样无论账号是否禁用未授权账号都无法远程登录。我见过的多数 RDP 暴力破解攻击利用的都是常驻管理员组和未授权的远程桌面用户策略。把这两个入口卡住Windows 用户管理的安全水位至少能提升 40%这是几千块钱的安全设备未必能换来效果的地方。6.5 用户管理和 Windows 安全日志相结合的建议每次事故分析安全日志都是第一手的“黑匣子”。用户管理和安全日志从来都是两条平行线但在实际故障和攻击调查中它们必须交汇在一起看。单独看用户是否被创建、单独看登录是否成功都只是局部信息把用户管理事件和登录事件串联起来才能还原完整时间线。我会在关键服务器上做一套简单的日志留痕方案安全日志至少保留 90 天日志大小提前调大每周自动备份安全日志到单独的归档目录配置事件转发把安全日志实时送到日志中心或另一台机器防止攻击者清理本机日志后线索全断。日志方案不需要很贵靠谱的运维习惯才是重点。没有审计的用户管理就像没有回声的射击场你不知道自己开了多少枪也不知道中了多少弹。这也是为什么我把安全日志放在用户管理的核心章节里讲真心建议读者把它当做一个必选项而不是可选项。7. 几个从实战中沉淀下来的用户管理习惯最后分享几条我这些年总结出来的实操习惯每一条都是踩过坑之后的教训。第一账号必须有负责人。不管是本地账号还是域账号创建时都要记录申请人和负责人方便后续追踪没有负责人的账号最好定期清理。第二管理员账号必须改名或禁用默认 Administrator并配置独立的强密码管理流程避免所有管理员共用一个账号。第三每次用户权限变更都要有记录哪怕是临时的授权也要落在变更单里防止“临时授权到期不收回”变成长期安全隐患。第四不要在生产服务器上贪图方便关闭 UAC 或者全部使用管理员账号运行日常应用。UAC 是挡不住真正黑客的但能拦住大部分误操作和自动化脚本的误执行保留它是划算的。第五账号清理要养成固定周期的节奏建议每个季度做一次账号巡检把长期未登录的、权限异常的、状态篡改的账号全部拉出来过一遍。巡检不是走形式最好输出一份报告里面包含账号数量、管理员组成员、最近登录时间、下次密码过期时间四大类数据这样每一次巡检都有纵向对比账号体系的变化就藏不住了。Windows 用户管理远不止“新建用户”一个界面那点事情它本质上是一种账号生命周期管理、权限控制和审计追踪的综合实践。把前面的原理、命令、权限模型、日志分析串联起来你会发现管理一台 Windows 其实也可以很从容。下次再有人问“为什么删了用户权限还是没干净”你可以从 SID 讲起这就是这篇文章存在的意义。