企业官网建设流程全解析

简介：这份PDF资料聚焦微软KB5004442安全更新，面向工业自动化领域的OPC Classic运维人员、DCOM组件开发者及系统管理员，用于评估CVE-2021-26414修补后DCOM安全机制变更对OPC通信的冲击。资源包仅含1个PDF文件，约398KB，内容围绕DCOM安全更新概述、对OPC Classic客户端与服务器的影响、微软分阶段更新时间表、受影响Windows版本清单及缓解措施展开，并给出注册表项启用与禁用方法、CoInitializeSecurity函数身份验证级别调整要点，以及2022年6月14日默认启用、2023年3月14日后无法禁用等关键节点。读者可据此判断自身系统与OPC组件是否需升级，提前规划测试与迁移方案，避免远程连接中断。目前已有460人学习下载，适合需要快速掌握该安全更新影响范围与应对思路的技术人员参考。

1. KB5004442 补丁落地前，先把 DCOM 与 OPC Classic 的依赖关系理清

很多工控现场第一次遇到 KB5004442，都不是在测试环境里，而是在某次例行补丁之后：SCADA 画面还在刷新，但 OPC Classic 的远程连接突然大面积掉线，事件日志里开始刷 10036、10037、10038。这个补丁对应 CVE-2021-26414，微软从 2021 年 6 月 8 日开始把 DCOM 激活时的最低身份验证级别往RPC_C_AUTHN_LEVEL_PKT_INTEGRITY上推，2022 年 6 月 14 日默认启用，2023 年 3 月 14 日之后注册表开关彻底失效。换句话说，只要你的 OPC Classic 客户端和服务器跨机器走 DCOM，就绕不开这次变更。这篇笔记按“先确认环境、再装补丁、再配注册表、最后验证连接”的顺序写，适合还在用 OPC DA、OPC HDA 这类老协议、又必须打安全补丁的现场工程师。

2. 装前环境盘点：哪些 Windows 版本和 OPC 组件会被 KB5004442 波及

2.1 受影响的 Windows 版本与补丁前置条件

KB5004442 不是单独一个补丁包，而是随月度安全更新滚进来的 DCOM 强化逻辑。按微软给出的范围，下面这些系统都在影响列表里，装之前先对一遍机器清单：

我一般会先在每台机器上跑一遍补丁查询，确认 KB5004442 或其后续累积更新是否已经进来：

# 在 PowerShell 中查询已安装的 DCOM 相关补丁 Get-HotFix | Where-Object { $_.HotFixID -match "KB5004442|KB5005101|KB5005102|KB5005103|KB5005573|KB5005619|KB5006714" } | Format-Table HotFixID, InstalledOn, Description

这段命令的逻辑是：Get-HotFix拉取本机已安装补丁列表，Where-Object用正则匹配 KB5004442 以及微软在 2021 年 8 月到 10 月间陆续放出的配套更新。Format-Table只保留补丁号、安装日期和描述，方便快速判断这台机器处于哪个阶段。如果一条都查不到，说明补丁还没进来，或者被 WSUS 拦住了，需要先确认补丁通道。

2.2 OPC Classic 组件的 DCOM 依赖确认

补丁本身不区分你是不是 OPC，它只管 DCOM 激活时的身份验证级别。所以第二步是确认哪些 OPC 组件真的在走 DCOM。常见做法是打开dcomcnfg，在“组件服务 → 计算机 → 我的电脑 → DCOM 配置”里找 OPC 相关的 AppID，比如OPC Server、OpcEnum、厂商自定义的 ProgID。

# 列出本机注册的 OPC 相关 DCOM 应用 Get-ChildItem "HKLM:\SOFTWARE\Classes\AppID" | ForEach-Object { $appid = $_.PSChildName $name = (Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue).'(default)' if ($name -match "OPC|Opc") { [PSCustomObject]@{ AppID = $appid; Name = $name } } } | Format-Table -AutoSize

这里遍历HKLM:\SOFTWARE\Classes\AppID，把默认值里带 OPC 字样的项挑出来。AppID是 DCOM 配置的主键，后面改自定义权限和身份验证级别都要靠它定位。如果这一步什么都查不到，但现场确实在用 OPC Classic，那可能是 OPC 组件以本地服务方式跑，或者客户端根本没走远程 DCOM，需要再确认拓扑。

提示：Windows Server 2019 Server Core 没有图形化 dcomcnfg，只能用 PowerShell 或regedit远程连过去改，装补丁前先把远程注册表通道确认好。

3. 安装与配置 KB5004442：注册表开关、身份验证级别和 DCOMCNFG 参数

3.1 注册表项 RequireIntegrityActivationAuthenticationLevel 的写入与回滚

微软给了一个临时开关，位置在：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat 值名称：RequireIntegrityActivationAuthenticationLevel 类型：DWORD 值数据：0x00000000 禁用，0x00000001 启用

我一般用 PowerShell 写，避免手抖把十六进制敲错：

# 启用 DCOM 数据包完整性强制（测试阶段用） $path = "HKLM:\SOFTWARE\Microsoft\Ole\AppCompat" if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null } New-ItemProperty -Path $path -Name "RequireIntegrityActivationAuthenticationLevel" -PropertyType DWord -Value 0x00000001 -Force # 回滚：改回 0x00000000 并重启 Set-ItemProperty -Path $path -Name "RequireIntegrityActivationAuthenticationLevel" -Value 0x00000000

New-ItemProperty的-PropertyType DWord对应注册表里的 dword，-Value 0x00000001是启用。注意微软明确要求必须以十六进制格式输入，并且设置后必须重启设备才生效。回滚时用Set-ItemProperty改回 0 再重启，这是 2023 年 3 月 14 日之前唯一能临时恢复连接的手段。2023 年 3 月 14 日之后这个开关不再起作用，只能从应用侧解决。

3.2 DCOMCNFG 中默认身份验证级别与自定义权限的调整

注册表开关只是总闸，真正决定单个 OPC 组件行为的是 DCOMCNFG 里的两处设置。第一处是“我的电脑”属性里的默认属性：

dcomcnfg → 组件服务 → 计算机 → 我的电脑 → 右键属性 → 默认属性 将“默认身份验证级别”改为：数据包完整性 (Packet Integrity)

第二处是每个 OPC Server 的 AppID 自定义属性：

dcomcnfg → 组件服务 → 计算机 → 我的电脑 → DCOM 配置 → 选中 OPC Server AppID → 右键属性 → 常规 将“身份验证级别”改为：数据包完整性

我一般会先改默认属性，再逐个改 OPC Server 的 AppID。改完不重启，直接测连接，因为 DCOM 配置是即时生效的。如果现场 OPC Server 是通过CoInitializeSecurity自己设权限的，DCOMCNFG 里的自定义权限可能被覆盖，这时候要看服务器端事件日志有没有 10036。

3.3 OPC Classic 客户端 CoInitializeSecurity 的代码侧适配

客户端侧的问题更隐蔽。OPC Classic 客户端如果在代码里调了CoInitializeSecurity，那它传进去的身份验证级别就决定了 DCOM 激活能不能过。微软的要求是至少RPC_C_AUTHN_LEVEL_PKT_INTEGRITY，对应数值 5。

// OPC Classic 客户端 CoInitializeSecurity 调用示例（C++） HRESULT hr = CoInitializeSecurity( NULL, // 安全描述符，NULL 表示用默认 -1, // 身份验证服务数量，-1 表示用默认 NULL, // 身份验证服务列表 NULL, // 保留参数 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, // 关键：数据包完整性 RPC_C_IMP_LEVEL_IMPERSONATE, // 模拟级别 NULL, // 身份验证列表 EOAC_NONE, // 能力标志 NULL // 保留参数 );

RPC_C_AUTHN_LEVEL_PKT_INTEGRITY是这次变更的核心，低于它的值比如RPC_C_AUTHN_LEVEL_CONNECT或RPC_C_AUTHN_LEVEL_NONE都会被服务器端拒绝。CoInitializeSecurity每个进程只能调一次，后续调用返回RPC_E_TOO_LATE，所以如果客户端库内部已经调过，外部再调没用，只能等供应商更新。如果客户端压根没调这个函数，操作系统会用默认 DCOM 设置，只要默认设置改成了数据包完整性，就不会受影响。

4. 避坑与排查：KB5004442 落地时最容易翻车的五个点

4.1 现象：补丁打完 OPC 连接全断，事件日志刷 10036

原因：服务器端已经启用 DCOM 强化，客户端激活时用的身份验证级别低于RPC_C_AUTHN_LEVEL_PKT_INTEGRITY。服务器端事件 10036 会记录客户端 IP、用户 SID 和域信息，客户端事件 10037 或 10038 会记录具体应用程序路径和 PID。

解决：先在服务器端事件日志里按事件 ID 10036 过滤，拿到客户端 IP；再去对应客户端查 10037/10038，定位是哪个 exe 在发起激活。如果是自己开发的客户端，改CoInitializeSecurity；如果是第三方 OPC 客户端，联系供应商要更新版本，或者临时把注册表开关改回 0 并重启。

4.2 现象：注册表项写了但没生效

原因：三个常见错误——值名拼错、类型写成 String、没重启。微软明确要求值名是RequireIntegrityActivationAuthenticationLevel，类型 dword，数据十六进制，设置后重启。

解决：用reg query确认写入结果：

reg query "HKLM\SOFTWARE\Microsoft\Ole\AppCompat" /v RequireIntegrityActivationAuthenticationLevel

输出里REG_DWORD和0x1都对才算写对。如果路径不存在，先手动建AppCompat项。

4.3 现象：DCOMCNFG 里改了身份验证级别，但 OPC 还是连不上

原因：OPC Server 的 AppID 可能不止一个，或者客户端走的是OpcEnum先枚举再连，枚举那一步的 DCOM 激活也需要数据包完整性。另外，如果服务器端 OPC 组件自己调了CoInitializeSecurity，DCOMCNFG 里的自定义权限会被覆盖。

解决：把OpcEnum的 AppID 也一起改。用 2.2 节的 PowerShell 脚本把所有 OPC 相关 AppID 列出来，逐个改。改完在客户端用 OPC 测试工具重新枚举一次，看能不能列出服务器。

4.4 现象：2023 年 3 月 14 日之后注册表开关失效，回滚不了

原因：微软按时间表在 2023 年 3 月 14 日之后强制启用，注册表项不再被读取。这是设计行为，不是 bug。

解决：只剩三条路——找软件供应商拿支持数据包完整性的更新版本；上 OPC Tunneller 这类方案，把 DCOM 通信转成 TCP 隧道，绕开 DCOM 激活；迁移到 OPC UA。我一般会先评估 OPC UA 迁移成本，如果现场设备多、老 Server 不支持 UA，就先用 Tunneller 顶住。

4.5 现象：Windows Server 2019 Server Core 上没法用 dcomcnfg

原因：Server Core 没有图形界面，dcomcnfg 打不开。

解决：从一台有图形界面的机器远程连过去，或者直接用 PowerShell 改注册表。DCOM 配置本质上都在注册表里，HKLM:\SOFTWARE\Classes\AppID下面每个 AppID 的AuthenticationLevel值就是身份验证级别，5对应数据包完整性。改完重启 DCOM 服务或重启机器。

# 在 Server Core 上直接改某个 AppID 的身份验证级别 $appid = "{你的OPC AppID}" Set-ItemProperty -Path "HKLM:\SOFTWARE\Classes\AppID\$appid" -Name "AuthenticationLevel" -Value 5 -Type DWord

AuthenticationLevel的数值含义：1 是 None，2 是 Connect，3 是 Call，4 是 Packet，5 是 Packet Integrity，6 是 Packet Privacy。设成 5 就是这次变更要求的最低级别。

5. 装完怎么验证：用事件日志和 OPC 连接测试确认 DCOM 强化已生效

补丁装完、注册表写完、DCOMCNFG 改完，最后一步是验证。我一般分三层做：先确认注册表状态，再确认事件日志没有新报错，最后跑一次真实的 OPC 连接。

第一层，注册表状态确认：

# 确认注册表开关和 DCOM 身份验证级别 reg query "HKLM\SOFTWARE\Microsoft\Ole\AppCompat" /v RequireIntegrityActivationAuthenticationLevel Get-ItemProperty "HKLM:\SOFTWARE\Classes\AppID\{你的OPC AppID}" | Select-Object AuthenticationLevel

输出里RequireIntegrityActivationAuthenticationLevel是0x1，AuthenticationLevel是5，才算配置到位。

第二层，事件日志检查。在服务器端和客户端分别查：

# 服务器端查 10036 Get-WinEvent -FilterHashtable @{LogName='System'; ID=10036} -MaxEvents 20 | Format-List TimeCreated, Message # 客户端查 10037 和 10038 Get-WinEvent -FilterHashtable @{LogName='System'; ID=10037,10038} -MaxEvents 20 | Format-List TimeCreated, Message

如果查不到新事件，说明当前没有低于数据包完整性的激活尝试。如果还有，按 4.1 的流程定位到具体应用。

第三层，真实 OPC 连接测试。用 OPC 客户端工具连一次服务器，枚举项、读一个标签、写一个标签。我一般会读一个模拟量标签，看数值能不能刷新，再写一个设定值，看服务器端有没有响应。这一步过了，才算真正跑通。

注意：验证时一定要用生产环境相同的客户端版本和网络路径，不要只在服务器本机测。DCOM 的问题往往只在跨机器时暴露。

从那以后我每次给工控现场打补丁，都会先把 KB5004442 的时间表和注册表开关写进变更单，补丁前跑一遍 2.1 的补丁查询，补丁后跑一遍 5 的三层验证，确认事件日志干净、OPC 读写正常才收工。希望帮到你。

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