Windows 10 1803安全基线加固：从账户策略到PowerShell核查脚本

简介：面向企业IT运维、安全管理员及等保测评人员，针对Windows 10 1803版本整理的安全基线资源，基于微软官方Security Baseline调整，可解决系统安全配置分散、合规审计缺乏统一标准等问题，适合新装系统批量加固、存量系统合规整改、日常基线巡检等场景。压缩包共72个文件，约1.06MB，主要包含xml策略规则、admx/adml组策略管理模板、pol安全策略配置、cmd客户端部署脚本、htm合规报告和xlsx说明文档；其中GPOs目录存放可直接导入的组策略对象，Templates提供策略模板，Documentation附有RS3到RS4的差异对比表，便于理解1803基线变化；xml定义具体检查规则，pol用于策略导入，cmd可辅助自动化部署。目前已有1613人学习。借助该包，读者可快速导入GPO模板、运行本地脚本批量下发安全基线，并生成合规核查报告，相比手工逐项配置，能显著降低基线落地成本、提升审计效率，并为后续Windows版本的安全基线学习提供参考。

1. 为什么是1803：这个版本的安全基线还值不值得做

接手一批预装 Windows 10 专业版 1803 的存量机器时，第一件事通常不是急着装杀毒软件，而是先回答一个问题：这台机器的安全底线在哪里。所谓安全基线，就是把底线写成一组可执行的配置——密码多久换一次、谁允许本地登录、SMB1 是否禁用、安全日志记到多细、远程桌面要不要开。1803 虽然早已停止官方支持，但工控、教学机房和不少内网办公区仍大量跑着这个版本；与其争论该不该升级，不如先把不随版本变化的账户、审核和边界策略补齐。

这篇文章适合三类人：刚接手一批 1803 设备的运维，要做等保或内部合规检查的安全工程师，以及想把自己手头的 Windows 10 加固到可对外交代状态的个人用户。下面内容按「装系统阶段 → 账户与审计策略 → 常见翻车现场 → 脚本化核查」的顺序展开，参数尽量写具体，方便你直接抄。

2. 系统与账户基线：从装完系统到锁定登录入口

安全基线不是装了杀毒软件就算完成，真正的分水岭在系统安装阶段和账户策略上。1803 的很多安全项在装系统那一刻就已经被决定，比如引导方式、磁盘加密前提、本地账户和微软账户的选择，这些后面再改代价极高。所以先讲安装阶段要盯住的三个点，再讲账户策略和用户权限分配。

2.1 安装阶段就要决定的三个选项：UEFI、TPM 与本地账户

第一个选项是引导方式。1803 支持 UEFI 安全启动（Secure Boot），装系统时选 UEFI 而不是传统 Legacy 引导，可以让引导链被签名机制锁定，防止引导扇区被改写。UEFI 和 Secure Boot 不是装完系统后能简单切换的，必须在安装介质启动前就进 BIOS 改好。老机型上如果硬盘是 MBR 分区且已经装过系统，从 Legacy 转到 UEFI 需要全盘重分 GPT，这意味着重装系统是唯一可靠路径。

第二个选项是 TPM。1803 对应的是 TPM 2.0 逐步普及的阶段，BitLocker 全盘加密依赖 TPM 芯片做密钥保护。安装前先在 BIOS 里确认 TPM 开启状态，装完系统后用下面命令验证：

Get-Tpm | Select-Object TpmPresent, TpmReady

如果两个字段都是 True，说明 TPM 可用且已就绪，后面可以直接开 BitLocker；如果 TpmReady 为 False，一般是需要初始化或清除 TPM 所有者授权。对基线来说，TPM 不可用的机器应打上标记，别盲开 BitLocker，否则下次开机可能直接进恢复界面。

第三个选项是本地账户。1803 专业版安装时选择「脱机账户」或跳过网络连接，可以避免把本地密码同步到微软账户云端。基线场景里我不建议用微软账户，因为密码策略、PIN 码和双重验证都受云端账户策略影响，存在本地策略之外的黑匣子。装完系统后再执行下面的检查，确认当前登录用户类型：

whoami /user net localgroup administrators

通俗解释：whoami /user看当前用户 SID，确认不是MicrosoftAccount开头；net localgroup administrators看管理员组里有没有微软账户残留。如果出现微软账户，最好删掉并重建一个纯本地管理员，否则后续密码策略会出现一套本地、一套云端的割裂状态。

2.2 账户策略：密码长度、锁定阈值与内置 Administrator

账户策略属于基线里最容易被忽略但最容易被攻击者利用的部分。1803 的本地安全策略编辑器（secpol.msc）里，账户策略分为密码策略和账户锁定策略两组。下表是业界常见基线推荐值，也是我一般在独立部署时使用的参数：

设置完这些策略后，可以用一条命令确认有效值：

net accounts

net accounts输出里的每一项对应表格里的值，重点看「锁定阈值」和「锁定持续时间」。注意一点：在域环境里，本机的 secpol 账户策略会被域策略覆盖，所以域内机器不需要在本机设置这两组策略，直接在域控的 Default Domain Policy 里配，否则会出现「本机配了 14 位密码，实际密码还是 6 位就通过」的翻车现象。

内置 Administrator 账号也要处理。常规做法是先把内置 Administrator 改名，再禁用：

wmic useraccount where name='Administrator' rename AdminCareful net user Administrator /active:no

第二条命令里的/active:no是禁用，而不是删除，删除内置管理员后续域策略下发会报错。禁用前务必确认 Administrators 组里已有一个能用的普通管理员账户，否则重启后你连门都进不去——这是最经典的自我锁死方式。

2.3 用户权限分配：谁能登录这台机器

用户权限分配在 secpol.msc 的「本地策略 → 用户权限分配」里，基线要调整的核心就三类：本地登录、网络登录、远程桌面登录。默认情况下，Users 组有本地登录权限，这没问题；但网络登录权限里通常包含 Everyone 和 Guests，这在 1803 默认开启来宾模型下是一个隐患。

我一般会做两个收紧动作：第一个是把「拒绝从网络访问此计算机」里加入 Everyone 和 Guests，阻断空密码来宾从网络访问；第二个是把「拒绝本地登录」里加入 Guest，防止来宾账户从控制台进入。

改完权限分配后，做本地共享访问验证要特别注意：如果你在 2.2 里已经禁用了 Guest，同时又在「拒绝从网络访问」里加了 Everyone，那这台机器的所有网络共享都会变成不可访问状态。这不是配置错误，而是预期内的收紧结果；若业务确实需要共享，就要在共享文件夹的 NTFS 权限里显式添加具体账号，而不是依赖 Everyone。

3. 安全选项与审核策略：把组策略里的关键开关讲透

账户策略管的是人的入口，安全选项和审核策略管的是协议、登录行为和审计数据。1803 在这两层里能调的开关非常多，但真正值得写进基线的就两类：一是不带来明显业务副作用的安全开关，二是能让你在出事时看得见痕迹的审计项。这一章把两组策略拆开讲，参数直接给出推荐值。

3.1 安全选项里最值得动的 8 个开关

安全选项在 secpol.msc 的「本地策略 → 安全选项」下，170 多项里只有少数对普通企业环境有意义。以下是 1803 基线里我保留的 8 个核心配置，每一项都有明确目的，且不容易误伤业务：

其中「LAN Manager 身份验证级别」对应的注册表值是LmCompatibilityLevel，在命令行的核查方式是：

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel

值为5时表示仅发送 NTLMv2，拒绝 LM 和 NTLM；低于3意味着还有旧协议在走，等于给攻击者留了破解后门。要注意，把这项直接调到 5 会影响到老版本的 XP、Windows Server 2003 客户端访问共享，公司里如果还有这种老机器，需要单独给他们开一台低等级协议的跳板机。

「不显示上次用户名」对应注册表值DontDisplayLastUserName，为 1 即启用。这两个注册表路径是后续脚本化核查的重点，建议抄进你的参数备忘里。

3.2 审核策略：用 auditpol 开启关键子类别

1803 的审核策略在 secpol.msc 里有「本地策略 → 审核策略」和「高级审核策略配置」两套入口，两者混用会互相覆盖。业界通用的做法是只用高级审核策略，因为它的子类别粒度更细，能精确到登录、进程创建和对象访问。我一般打开以下五个子类别：

直接在命令行开启的方式是使用 auditpol：

auditpol /set /subcategory:"登录/注销" /success:enable /failure:enable auditpol /set /subcategory:"账户登录" /success:enable /failure:enable auditpol /set /subcategory:"账户管理" /success:enable /failure:enable auditpol /set /subcategory:"进程创建" /success:enable /failure:disable auditpol /set /subcategory:"对象访问" /success:disable /failure:enable

参数说明：/success:enable记录成功的访问，/failure:enable记录失败尝试；进程创建只开成功，因为失败进程通常由对象的失败事件覆盖；对象访问必须只开失败，否则全盘扫描会造成每秒上千条事件，直接把日志塞爆。

auditpol 的子类别名称是跟着系统语言走的，中文系统用中文名，英文系统用英文名。如果你不确定当前语言环境下的准确名称，直接auditpol /list /subcategory:*查一遍，别硬背命令，否则会报「指定的子类别不存在」。

开好审核后顺手调整安全日志大小，默认的几十 MB 在 1803 上撑不过一天：

wevtutil set-log Security /ms:209715200 /rt:true /ab:true

参数含义：/ms:209715200表示把安全日志上限设为 200MB，/rt:true启用日志自动保留（满时按时间顺序清理），/ab:true启用自动备份，防止日志满后被覆盖。如果机器是全职域控或财务服务器，建议直接调到 500MB，宁可多占点磁盘，别在出事时发现关键事件没了。

3.3 远程桌面、SMB 与防火墙：把入口守住的边界策略

远程桌面是 1803 环境里最常见的攻击入口之一。基线首要是确认 NLA（网络级别身份验证）已启用，没有 NLA 的 RDP 会允许在未认证前加载登录界面，耗尽资源且容易被暴力破解。核查方式：

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name UserAuthentication

值为1表示已启用 NLA。如果业务不需要远程桌面，干脆直接停掉服务：

Set-Service TermService -StartupType Disabled -Status Stopped

注意：停服务只是把入口关了，防火墙规则还在；稳妥做法是同时在 Windows 防火墙里把「远程桌面」入站规则禁用，双保险。

SMB 协议方面，1803 默认已不安装 SMB1，但有些 OEM 镜像或升级上来的系统里 SMB1 协议栈仍残留着。核查命令：

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol

如果返回True，立即关闭：

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

SMB1 关闭后要验证打印机和文件共享是否正常——这是坑最多的地方，下面第 4 章专门展开。防火墙侧，基线要求入站默认阻断，只开放明确需要的端口。1803 的 Windows 防火墙默认就是阻断入站，但「文件和打印机共享」相关入站规则（135、137-139、445）默认启用，若是纯办公或开发机器，把这一组入站规则禁用能省掉大量被扫描面。

4. 踩坑记录：1803 基线落地时最常翻车的 4 个地方

1803 的基线配置看起来都是开关项，真到批量下发时总有几个雷是反复踩的。下面四条来自实际部署场景，每条按「现象 → 原因 → 解决」写，希望能帮你绕开我掉过的坑。

4.1 改了密码策略后把本地管理员锁在门外

现象：在 secpol 里把密码复杂度和锁定阈值设好，重启后本地管理员登录一直提示密码错误，最后账户被锁定。

原因：有三个动作叠加出错。一是按 2.2 禁用内置 Administrator 时，忘了确认 Administrators 组里还有第二个可用账号；二是把密码策略设严后，现有管理员密码长度不满足新策略，系统在后台已经标记该密码失效；三是连续输错几次密码触发了锁定阈值。

解决：先把新策略逐项加，不要一次性全改。最安全的顺序是：第一步新建一个独立本地管理员并加入 Administrators 组；第二步改密码策略；第三步用新管理员登录，验证密码复杂度满足要求；最后一步才禁用内置 Administrator。如果已经锁死，只能 PE 启动后用工具重置密码或挂载注册表蜂巢改掉锁定阈值，过程耗时且容易损坏系统，不如提前按顺序操作。

4.2 文件共享和打印机静默失效

现象：基线配完后，共享文件夹能 ping 通、能看到服务器名，但双击提示没有访问权限；老打印机挂载失败，驱动安装中途报错。

原因：这一步通常是三个收紧动作叠加导致：禁用了 Guest、在「拒绝从网络访问此计算机」里加了 Everyone、把 LAN Manager 身份验证级别升到 NTLMv2-only。老打印机和部分低端 NAS 走的是 SMB1 协议栈或空密码来宾会话，三条全断后自然连不上。

解决：第一步确认设备是否支持 SMB2，2009 年以后发布的固件基本都支持，在打印机面板或厂商文档里确认；第二步把 SMB1 依赖设备单独放进一个隔离网段，用一台保留低等级协议的旧机器做打印代理，而不是放开全局 SMB1；第三步为共享文件夹创建显式访问账号，替代 Everyone 和 Guest。总的来说，SMB1 不回退，用代理机解决兼容，才是一个可交付的基线。

4.3 安全日志被撑爆，登录事件反而看不到

现象：开完高级审核后，安全日志在半天内写满，系统开始变卡，需要登录的事件 4624 却查不到几条。

原因：开了对象访问的成功 + 失败审核，并且没设日志上限。对象访问成功事件在系统运行时会疯狂产生——每次读注册表、读写文件都会触发，量级远超登录事件。日志一满，默认策略下系统直接丢弃新事件，关键登录记录反而最先被挤掉。

解决：撤销对象访问的成功审核，只保留失败；把安全日志上限从默认调到 200MB 以上；再开启自动备份，让满日志时自动归档而不是丢弃。调整完的命令行回滚：

auditpol /set /subcategory:"对象访问" /success:disable /failure:enable wevtutil set-log Security /ms:524288000 /rt:true /ab:true

参数说明：第二行直接把日志上限提到 500MB，适合事务型服务器；日常办公机 200MB 足够，别一刀切都设 500MB。

4.4 实时保护与兼容性：关不关都有问题

现象：按教程关闭 Windows Defender 实时保护后，系统频繁提示安全服务已关闭，部分组件更新失败；不关则老业务软件被误报，安装过程直接被隔离。

原因：1803 上 Defender 的篡改保护（Tamper Protection）和组策略优先级的博弈，让手动改注册表、界面开关都可能在几分钟内被还原；同时部分老软件确实依赖未签名启动驱动，Defender 实时扫描会拦截加载。

解决：如果必须关，用组策略的「关闭 Microsoft Defender 防病毒」策略项，而不是到界面里手动点实时保护开关——组策略配置优先级更高，不会被篡改保护回滚。同时给 Defender 配置排除路径：老软件安装目录、数据库文件目录、更新临时目录，这样既保留防护能力又解决误报。到 2024 年再看这类存量机器，最干净的解法是直接升级到 22H2 并开启智能应用控制，1803 的 Defender 组件太老，所有绕行方案都是补丁式的。若决定升级，务必先做好应用兼容性测试，别为了关 Defender 把一个正在跑生产的系统搞挂。

5. 用 PowerShell 核查 1803 基线：脚本、导表与重装恢复

基线不是一次性动作，重装系统、换硬件、域策略调整都会把它冲掉。我的习惯是每台机器加固完就跑一遍核查脚本，把结果导出留档，之后每周和最新基线模板对比一次。下面这条思路可以直接抄。

首先用一个简单的 PowerShell 函数，把基线核查做成「期望值对比」：

function Test-BaselineItem { param( [string]$Path, [string]$Name, [int]$Expected ) $item = Get-ItemProperty -Path $Path -Name $Name -ErrorAction SilentlyContinue $actual = $item.$Name if ($null -eq $actual) { return "FAIL: 策略项不存在" } if ($actual -eq $Expected) { return "PASS" } return "FAIL: 当前值 $actual，期望值 $Expected" }

调用示例：

Test-BaselineItem -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "DontDisplayLastUserName" -Expected 1

逻辑说明：Get-ItemProperty读注册表策略值，-ErrorAction SilentlyContinue避免策略项不存在时直接抛错中断脚本；返回值统一为字符串。你可以把第 3 章所有注册表项全部塞进这个函数，写成一个 CSV 参数表批量跑，结果就是一台机器的合规报告。

注册表路径里也有坑：DontDisplayLastUserName的值是 DWORD 类型，PowerShell 读出来是整型，所以-Expected 1没问题；但有些策略项如LmCompatibilityLevel默认值可能是 0，如果你的基线里该项是未配置状态，也会被判定为 FAIL。这是好事，基线就是要暴露「未配置」和「配置错误」。

第二步是把当前安全策略整体导出，与基线模板比对：

secedit /export /cfg C:\baseline\current.inf /areas SECURITYPOLICY secedit /configure /db C:\baseline\1803.sdb /cfg C:\baseline\1803.inf /areas SECURITYPOLICY /log C:\baseline\apply.log

/export导出的 current.inf 是文本文件，重点看[System Access]（密码与锁定策略）和[Event Audit]（审核策略）两段，直接用文本对比工具和基线模板 diff。/configure是把基线的 inf 应用回机器，/db指定临时数据库文件，/log记录应用过程，若某条配置应用失败，行号会直接写在日志里。

secedit 覆盖不了全部基线项，注册表和用户权限分配之外的安全选项还是得靠 PowerShell 脚本逐一核查。重装系统时我一般按这个顺序：先装系统并更新到当前补丁 → 跑一遍基线加固脚本 → 验证管理员账户可登录且密码策略生效 → 再装业务软件。顺序反了，基线会被业务软件的安全组件或优化工具覆盖掉，后补策略又容易和业务冲突。别问怎么知道的，我吃过的亏都写在前面几章里了。

希望帮到你。这套方法不只在 1803 上用，等哪天真把环境升到 22H2，把版本相关的注册表路径改掉，核查脚本照样能跑，到时候你只需要替换参数表，不用改框架。

本文还有配套的精品资源，点击获取