企业官网建设流程全解析

简介：面向工业自动化运维人员与OPC Classic应用开发者的技术资料，聚焦微软KB5004442安全更新对Windows DCOM机制的影响，帮助读者理解CVE-2021-26414修补后OPC通信可能中断的原因与应对思路。资源包共1个PDF文件，约398KB，内容围绕DCOM安全更新概述、对OPC客户端与服务器的影响、微软分阶段启用时间表及注册表缓解措施展开，并附受影响Windows版本清单与测试步骤说明。已有461人学习下载，适合需要评估升级风险、排查连接故障或规划迁移至OPC UA的工程师参考，可据此对照自身系统版本与应用程序身份验证设置，提前验证数据包完整性级别配置，减少因安全功能强制启用导致的远程连接失败。

1. 一次远程 OPC 连接断掉，把我拉回 KB5004442 这个补丁

去年给一套老产线做远程数据采集，客户端在办公网、OPC Classic 服务器在车间机柜里，中间隔着两层交换机。白天还好好的，晚上重启了一次采集机，第二天早上所有点位全红，日志里只有一句“拒绝访问”。查了半天网络、账号、防火墙，最后在系统日志里翻到事件 ID 10036，才想起这台机器上个月刚打过 KB5004442 相关的累积更新。这个补丁不是装完就完事的类型，它改的是 Windows DCOM 的激活身份验证级别，而 OPC Classic 客户端和服务器之间恰恰全靠 DCOM 通信。装不好、配不对，表现就是连接时好时坏，或者干脆连不上，而且报错信息完全不指向补丁本身。这篇笔记按我实际处理的顺序写：先确认系统版本和补丁状态，再讲注册表开关怎么配、DCOMCNFG 里身份验证级别怎么改，然后是验证连接和看事件日志的方法，最后是几个我踩过的坑。适合还在维护 OPC Classic 通信、又不得不跟着 Windows 更新走的运维和现场工程师。

2. 装前先摸清环境：Windows 版本、补丁与 DCOM 现状

2.1 确认受影响的 Windows 版本和补丁落地情况

KB5004442 覆盖的版本比想象中宽，从 Windows 7 SP1、Windows 8.1 一直到 Windows 10 各版本、Windows Server 2008 R2 SP2 到 Server 2019，都在影响范围内。我一般先在两台机器上各跑一遍版本查询，客户端和服务器都要看，因为问题往往出在客户端调用的身份验证级别上，而不是服务器端。

# 查看系统版本和内部版本号，确认是否在受影响列表内 systeminfo | findstr /B /C:"OS Name" /C:"OS Version" # 查看已安装的累积更新，确认 KB5004442 相关补丁是否已落地 wmic qfe list brief | findstr /I "KB500"

第一条命令给出 OS 名称和版本号，比如 Windows Server 2016 对应内部版本 14393，Windows 10 20H2 对应 19042。第二条命令列出已安装补丁，重点看 KB5005101、KB5005102、KB5005103、KB5005573、KB5005619、KB5006714 这几个编号，它们分别是不同 Windows 版本上带出 DCOM 错误事件和强化逻辑的更新。如果客户端机器上这些补丁已经装了，但事件日志里还没有 10036/10037/10038，说明强化功能可能还处于默认禁用状态，这时候连接正常不代表以后正常。

提示：不要只看一台机器。OPC Classic 是客户端发起激活请求，客户端不调用 CoInitializeSecurity 时走的是系统默认 DCOM 设置，所以客户端的默认身份验证级别才是关键。

2.2 用 DCOMCNFG 看当前默认身份验证级别

图形界面里看 DCOM 默认设置，路径是组件服务 → 计算机 → 我的电脑 → 右键属性 → 默认属性。这里有一个“默认身份验证级别”下拉框，默认值通常是“连接”。KB5004442 强化启用后，DCOM 服务器要求激活请求至少达到“数据包完整性”，也就是 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY，对应数值 5。如果这里还是“连接”，而客户端又没有自己调 CoInitializeSecurity 把级别提上去，远程激活就会被服务器拒绝。

我习惯先用注册表确认当前实际生效的值，因为图形界面有时候显示和注册表不一致，尤其是被组策略改过之后。

# 查看 DCOM 默认身份验证级别，1=无 2=连接 3=调用 4=数据包 5=数据包完整性 6=数据包隐私 reg query "HKLM\SOFTWARE\Microsoft\Ole" /v LegacyAuthenticationLevel

如果这条命令返回“系统找不到指定的注册表项或值”，说明没有显式设置，走的是系统默认。这时候不要急着加值，先按下一节把测试开关打开，观察事件日志，再决定是改默认级别还是改单个 OPC 服务器对象的自定义权限。

2.3 确认 OPC 服务器对象的自定义 DCOM 权限

服务器端每个 OPC Server 的 CLSID 在注册表里都有独立配置，路径在 HKLM\SOFTWARE\Classes\AppID 下。现场常见做法是直接在 DCOMCNFG 里展开“组件服务 → 计算机 → 我的电脑 → DCOM 配置”，找到对应的 OPC 服务器项，右键属性 → 安全，看“启动和激活权限”是默认还是自定义。如果这里是自定义，那么 KB5004442 强化启用后，激活请求的身份验证级别要求会叠加在这套自定义权限上，改默认属性不一定能覆盖到。

我一般会先把服务器对象的自定义权限截图存档，再动任何配置。因为一旦改乱，回滚时至少有个对照。这一步不产生命令输出，但决定了后面测试时是改全局还是改单个对象。

3. 配置 DCOM 安全强化：注册表开关与身份验证级别

3.1 注册表开关的位置、类型和取值

KB5004442 的强化功能由一个注册表值控制，位置和写法都比较固定，但有几个细节容易写错。

# 打开强化测试开关：RequireIntegrityActivationAuthenticationLevel = 1 reg add "HKLM\SOFTWARE\Microsoft\Ole\AppCompat" /v RequireIntegrityActivationAuthenticationLevel /t REG_DWORD /d 0x00000001 /f # 关闭强化（仅限 2023 年 3 月 14 日之前的补丁阶段可用） reg add "HKLM\SOFTWARE\Microsoft\Ole\AppCompat" /v RequireIntegrityActivationAuthenticationLevel /t REG_DWORD /d 0x00000000 /f

路径是 HKLM\SOFTWARE\Microsoft\Ole\AppCompat，值名 RequireIntegrityActivationAuthenticationLevel，类型 REG_DWORD。0x00000000 表示禁用，0x00000001 表示启用，值不存在时默认按禁用处理。这里有两个参数取舍要说清楚：第一，数据必须以十六进制格式写入，虽然 reg add 的 /d 参数对 1 和 0x1 都能接受，但现场交接文档里统一写十六进制，避免别人照着十进制改出歧义；第二，改完必须重启设备才生效，不是重启 OPC 服务就行，因为 DCOM 的激活策略在系统启动阶段加载。

注意：2023 年 3 月 14 日之后的累积更新里，这个开关不再允许关闭。也就是说，如果现场还停留在能关的阶段，关掉只是争取时间，不是解决方案。

3.2 把默认身份验证级别提到数据包完整性

测试阶段我一般分两步走：先开注册表开关，再把默认身份验证级别改成“数据包完整性”，观察哪些客户端断、哪些不断。改默认级别可以直接写注册表，也可以用 DCOMCNFG 图形界面，两者等价。

# 将 DCOM 默认身份验证级别设为数据包完整性（5） reg add "HKLM\SOFTWARE\Microsoft\Ole" /v LegacyAuthenticationLevel /t REG_DWORD /d 0x00000005 /f

LegacyAuthenticationLevel 的取值含义：1 是无，2 是连接，3 是调用，4 是数据包，5 是数据包完整性，6 是数据包隐私。设成 5 之后，所有没有显式调用 CoInitializeSecurity 的客户端都会以数据包完整性级别发起激活。这一步的风险在于，如果某个老客户端根本不支持这个级别，它会直接连不上，而不是降级重试。所以我在生产环境改这个值之前，一定先在非生产系统上按同样的顺序走一遍，并且把事件日志开到实时刷新。

3.3 单个 OPC 服务器对象的自定义权限怎么调

如果不想全局改默认级别，可以只针对某个 OPC 服务器对象改自定义权限。DCOMCNFG 里找到该对象，属性 → 安全 → 启动和激活权限选“自定义”，编辑里给相应用户或组勾上“本地启动”“远程启动”“本地激活”“远程激活”。这套权限本身不直接设置身份验证级别，但它决定了谁能在什么范围内发起激活，配合全局的数据包完整性要求一起生效。

我遇到过一次，全局默认级别已经改成 5，但某个 OPC 服务器对象之前被设过自定义权限，里面只给了“本地启动”，远程客户端一直报 10036。把自定义权限改成默认，或者补上远程激活权限，连接才恢复。所以改完全局之后，一定要把现场所有 OPC 服务器对象的自定义权限过一遍，不能只看默认属性。

4. 验证与排查：事件日志、连接测试和常见坑

4.1 用事件 ID 10036/10037/10038 定位问题端

强化启用后，系统日志里会出现三类新事件，分别对应服务器端拒绝、客户端显式设置低级别、客户端走默认低级别。我排查时先看服务器端 10036，它直接告诉你哪个用户、哪个 SID、从哪个 IP 发起的激活被拒，以及要求的最低级别是 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY。然后到对应客户端上看 10037 或 10038，10037 表示应用程序显式把身份验证级别设低了，10038 表示应用程序走的是默认激活级别且低于要求。

# 在服务器端筛选 DCOM 相关事件 wevtutil qe System /q:"*[System[(EventID=10036)]]" /f:text /c:10 # 在客户端筛选 10037 和 10038 wevtutil qe System /q:"*[System[(EventID=10037 or EventID=10038)]]" /f:text /c:10

wevtutil 的 /q 参数里用 XPath 过滤事件 ID，/c:10 限制返回最近 10 条，/f:text 输出可读文本。10036 里的 %4 是客户端 IP，拿这个 IP 去对应机器上查 10037/10038，就能定位到具体是哪个应用程序、哪个 PID、请求激活的 CLSID 是什么。如果客户端上一条都没有，说明该客户端可能还没装带事件记录的补丁，或者它调用的 CoInitializeSecurity 已经设了足够高的级别。

4.2 连接测试的顺序和观察点

验证不能只靠 OPC 客户端软件点“连接”。我一般按这个顺序走：先在服务器本机用本地 OPC 客户端连一次，确认服务器本身没问题；再从一台已改默认级别的客户端远程连，看是否成功；最后从一台未改的客户端远程连，确认它是否按预期失败并产生 10038。这个对照能区分“服务器配置问题”和“客户端身份验证级别问题”。

如果远程连接失败但事件日志里没有 10036，常见原因是防火墙或 RPC 动态端口没放通，和 KB5004442 无关。这时候先看服务器端 DCOM 是否监听 135 端口，再看 RPC 动态端口范围有没有在防火墙里开口。我吃过一次亏，把 DCOM 配置改了一圈，最后发现是中间一台交换机做了端口限制，白折腾半天。

4.3 常见坑：现象、原因、解决

现象一：改完注册表没重启，连接依旧失败。原因：RequireIntegrityActivationAuthenticationLevel 在系统启动时读取，重启 OPC 服务或重启 DCOM 服务都不算。解决：完整重启设备，再复查注册表值是否还在，有些安全软件会回写。

现象二：服务器端事件 10036 里显示的用户是 ANONYMOUS LOGON。原因：客户端没有正确传递凭据，或者 DCOM 自定义权限里没给对应用户远程激活权限。解决：先在 DCOMCNFG 里确认该 OPC 对象的启动和激活权限包含实际发起连接的用户，再检查客户端是否以对等身份运行。

现象三：全局默认级别改成 5 后，部分老客户端直接连不上，事件 10037 显示显式设置了级别 2。原因：客户端程序自己调了 CoInitializeSecurity 并把身份验证级别写死成“连接”，这种只能等软件供应商更新。解决：短期用注册表开关关掉强化争取时间，长期推动供应商改代码或改用 OPC Tunneller、OPC UA 这类不依赖 DCOM 的方案。

现象四：2023 年 3 月之后的补丁上，注册表开关改成 0 也不生效。原因：该阶段强化已强制启用，开关不再被读取。解决：没有配置层面的后悔药，只能从应用侧解决，或者迁移通信方式。

现象五：客户端和服务器都改了，还是间歇性断连。原因：OPC Classic 很多实现只在首次建立连接时做身份验证，不是每个数据包都验证，网络抖动后重连时可能走到不同的激活路径。解决：把客户端和服务器的 DCOM 默认级别统一到 5，并确认没有单个对象残留低级别自定义设置，然后用长时间采集脚本观察事件日志是否还有 10038。

5. 装完怎么验证跑通：一套可重复的检查清单

配置改完不等于跑通，我最后一定会走一遍固定检查，确认这套环境在重启后仍然成立。第一步，重启客户端和服务器，重启后立刻查注册表值是否保持：reg query "HKLM\SOFTWARE\Microsoft\Ole\AppCompat" /v RequireIntegrityActivationAuthenticationLevel，返回 0x1 才算开关生效。第二步，查默认身份验证级别：reg query "HKLM\SOFTWARE\Microsoft\Ole" /v LegacyAuthenticationLevel，返回 0x5 才算级别到位。第三步，在服务器端清空事件日志前先记下当前时间，然后从客户端发起一次远程 OPC 连接，连接成功后等两分钟，再用wevtutil qe System /q:"*[System[(EventID=10036)]]" /f:text /c:5确认没有新的 10036。第四步，故意从一台未改配置的客户端连一次，确认它产生 10038 而不是静默失败，这说明事件记录链路是通的，以后出问题能查到。

这套检查里最容易漏的是第三步的等待时间。DCOM 激活失败有时候不是立刻报错，而是客户端重试几次后才在日志里落事件，所以连上之后不要马上收工，留两分钟观察窗口。另外，如果现场有多台 OPC 服务器，每台都要单独走一遍，不能拿一台的结果代表全部，因为自定义权限是按对象配的。

我现在的习惯是，每次 Windows 累积更新落地后，不管有没有重启，都把上面四步跑一遍，尤其是 2023 年 3 月之后的补丁阶段，开关已经不能关，只能靠这套检查提前发现哪个客户端还没跟上。血泪经验就是别等产线停了再查日志，那时候每一分钟都在烧钱。希望帮到你。

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