簡(jiǎn)介這份PDF資料聚焦微軟KB5004442安全更新面向工業(yè)自動(dòng)化領(lǐng)域的OPC Classic運(yùn)維人員、DCOM應(yīng)用開發(fā)者及系統(tǒng)管理員用于評(píng)估CVE-2021-26414修補(bǔ)后DCOM安全機(jī)制變更對(duì)OPC通信的沖擊。資源包僅含1個(gè)PDF文件約398KB內(nèi)容圍繞DCOM安全更新概述、對(duì)OPC Classic客戶端與服務(wù)器的影響、微軟分階段更新時(shí)間表、受影響Windows版本清單及緩解措施展開并給出注冊(cè)表項(xiàng)啟用與禁用方法、CoInitializeSecurity函數(shù)身份驗(yàn)證級(jí)別調(diào)整要點(diǎn)以及2022年6月14日默認(rèn)啟用、2023年3月14日后無法禁用等關(guān)鍵節(jié)點(diǎn)。讀者可據(jù)此判斷現(xiàn)有OPC Classic應(yīng)用是否需升級(jí)掌握測(cè)試與臨時(shí)規(guī)避思路并了解遷移至OPC UA或OPC Tunneller等替代方案。目前已有460人學(xué)習(xí)下載適合需要快速排查DCOM安全更新兼容性問題的技術(shù)人員參考。1. OPC 連不上服務(wù)器KB5004442 之后 DCOM 拒絕激活的典型現(xiàn)場(chǎng)如果你在 2022 年 6 月之后突然發(fā)現(xiàn) OPC Classic 客戶端連不上遠(yuǎn)程服務(wù)器事件日志里冒出 10036、10037、10038 這類 DCOM 錯(cuò)誤大概率不是網(wǎng)絡(luò)斷了也不是 OPC 服務(wù)掛了而是 Windows 的 DCOM 安全強(qiáng)化更新 KB5004442 在起作用。這個(gè)補(bǔ)丁對(duì)應(yīng) CVE-2021-26414微軟從 2021 年 6 月就開始推送但默認(rèn)禁用新策略給了將近兩年的緩沖期。很多人當(dāng)時(shí)測(cè)試沒問題就忘了這回事結(jié)果 2023 年 3 月 14 日一過注冊(cè)表開關(guān)徹底失效OPC Classic 的遠(yuǎn)程連接直接翻車。這類故障折騰人的地方在于網(wǎng)絡(luò) ping 得通、DCOMCNFG 里權(quán)限看著也對(duì)、服務(wù)也在跑但客戶端就是報(bào)“拒絕訪問”或“服務(wù)器不可用”。下面按報(bào)錯(cuò)現(xiàn)象、根因定位、可執(zhí)行修復(fù)、避坑記錄、快速排查的順序把這條鏈路拆開講清楚。2. 報(bào)錯(cuò) 10036/10037/10038先分清是客戶端還是服務(wù)器在拒絕2.1 三個(gè)事件 ID 分別代表什么KB5004442 啟用后系統(tǒng)會(huì)在事件日志里記錄 DCOM 激活失敗的具體原因。這三個(gè) ID 是最直接的線索事件 ID記錄位置含義10036服務(wù)器端系統(tǒng)日志服務(wù)器端身份驗(yàn)證級(jí)別策略不允許該用戶從某 IP 激活 DCOM 服務(wù)器10037客戶端系統(tǒng)日志應(yīng)用程序顯式設(shè)置了低于數(shù)據(jù)包完整性的身份驗(yàn)證級(jí)別10038客戶端系統(tǒng)日志應(yīng)用程序使用默認(rèn)激活身份驗(yàn)證級(jí)別但低于數(shù)據(jù)包完整性要求10036 出現(xiàn)在服務(wù)器上說明請(qǐng)求已經(jīng)到達(dá)服務(wù)器但被服務(wù)器的 DCOM 安全策略擋了。10037 和 10038 出現(xiàn)在客戶端上區(qū)別在于10037 是應(yīng)用程序自己調(diào)用了CoInitializeSecurity并顯式設(shè)了一個(gè)低級(jí)別10038 是應(yīng)用程序根本沒調(diào)走了系統(tǒng)默認(rèn)設(shè)置而默認(rèn)值不夠。2.2 用 PowerShell 快速拉出相關(guān)事件不要手動(dòng)在事件查看器里翻直接跑命令過濾# 在服務(wù)器端查 10036在客戶端查 10037/10038 Get-WinEvent -FilterHashtable {LogNameSystem; Id10036,10037,10038} -MaxEvents 50 | Select-Object TimeCreated, Id, MachineName, Message | Format-List這條命令把三個(gè)事件 ID 一起拉出來MachineName能幫你確認(rèn)是哪臺(tái)機(jī)器記錄的。如果只在服務(wù)器上看到 10036客戶端沒有 10037/10038說明客戶端可能根本沒走到激活階段先查網(wǎng)絡(luò)和 RPC 端口。如果客戶端有 10037重點(diǎn)看消息里的%5字段——那是應(yīng)用程序設(shè)置的身份驗(yàn)證級(jí)別值5 才是RPC_C_AUTHN_LEVEL_PKT_INTEGRITY小于 5 就會(huì)被拒。2.3 確認(rèn)注冊(cè)表開關(guān)的當(dāng)前狀態(tài)KB5004442 的行為由一個(gè)注冊(cè)表值控制# 路徑HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat # 值名稱RequireIntegrityActivationAuthenticationLevel # 類型REG_DWORD # 數(shù)據(jù)0x00000000 禁用0x00000001 啟用用 reg query 查reg query HKLM\SOFTWARE\Microsoft\Ole\AppCompat /v RequireIntegrityActivationAuthenticationLevel如果返回“找不到指定的注冊(cè)表項(xiàng)或值”說明該值未定義系統(tǒng)按默認(rèn)處理。在 2022 年 6 月 14 日到 2023 年 3 月 14 日之間未定義等于禁用2023 年 3 月 14 日之后未定義等于強(qiáng)制啟用且無法通過設(shè) 0 來關(guān)閉。這一點(diǎn)是很多人的誤區(qū)以為沒設(shè)過就沒事實(shí)際上時(shí)間一到自動(dòng)生效。注意修改這個(gè)注冊(cè)表值后必須重啟設(shè)備才生效不是重啟服務(wù)就行。3. 修復(fù) OPC 連接失敗從注冊(cè)表緩解到代碼級(jí)改造3.1 臨時(shí)緩解在允許的時(shí)間窗口內(nèi)禁用安全功能如果你還在 2023 年 3 月 14 日之前或者系統(tǒng)尚未安裝強(qiáng)制啟用的補(bǔ)丁可以用注冊(cè)表臨時(shí)關(guān)掉# 以管理員身份運(yùn)行 reg add HKLM\SOFTWARE\Microsoft\Ole\AppCompat /v RequireIntegrityActivationAuthenticationLevel /t REG_DWORD /d 0x00000000 /f # 重啟設(shè)備 shutdown /r /t 0/d 0x00000000表示禁用/f強(qiáng)制覆蓋已有值。執(zhí)行完必須重啟否則 DCOM 運(yùn)行時(shí)不會(huì)重新讀取這個(gè)配置。這個(gè)操作只是緩兵之計(jì)2023 年 3 月 14 日之后同樣的命令會(huì)被系統(tǒng)忽略設(shè)了也沒用。3.2 服務(wù)器端把默認(rèn)身份驗(yàn)證級(jí)別提到數(shù)據(jù)包完整性服務(wù)器端的問題通常出在 DCOMCNFG 的默認(rèn)設(shè)置上。手動(dòng)改的路徑是組件服務(wù) → 計(jì)算機(jī) → 我的電腦 → 右鍵屬性 → 默認(rèn)屬性 → 默認(rèn)身份驗(yàn)證級(jí)別改為“數(shù)據(jù)包完整性”。對(duì)應(yīng)的注冊(cè)表位置在# 默認(rèn)身份驗(yàn)證級(jí)別 reg add HKLM\SOFTWARE\Microsoft\Ole /v LegacyAuthenticationLevel /t REG_DWORD /d 0x00000005 /f0x00000005對(duì)應(yīng)RPC_C_AUTHN_LEVEL_PKT_INTEGRITY。改完后同樣需要重啟。如果服務(wù)器上有多個(gè) OPC Server 對(duì)象每個(gè)對(duì)象的自定義 DCOM 權(quán)限也要單獨(dú)檢查確保沒有覆蓋成更低級(jí)別。3.3 客戶端CoInitializeSecurity 調(diào)用與不調(diào)用的區(qū)別客戶端分兩種情況。如果 OPC Classic 客戶端代碼里調(diào)用了CoInitializeSecurity需要把身份驗(yàn)證級(jí)別參數(shù)改成RPC_C_AUTHN_LEVEL_PKT_INTEGRITY// C 示例顯式設(shè)置數(shù)據(jù)包完整性 CoInitializeSecurity( NULL, // 安全描述符 -1, // 認(rèn)證服務(wù)數(shù)量 NULL, // 認(rèn)證服務(wù)列表 NULL, // 保留參數(shù) RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, // 關(guān)鍵身份驗(yàn)證級(jí)別 RPC_C_IMP_LEVEL_IMPERSONATE, // 模擬級(jí)別 NULL, // 認(rèn)證列表 EOAC_NONE, // 能力標(biāo)志 NULL // 保留參數(shù) );RPC_C_AUTHN_LEVEL_PKT_INTEGRITY的值是 5它要求每個(gè)數(shù)據(jù)包都驗(yàn)證完整性而不是只在連接建立時(shí)驗(yàn)證一次。如果客戶端不調(diào)用這個(gè)函數(shù)系統(tǒng)會(huì)用默認(rèn) DCOM 設(shè)置代替只要默認(rèn)設(shè)置已經(jīng)改成數(shù)據(jù)包完整性就不會(huì)受影響。所以排查時(shí)先確認(rèn)客戶端到底調(diào)沒調(diào)再?zèng)Q定是改代碼還是改系統(tǒng)默認(rèn)值。3.4 長(zhǎng)期方案OPC Tunneller 或遷移到 OPC UA如果供應(yīng)商短期內(nèi)給不出支持?jǐn)?shù)據(jù)包完整性的新版本可以考慮用 OPC Tunneller 把 DCOM 通信封裝成普通 TCP 隧道繞過 DCOM 安全策略。更徹底的方案是遷移到 OPC UA它原生支持證書和消息安全不依賴 Windows DCOM。遷移成本不低但對(duì)于 2023 年 3 月 14 日之后還在用舊版 OPC Classic 的系統(tǒng)這幾乎是唯一能徹底擺脫時(shí)間壓力的路徑。4. 避坑記錄KB5004442 排查中最容易踩的五個(gè)坑4.1 坑一以為沒設(shè)注冊(cè)表就不會(huì)啟用現(xiàn)象系統(tǒng)從未手動(dòng)配置過RequireIntegrityActivationAuthenticationLevel但 2023 年 3 月 14 日之后 OPC 突然斷了。原因該值未定義時(shí)2023 年 3 月 14 日之后系統(tǒng)按強(qiáng)制啟用來處理不是按禁用。解決不要依賴“沒設(shè)過”這個(gè)狀態(tài)提前用reg query確認(rèn)實(shí)際生效值并在測(cè)試環(huán)境驗(yàn)證。4.2 坑二改了注冊(cè)表但沒重啟現(xiàn)象注冊(cè)表值已經(jīng)改成 0OPC 還是連不上。原因DCOM 運(yùn)行時(shí)在系統(tǒng)啟動(dòng)時(shí)讀取該配置不重啟不會(huì)重新加載。解決改完必須shutdown /r /t 0不能只重啟 OPC 服務(wù)或 DCOM Server Process Launcher。4.3 坑三只改客戶端或只改服務(wù)器現(xiàn)象客戶端事件日志里 10037 消失了但服務(wù)器端 10036 還在報(bào)。原因DCOM 激活需要兩端都滿足最低身份驗(yàn)證級(jí)別只改一端不夠。解決客戶端和服務(wù)器同時(shí)檢查客戶端看CoInitializeSecurity或默認(rèn)級(jí)別服務(wù)器看 DCOMCNFG 默認(rèn)屬性和每個(gè) OPC Server 對(duì)象的自定義權(quán)限。4.4 坑四把 10036 當(dāng)成網(wǎng)絡(luò)故障去查現(xiàn)象看到“拒絕激活”就去查防火墻、RPC 端口、DNS。原因10036 是安全策略拒絕不是網(wǎng)絡(luò)不通。網(wǎng)絡(luò)層能通但 DCOM 安全層不放行。解決先看事件消息里的身份驗(yàn)證級(jí)別值小于 5 就直接往安全配置方向查不要浪費(fèi)時(shí)間在網(wǎng)絡(luò)上。4.5 坑五在 2023 年 3 月 14 日之后還試圖用注冊(cè)表禁用現(xiàn)象執(zhí)行reg add ... /d 0x00000000后重啟OPC 依然連不上。原因該日期之后安全功能強(qiáng)制啟用注冊(cè)表禁用開關(guān)失效。解決只能從供應(yīng)商獲取支持?jǐn)?shù)據(jù)包完整性的更新版本或者轉(zhuǎn)向 OPC Tunneller / OPC UA。5. 快速定位這類問題的排查順序與驗(yàn)證方法遇到 OPC Classic 連接失敗不要一上來就重啟服務(wù)或重裝軟件。我一般按下面這個(gè)順序走基本能在十分鐘內(nèi)判斷問題出在哪一層。第一步確認(rèn)時(shí)間線和補(bǔ)丁狀態(tài)。查系統(tǒng)是否安裝了 KB5004442 相關(guān)更新以及當(dāng)前日期是否已過 2023 年 3 月 14 日。這一步?jīng)Q定了后面所有操作的方向。第二步拉事件日志。服務(wù)器端查 10036客戶端查 10037 和 10038。三個(gè) ID 的組合能直接告訴你是客戶端設(shè)低了10037、客戶端沒設(shè)而默認(rèn)低了10038還是服務(wù)器端策略拒絕10036。第三步查注冊(cè)表實(shí)際生效值。不要只看有沒有手動(dòng)設(shè)過用reg query看返回值。未定義、0、1 三種狀態(tài)對(duì)應(yīng)不同的行為階段。第四步檢查 DCOMCNFG 默認(rèn)身份驗(yàn)證級(jí)別和 OPC Server 對(duì)象的自定義權(quán)限。默認(rèn)級(jí)別必須是數(shù)據(jù)包完整性自定義權(quán)限不能覆蓋成更低。第五步確認(rèn)客戶端是否調(diào)用CoInitializeSecurity。調(diào)用了就查代碼里的級(jí)別參數(shù)沒調(diào)用就查系統(tǒng)默認(rèn)值是否已改對(duì)。第六步如果以上都正確但依然失敗用 OPC Tunneller 做隔離測(cè)試確認(rèn)是否還有 DCOM 之外的依賴問題。驗(yàn)證方法上最直接的是在非生產(chǎn)環(huán)境把注冊(cè)表設(shè)為 1 強(qiáng)制啟用然后跑一遍全鏈路連接測(cè)試。如果啟用后連接失敗、禁用后恢復(fù)說明問題確實(shí)在 DCOM 安全強(qiáng)化上。這個(gè)測(cè)試要在 2023 年 3 月 14 日之前做之后就沒有禁用這個(gè)選項(xiàng)了。從那以后我每次給 OPC Classic 系統(tǒng)做升級(jí)或遷移都會(huì)先把 KB5004442 的時(shí)間表和注冊(cè)表狀態(tài)查一遍再檢查客戶端和服務(wù)器的身份驗(yàn)證級(jí)別最后才動(dòng)網(wǎng)絡(luò)和防火墻。這個(gè)順序幫我省了很多來回折騰的時(shí)間。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取