簡(jiǎn)介這份資源圍繞微軟 KB5004442 安全更新展開(kāi)系統(tǒng)梳理了 CVE-2021-26414 漏洞對(duì) Windows DCOM Server 及 OPC Classic 通信機(jī)制的影響適合工業(yè)自動(dòng)化工程師、IT運(yùn)維人員及 OPC 應(yīng)用開(kāi)發(fā)者作為合規(guī)評(píng)估與排障參考。內(nèi)容涵蓋漏洞背景、DCOM 安全機(jī)制變更時(shí)間表、對(duì)客戶端與服務(wù)器端的差異化影響、CoInitializeSecurity 權(quán)限設(shè)置要點(diǎn)以及 2022 年 6 月 14 日與 2023 年 3 月 14 日兩個(gè)關(guān)鍵節(jié)點(diǎn)的應(yīng)對(duì)建議并附有具體注冊(cè)表路徑與測(cè)試步驟。資料為 1 個(gè) PDF 文件壓縮包約 398KB方便直接查閱。已有 459 人學(xué)習(xí)適合需要評(píng)估現(xiàn)有 OPC Classic 環(huán)境是否受此更新影響、提前規(guī)劃軟件升級(jí)或臨時(shí)緩解措施的技術(shù)人員可在短時(shí)間內(nèi)掌握更新要點(diǎn)并據(jù)此安排后續(xù)驗(yàn)證工作。1. KB5004442 不是一次普通安全更新它直接決定 OPC Classic 還能不能聯(lián)網(wǎng)2022 年 6 月之后如果你所在的工廠還在用 OPC Classic 采集 PLC、DCS 數(shù)據(jù)并且 Windows 服務(wù)器裝了 KB5004442 更新那你大概率會(huì)撞上一個(gè)詭異現(xiàn)象OPC 客戶端能啟動(dòng)、能加載但一建立遠(yuǎn)程連接就超時(shí)事件日志里冒出一堆 10036、10037。這不是網(wǎng)絡(luò)問(wèn)題也不是 OPC 軟件本身壞了而是 Windows DCOM 安全機(jī)制被微軟強(qiáng)制提高了一個(gè)等級(jí)——從「連接時(shí)驗(yàn)一次身」變成了「每個(gè)數(shù)據(jù)包都要驗(yàn)身」。KB5004442 正是針對(duì) CVE-2021-26414 這個(gè) DCOM Server 安全功能旁路漏洞的修復(fù)補(bǔ)丁它給所有依賴(lài) DCOM 的 OPC Classic 應(yīng)用劃了一條硬底線激活 DCOM 服務(wù)器時(shí)身份驗(yàn)證級(jí)別不得低于數(shù)據(jù)包完整性RPC_C_AUTHN_LEVEL_PKT_INTEGRITY。如果你負(fù)責(zé)產(chǎn)線上的 OPC 通信或者你正在維護(hù)老的 SCADA 系統(tǒng)這篇文章就是為你寫(xiě)的。2. DCOM 安全更新為什么會(huì)掐斷 OPC 通信認(rèn)證級(jí)別、CoInitializeSecurity 與 CVE-2021-264142.1 先捋清 COM、DCOM 和 OPC Classic 的關(guān)系OPC Classic包括 DA、HDA、AE本質(zhì)上是基于微軟 COM 組件模型的一套接口規(guī)范。COM 組件在同一臺(tái)機(jī)器上可以通過(guò)指針調(diào)用但一旦跨進(jìn)程、跨機(jī)器Windows 就會(huì)自動(dòng)把 COM 調(diào)用包裝成 DCOM——分布式 COM。換句話說(shuō)OPC 客戶端和 OPC 服務(wù)器都是 COM 組件它們之間的遠(yuǎn)程通信走的是 DCOM 通道安全策略完全由 Windows DCOM 機(jī)制說(shuō)了算。這就帶來(lái)一個(gè)連鎖反應(yīng)Windows 的安全更新只要?jiǎng)?DCOM 的默認(rèn)行為OPC Classic 的通信就跟著遭殃。KB5004442 就屬于這一類(lèi)——它不是針對(duì) OPC 的但它改了所有 DCOM 激活請(qǐng)求的最低認(rèn)證門(mén)檻。OPC 行業(yè)的老應(yīng)用普遍只做了「首次連接認(rèn)證」甚至完全沒(méi)設(shè)認(rèn)證級(jí)別正好被這個(gè)更新卡住。我接觸過(guò)的不少項(xiàng)目里WinCC、InTouch 連舊版 Matrikon OPC 服務(wù)器都屬于這種情況。2.2 這次更新到底改了什么從默認(rèn)認(rèn)證到強(qiáng)制數(shù)據(jù)包完整性CVE-2021-26414 的核心問(wèn)題是DCOM 服務(wù)器在激活過(guò)程中沒(méi)有強(qiáng)制校驗(yàn)客戶端的認(rèn)證級(jí)別攻擊者可以用低級(jí)別認(rèn)證繞過(guò)安全機(jī)制在未經(jīng)授權(quán)的情況下激活 DCOM 對(duì)象。微軟的修復(fù)思路很直接——在 DCOM 服務(wù)器端加一道閘凡是激活請(qǐng)求認(rèn)證級(jí)別必須達(dá)到 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY值等于 5或更高。這個(gè)「認(rèn)證級(jí)別」不是網(wǎng)絡(luò)術(shù)語(yǔ)里的密碼強(qiáng)度它描述的是 DCOM 調(diào)用過(guò)程中安全包對(duì)數(shù)據(jù)的保護(hù)程度。級(jí)別從 0 到 6 遞增0 是無(wú)認(rèn)證1 是連接級(jí)認(rèn)證只驗(yàn)一次連接2 是調(diào)用級(jí)認(rèn)證每次調(diào)用驗(yàn)一次3 是數(shù)據(jù)包級(jí)認(rèn)證每個(gè)數(shù)據(jù)包驗(yàn)一次4 是數(shù)據(jù)包完整性每個(gè)數(shù)據(jù)包驗(yàn)簽確保沒(méi)被篡改5 是數(shù)據(jù)包機(jī)密性在完整性基礎(chǔ)上還加密6 是數(shù)據(jù)包機(jī)密性舊版保留值。KB5004442 要求的最低級(jí)別是 4也就是數(shù)據(jù)包完整性。注意3 和 4 的區(qū)別很關(guān)鍵3 只驗(yàn)證數(shù)據(jù)包來(lái)源4 還要做完整性校驗(yàn)防止中間人篡改。微軟選 4 而不是 3是因?yàn)?CVE-2021-26414 的利用路徑正是通過(guò)篡改 DCOM 激活流量來(lái)繞過(guò)安全策略。所以問(wèn)題不是「OPC 軟件沒(méi)做認(rèn)證」而是很多老應(yīng)用用的認(rèn)證級(jí)別是 1連接級(jí)或 3數(shù)據(jù)包級(jí)要么完全沒(méi)觸發(fā)強(qiáng)制檢查要么達(dá)不到新的最低要求。系統(tǒng)日志里會(huì)出現(xiàn) 10036、10037、10038 這些新事件就是系統(tǒng)在告訴你有應(yīng)用試圖用低于 4 的認(rèn)證級(jí)別激活 DCOM 服務(wù)器被攔下來(lái)了。2.3 CoInitializeSecurity客戶端的「一次性」安全配置函數(shù)對(duì) OPC Classic 客戶端來(lái)說(shuō)權(quán)限設(shè)置通常通過(guò) CoInitializeSecurity 函數(shù)完成。這個(gè)函數(shù)有個(gè)特殊的脾氣每個(gè)進(jìn)程實(shí)例只能調(diào)用一次第二次調(diào)用會(huì)直接失敗并返回錯(cuò)誤。也就是說(shuō)客戶端程序如果在初始化時(shí)把認(rèn)證級(jí)別定死了后續(xù)任何代碼都無(wú)法再修改。這里要分兩種情況看客戶端調(diào)用了 CoInitializeSecurity并且傳入了認(rèn)證級(jí)別參數(shù)。這種情況下如果傳入的級(jí)別低于 4更新啟用后就會(huì)被服務(wù)器拒絕。客戶端沒(méi)有調(diào)用 CoInitializeSecurity。此時(shí)操作系統(tǒng)會(huì)按照默認(rèn) DCOM 設(shè)置替它調(diào)用一次認(rèn)證級(jí)別來(lái)自 DCOMCNFG 里的默認(rèn)值。如果默認(rèn)設(shè)置正確比如默認(rèn)認(rèn)證級(jí)別是「數(shù)據(jù)包完整性」客戶端不會(huì)受影響。我自己排查過(guò)的一個(gè)案例某 OPC 客戶端軟件是 C 寫(xiě)的代碼里明確調(diào)用了 CoInitializeSecurity傳入的是 RPC_C_AUTHN_LEVEL_CONNECT級(jí)別 1。在 2021 年 6 月前完全正常但注冊(cè)表強(qiáng)制啟用后所有遠(yuǎn)程 OPC 連接全部失敗。這類(lèi)問(wèn)題只能找軟件廠商出補(bǔ)丁相當(dāng)于從源碼層面改認(rèn)證級(jí)別。2.4 服務(wù)器端為什么 DCOMCNFG 反而更安全服務(wù)器端的邏輯和客戶端不一樣。多數(shù) OPC Classic 服務(wù)器比如 Matrikon OPC Server不直接在代碼里調(diào) CoInitializeSecurity而是通過(guò) DCOMCNFG 工具配置安全權(quán)限。這就意味著服務(wù)器端的認(rèn)證級(jí)別是管理員在圖形界面里設(shè)的改起來(lái)相對(duì)容易。但要注意DCOMCNFG 里有兩套設(shè)置一個(gè)是「默認(rèn) DCOM 設(shè)置」——影響所有未單獨(dú)配置的 COM 應(yīng)用另一個(gè)是對(duì)每個(gè)具體 OPC 服務(wù)器對(duì)象的「自定義 DCOM 設(shè)置」——優(yōu)先級(jí)更高。KB5004442 啟用后系統(tǒng)強(qiáng)制的是服務(wù)器的激活A(yù)ctivation認(rèn)證級(jí)別而不是調(diào)用的認(rèn)證級(jí)別。很多人只改了調(diào)用Call級(jí)別沒(méi)改激活A(yù)ctivation級(jí)別結(jié)果依然是連接失敗。服務(wù)器端受影響相對(duì)小但配置錯(cuò)了照樣翻車(chē)。3. 事件日志里找答案10036、10037、10038 三類(lèi) DCOM 錯(cuò)誤怎么讀3.1 服務(wù)器的 10036激活請(qǐng)求被策略拒絕啟用新安全功能后如果 DCOM 服務(wù)器端檢測(cè)到有客戶端用低于數(shù)據(jù)包完整性的認(rèn)證級(jí)別來(lái)激活它系統(tǒng)日志里會(huì)寫(xiě)入事件 ID 10036。這條事件記錄在服務(wù)器上消息長(zhǎng)這樣服務(wù)器端身份驗(yàn)證級(jí)別策略不允許用戶 %1%2 SID (%3) 從地址 %4 激活 DCOM 服務(wù)器。請(qǐng)將激活身份驗(yàn)證級(jí)別至少提升為在客戶端應(yīng)用程序中 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY。其中 %1 是域名%2 是用戶名%3 是用戶 SID%4 是客戶端 IP 地址。這條日志最有價(jià)值的字段是 %4——它直接告訴你「是誰(shuí)從哪里來(lái)的請(qǐng)求被拒了」。遇到這條事件優(yōu)先去查對(duì)應(yīng)客戶端程序用了什么認(rèn)證級(jí)別而不是先懷疑服務(wù)器權(quán)限配置。實(shí)際操作中我一般會(huì)用 PowerShell 把近期相關(guān)的 10036 事件拉出來(lái)看Get-WinEvent -FilterHashtable { LogName System Id 10036 StartTime (Get-Date).AddDays(-7) } | Select-Object TimeCreated, Message | Format-List這段命令的意思是在系統(tǒng)日志里篩選過(guò)去 7 天中事件 ID 為 10036 的記錄然后列出每條的時(shí)間和完整消息內(nèi)容。-FilterHashtable比-FilterXPath寫(xiě)起來(lái)更簡(jiǎn)潔適合現(xiàn)場(chǎng)快速排查。如果你要精確到某個(gè) IP可以在 Message 字段里用Where-Object再做一次過(guò)濾比如加一個(gè)Where-Object { $_.Message -like *192.168.* }。3.2 客戶端的 10037 和 10038分清「顯式設(shè)置」和「默認(rèn)設(shè)置」的差別10037 和 10038 都寫(xiě)在客戶端那臺(tái)機(jī)器上但它們代表的場(chǎng)景完全不同。10037 是客戶端程序在代碼里顯式指定了認(rèn)證級(jí)別而且這個(gè)級(jí)別低于 510038 是客戶端程序沒(méi)有顯式指定由系統(tǒng)按默認(rèn)激活認(rèn)證級(jí)別代勞而這個(gè)默認(rèn)值低于 5。10037 的消息里會(huì)帶 %5表示客戶端顯式設(shè)置的認(rèn)證級(jí)別值10038 的 %5 則是系統(tǒng)使用的默認(rèn)認(rèn)證級(jí)別值。這兩條事件都在客戶端日志里找Get-WinEvent -FilterHashtable { LogName System Id 10037, 10038 } | Select-Object Id, TimeCreated, {NApplication;E{$_.Properties[0].Value}}, {NPID;E{$_.Properties[1].Value}}, {NCLSID;E{$_.Properties[2].Value}}, {NAuthLevel;E{$_.Properties[4].Value}} | Format-Table -AutoSize這里的Properties數(shù)組順序?qū)?yīng)事件消息里的占位符第 0 個(gè)是應(yīng)用程序路徑第 1 個(gè)是 PID第 2 個(gè)是 CLSID第 4 個(gè)在 10037 里是顯式認(rèn)證級(jí)別、在 10038 里是默認(rèn)認(rèn)證級(jí)別。用這種方式格式化輸出比直接看原始消息更清晰尤其是一次抓幾十條事件的時(shí)候?？吹?CLSID你可以去注冊(cè)表里反查它對(duì)應(yīng)哪個(gè) COM 組件從而確定是哪個(gè) OPC 客戶端軟件干的。3.3 用事件日志時(shí)間線還原故障全過(guò)程排查 OPC 連接故障時(shí)不要只看單條事件。我習(xí)慣把三臺(tái)機(jī)器客戶端、服務(wù)器、域控如果涉及的事件日志時(shí)間線對(duì)齊來(lái)看客戶端先出現(xiàn) 10037 或 10038緊接著服務(wù)器出現(xiàn) 10036說(shuō)明是認(rèn)證級(jí)別被拒如果客戶端沒(méi)有事件、服務(wù)器也沒(méi)有事件但連接就是斷了那問(wèn)題多半在網(wǎng)絡(luò)層面或 DCOM 端口配置上跟這次安全更新無(wú)關(guān)。有個(gè)細(xì)節(jié)值得注意10036、10037、10038 這三類(lèi)事件僅在特定 Windows 版本上可用。比如 Windows Server 2022 是 2021 年 9 月 27 日之后、Windows 10 2004/20H2/21H1 是 2021 年 9 月 1 日之后。如果你在 Windows Server 2016 上找不到這些事件先確認(rèn)補(bǔ)丁是否裝到位——沒(méi)有這些事件 ID不等于安全強(qiáng)化沒(méi)生效可能只是舊系統(tǒng)還沒(méi)引入事件記錄功能。4. 三階段時(shí)間表與注冊(cè)表操作從測(cè)試啟用到永久強(qiáng)制4.1 第一階段2021 年 6 月 8 日到 2022 年 6 月 13 日默認(rèn)禁用手動(dòng)啟用測(cè)試KB5004442 在 2021 年 6 月 8 日發(fā)布時(shí)新安全功能默認(rèn)處于關(guān)閉狀態(tài)微軟給了一個(gè)注冊(cè)表項(xiàng)來(lái)手動(dòng)開(kāi)啟。這個(gè)階段的目的是讓大家在非生產(chǎn)環(huán)境測(cè)試影響。你要做的不是直接改生產(chǎn)系統(tǒng)而是先搭一套測(cè)試環(huán)境把注冊(cè)表項(xiàng)打開(kāi)然后跑一遍完整的 OPC 通信鏈路驗(yàn)證。注冊(cè)表操作路徑如下項(xiàng)目值注冊(cè)表路徑HKLM\SOFTWARE\Microsoft\Ole\AppCompat值名稱(chēng)RequireIntegrityActivationAuthenticationLevel類(lèi)型REG_DWORD值數(shù)據(jù)0 禁用1 啟用用命令行設(shè)置reg add HKLM\SOFTWARE\Microsoft\Ole\AppCompat /v RequireIntegrityActivationAuthenticationLevel /t REG_DWORD /d 1 /f/v指定值名稱(chēng)/t聲明類(lèi)型是 DWORD/d 1表示寫(xiě)入數(shù)值 1 即啟用/f強(qiáng)制覆蓋已存在的同名值。執(zhí)行完必須重啟系統(tǒng)注冊(cè)表項(xiàng)才會(huì)被 DCOM 運(yùn)行時(shí)讀取。我當(dāng)時(shí)測(cè)試的時(shí)候只運(yùn)行了命令沒(méi)重啟結(jié)果折騰了半小時(shí)以為是命令寫(xiě)錯(cuò)路徑實(shí)際上就是沒(méi)生效——這個(gè)坑后面細(xì)說(shuō)。4.2 第二階段2022 年 6 月 14 日到 2023 年 3 月 13 日默認(rèn)啟用注冊(cè)表可關(guān)從 2022 年 6 月 14 日開(kāi)始Windows 默認(rèn)啟動(dòng)新安全功能但你仍然可以通過(guò)把注冊(cè)表值設(shè)為 0 來(lái)臨時(shí)禁用。微軟留這個(gè)窗口期是為了給軟件廠商爭(zhēng)取時(shí)間發(fā)布兼容更新。對(duì)一線運(yùn)維來(lái)說(shuō)這個(gè)階段最穩(wěn)妥的做法是先啟用安全功能跑一段時(shí)間收集所有告警和事件日志確認(rèn)哪些 OPC 組件不兼容然后聯(lián)系廠商要補(bǔ)丁。如果你在產(chǎn)線上一時(shí)半會(huì)兒等不到廠商更新可以臨時(shí)禁用注冊(cè)表項(xiàng)恢復(fù)通信但禁用期間系統(tǒng)暴露在 CVE-2021-26414 風(fēng)險(xiǎn)之下。我建議設(shè)置一個(gè)明確的恢復(fù)時(shí)間點(diǎn)并在服務(wù)器上留好操作記錄免得三個(gè)月后忘了自己關(guān)過(guò)這個(gè)開(kāi)關(guān)。reg add HKLM\SOFTWARE\Microsoft\Ole\AppCompat /v RequireIntegrityActivationAuthenticationLevel /t REG_DWORD /d 0 /f注意這臺(tái)機(jī)器上如果有多個(gè)依賴(lài) DCOM 的應(yīng)用禁用注冊(cè)表會(huì)影響所有應(yīng)用不只是 OPC。禁用前確認(rèn)有沒(méi)有其他更嚴(yán)格的安全策略在網(wǎng)關(guān)或防火墻上兜底。4.3 第三階段2023 年 3 月 14 日之后永久強(qiáng)制注冊(cè)表開(kāi)關(guān)失效2023 年 3 月 14 日之后微軟徹底移除了禁用開(kāi)關(guān)——注冊(cè)表項(xiàng)即使設(shè)成 0 也不再生效。到這個(gè)節(jié)點(diǎn)唯一的選擇只剩三條路從 OPC 客戶端/服務(wù)器廠商獲取兼容更新版本用 OPC Tunneller 之類(lèi)的軟件把 OPC Classic 通信封裝成獨(dú)立的 TCP 隧道繞過(guò) DCOM遷移到 OPC UA直接告別 DCOM 依賴(lài)。我之前在某個(gè)水處理項(xiàng)目里就遇到這種情況客戶有 30 多個(gè) OPC 采集點(diǎn)用的舊版采集器不支持?jǐn)?shù)據(jù)包完整性認(rèn)證廠商已經(jīng)停止維護(hù)。最后我們?cè)u(píng)估下來(lái)用 OPC UA 網(wǎng)關(guān)做協(xié)議轉(zhuǎn)換把老的 OPC DA 封裝成 UA 服務(wù)花了三天完成切換。這筆賬要早點(diǎn)算拖到強(qiáng)制階段再動(dòng)手就只能停機(jī)窗口里趕工。4.4 驗(yàn)證注冊(cè)表生效不只是看值設(shè)置完注冊(cè)表并重啟后怎么確認(rèn)新安全功能真的在起作用一個(gè)有效的辦法是直接在測(cè)試環(huán)境里故意用一個(gè)低認(rèn)證級(jí)別的客戶端去連服務(wù)器。如果沒(méi)有生效連接會(huì)成功如果生效了系統(tǒng)日志里會(huì)立刻出現(xiàn) 10036。你也可以用 PowerShell 檢查注冊(cè)表當(dāng)前值Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Ole\AppCompat -Name RequireIntegrityActivationAuthenticationLevel輸出結(jié)果里RequireIntegrityActivationAuthenticationLevel的值為 1 代表啟用0 或未定義代表禁用。注意Get-ItemProperty如果值不存在會(huì)報(bào)錯(cuò)這是正常的不代表注冊(cè)表有問(wèn)題——很多機(jī)器上根本沒(méi)有這個(gè)鍵默認(rèn)就是禁用狀態(tài)。5. 避坑記錄KB5004442 在 OPC 現(xiàn)場(chǎng)的五個(gè)常見(jiàn)翻車(chē)點(diǎn)5.1 改完注冊(cè)表不重啟白忙活一場(chǎng)現(xiàn)象注冊(cè)表值已經(jīng)改成 1但跑 OPC 連接測(cè)試還是正常或者還是報(bào)錯(cuò)跟沒(méi)改一樣。原因DCOM 配置在系統(tǒng)啟動(dòng)時(shí)被 Ole32.dll 加載注冊(cè)表變更不會(huì)實(shí)時(shí)熱加載。很多人改完注冊(cè)表之后直接跑測(cè)試結(jié)果操作的還是舊配置。解決改注冊(cè)表后必須重啟系統(tǒng)。測(cè)試環(huán)境可以接受生產(chǎn)環(huán)境建議先規(guī)劃停機(jī)窗口。重啟后用第 4.4 節(jié)的方法確認(rèn)值已生效再做連接測(cè)試。5.2 只改 DCOMCNFG 的調(diào)用認(rèn)證級(jí)別忘了激活級(jí)別現(xiàn)象DCOMCNFG 里已經(jīng)把「身份驗(yàn)證級(jí)別」改成了「數(shù)據(jù)包完整性」但 OPC 客戶端連服務(wù)器還是被拒事件日志照樣出 10036。原因KB5004442 強(qiáng)制檢查的是 DCOM 激活A(yù)ctivation階段的認(rèn)證級(jí)別不是調(diào)用Call階段。DCOMCNFG 的常規(guī)設(shè)置頁(yè)里那個(gè)身份驗(yàn)證級(jí)別下拉框大部分時(shí)間影響的是調(diào)用階段激活級(jí)別在高級(jí)設(shè)置里很多人根本沒(méi)注意到。解決在 DCOMCNFG 里找到目標(biāo) OPC 服務(wù)器的組件打開(kāi)屬性 → 高級(jí)把「默認(rèn)模擬級(jí)別」下方或安全選項(xiàng)卡里的激活身份驗(yàn)證級(jí)別同步設(shè)置為「數(shù)據(jù)包完整性」值為 5。如果是自定義配置每個(gè) OPC 服務(wù)器對(duì)象都要單獨(dú)檢查不能只改默認(rèn)值。5.3 誤以為所有 OPC 通信都走 135 端口漏改防火墻現(xiàn)象注冊(cè)表啟用后OPC 客戶端能 ping 通服務(wù)器但 DCOM 連接就是建立不起來(lái)事件日志里也沒(méi)有 10036。原因DCOM 建立連接的初始協(xié)商走 TCP 135 端口但實(shí)際數(shù)據(jù)通道會(huì)動(dòng)態(tài)分配一個(gè)隨機(jī)端口默認(rèn)范圍 1024-65535。很多現(xiàn)場(chǎng)防火墻只放行了 135導(dǎo)致協(xié)商成功但數(shù)據(jù)通道被攔。也不是每次通都失敗——Windows 會(huì)緩存端口分配表現(xiàn)得很隨機(jī)。解決用Dcomcnfg.exe打開(kāi)組件服務(wù)右鍵「我的電腦」→ 屬性 → 默認(rèn)屬性把「默認(rèn) DCOM 端口范圍」固定成一個(gè)窄段比如 55000-55050然后在防火墻上放行 TCP 55000-55050。這個(gè)操作要在所有 OPC 服務(wù)器上重復(fù)做。注意固定端口范圍本身有安全風(fēng)險(xiǎn)端口段越窄越安全但也要留夠并發(fā)連接數(shù)。5.4 把 10038 當(dāng)成程序 Bug實(shí)際是系統(tǒng)默認(rèn)級(jí)別過(guò)低現(xiàn)象客戶端事件日志出現(xiàn) 10038消息說(shuō)「默認(rèn)激活身份驗(yàn)證級(jí)別為 %5」但程序本身是自己開(kāi)發(fā)的代碼里沒(méi)設(shè)置過(guò)認(rèn)證級(jí)別。原因10038 表示程序沒(méi)有顯式調(diào)用 CoInitializeSecurity系統(tǒng)按默認(rèn)值代替程序執(zhí)行。默認(rèn)激活認(rèn)證級(jí)別來(lái)自 DCOMCNFG 的「默認(rèn)屬性」頁(yè)如果那里的身份驗(yàn)證級(jí)別設(shè)的是「連接」值 1甚至「無(wú)」值 0就會(huì)觸發(fā) 10038。解決先在 DCOMCNFG 默認(rèn)屬性里把身份驗(yàn)證級(jí)別設(shè)為「數(shù)據(jù)包完整性」觀察 10038 是否消失。如果消失了說(shuō)明問(wèn)題在系統(tǒng)默認(rèn)配置如果還在說(shuō)明有代碼在某個(gè)間接路徑上調(diào)了 CoInitializeSecurity——這時(shí)候就得翻代碼或者找廠商。5.5 把注冊(cè)表值寫(xiě)成字符串導(dǎo)致類(lèi)型不匹配現(xiàn)象手動(dòng)用注冊(cè)表編輯器添加值輸入了 1但 reg query 查出來(lái)類(lèi)型顯示為 REG_SZ系統(tǒng)不認(rèn)。原因DCOM 運(yùn)行時(shí)讀取的是 DWORD 類(lèi)型你在注冊(cè)表編輯器里新建值的時(shí)候選的類(lèi)型不對(duì)或者直接復(fù)制了網(wǎng)上別人發(fā)的 REG_SZ 寫(xiě)法。解決用reg add命令創(chuàng)建明確指定/t REG_DWORD。如果已經(jīng)建錯(cuò)了先刪除錯(cuò)的值再重建reg delete HKLM\SOFTWARE\Microsoft\Ole\AppCompat /v RequireIntegrityActivationAuthenticationLevel /f reg add HKLM\SOFTWARE\Microsoft\Ole\AppCompat /v RequireIntegrityActivationAuthenticationLevel /t REG_DWORD /d 1 /f第一條命令/f表示不確認(rèn)直接刪除第二條命令重建。完成后務(wù)必用reg query驗(yàn)證類(lèi)型reg query HKLM\SOFTWARE\Microsoft\Ole\AppCompat /v RequireIntegrityActivationAuthenticationLevel6. 遷移到 OPC UA 之前的最后一搏三步驗(yàn)證法判斷老系統(tǒng)是否還有救在決定是否遷移到 OPC UA 之前我建議你把下面這套驗(yàn)證流程完整跑一遍。它能幫你快速判斷現(xiàn)有 OPC Classic 系統(tǒng)在 KB5004442 強(qiáng)制階段下還有沒(méi)有救同時(shí)避免拍腦袋上遷移方案導(dǎo)致項(xiàng)目延期。第一步確認(rèn)所有 OPC 客戶端的 CoInitializeSecurity 行為。寫(xiě)一個(gè)小工具用 Get-Process 列出所有運(yùn)行中的 OPC 客戶端進(jìn)程然后用 Get-WinEvent 檢查最近 30 天內(nèi)有沒(méi)有出現(xiàn)過(guò) 10037 事件。如果客戶端進(jìn)程一次 10037 都沒(méi)有說(shuō)明它的認(rèn)證級(jí)別可能是由系統(tǒng)默認(rèn)值決定的你還有機(jī)會(huì)通過(guò)調(diào) DCOMCNFG 默認(rèn)屬性解決如果頻繁出現(xiàn) 10037說(shuō)明代碼里寫(xiě)死了低認(rèn)證級(jí)別得等廠商更新。第二步在非生產(chǎn)環(huán)境完整模擬強(qiáng)制階段。設(shè)置注冊(cè)表值為 1重啟然后把 DCOMCNFG 里所有相關(guān)組件的激活認(rèn)證級(jí)別和調(diào)用認(rèn)證級(jí)別全部改為「數(shù)據(jù)包完整性」跑一遍采集鏈路、寫(xiě)操作、報(bào)警上報(bào)AE的完整測(cè)試。這一步要特別注意 OPC DA 的寫(xiě)操作——有些采集器讀數(shù)據(jù)走 DCOM 沒(méi)問(wèn)題但寫(xiě)操作走了另一條路徑認(rèn)證級(jí)別要求不同容易被忽略。第三步檢查 OPC 服務(wù)器端是否有替代通信通道。如果服務(wù)器本身支持 OPC UA現(xiàn)在很多廠家在同一個(gè)服務(wù)里同時(shí)提供 DA 和 UA 接口直接切 UA 端口就行成本最低。如果不支持考慮 OPC Tunneller——這類(lèi)軟件的原理是在兩臺(tái)機(jī)器上分別裝一個(gè)代理代理之間用普通 TCP 通信兩端各自身邊的 OPC 組件只做本機(jī) COM 調(diào)用完全不跨機(jī)器走 DCOM。好處是改動(dòng)最小壞處是引入了私有協(xié)議依賴(lài)。我在一個(gè)汽車(chē)零部件工廠里用過(guò)這種方式把 20 多臺(tái)老設(shè)備的采集切換時(shí)間控制在了一個(gè)周末。三套方案對(duì)比下來(lái)最直接的判斷標(biāo)準(zhǔn)是客戶端是否有可用更新。有更新優(yōu)先打補(bǔ)丁沒(méi)有更新優(yōu)先看服務(wù)器端是否自帶 UA兩者都不行再上 Tunneller。遷移到 OPC UA 是長(zhǎng)期最優(yōu)解但工程改造量最大涉及的不僅是通信層連上位機(jī)組態(tài)軟件的連接配置都要重做。這輪排查里唯一不能做的事是繼續(xù)指望注冊(cè)表開(kāi)關(guān)。微軟在 2023 年 3 月 14 日之后已經(jīng)把這條路焊死了。從那以后我每次接手帶 OPC Classic 的項(xiàng)目第一件事就是先查服務(wù)器 Windows 版本和補(bǔ)丁日期確認(rèn)是否已經(jīng)進(jìn)入強(qiáng)制階段再?zèng)Q定是做兼容測(cè)試還是直接規(guī)劃 UA 遷移。這個(gè)習(xí)慣幫我避開(kāi)了好幾次產(chǎn)線停機(jī)事故希望也能幫到你。本文還有配套的精品資源點(diǎn)擊獲取