KB5004442 补丁导致 OPC Classic 远程连接失败?DCOM 身份验证配置与排查指南
简介面向工业自动化运维人员与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 对应内部版本 14393Windows 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 /fLegacyAuthenticationLevel 的取值含义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 或 1003810037 表示应用程序显式把身份验证级别设低了10038 表示应用程序走的是默认激活级别且低于要求。# 在服务器端筛选 DCOM 相关事件 wevtutil qe System /q:*[System[(EventID10036)]] /f:text /c:10 # 在客户端筛选 10037 和 10038 wevtutil qe System /q:*[System[(EventID10037 or EventID10038)]] /f:text /c:10wevtutil 的 /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[(EventID10036)]] /f:text /c:5确认没有新的 10036。第四步故意从一台未改配置的客户端连一次确认它产生 10038 而不是静默失败这说明事件记录链路是通的以后出问题能查到。这套检查里最容易漏的是第三步的等待时间。DCOM 激活失败有时候不是立刻报错而是客户端重试几次后才在日志里落事件所以连上之后不要马上收工留两分钟观察窗口。另外如果现场有多台 OPC 服务器每台都要单独走一遍不能拿一台的结果代表全部因为自定义权限是按对象配的。我现在的习惯是每次 Windows 累积更新落地后不管有没有重启都把上面四步跑一遍尤其是 2023 年 3 月之后的补丁阶段开关已经不能关只能靠这套检查提前发现哪个客户端还没跟上。血泪经验就是别等产线停了再查日志那时候每一分钟都在烧钱。希望帮到你。本文还有配套的精品资源点击获取