2026 年 7 月的最後一週為 Microsoft Entra ID 帶來一系列多元的更新,涵蓋驗證、多租戶管理、通訊協定安全與安全營運整合。從通行金鑰註冊的改進,到 Kerberos RC4 的不可逆終止,以下是身分管理員需要知道的所有事項。

MC1440968:通行金鑰註冊最佳化

7 月 27 日,Microsoft 發布了訊息中心通知 MC1440968,詳細說明 Entra ID 通行金鑰註冊體驗的最佳化內容。這些變更針對三個註冊介面:註冊活動 (Registration Campaign)、驗證強度 (Authentication Strengths) 與我的登入 (My Sign-Ins)。

變更內容

更新後的註冊邏輯引進兩項關鍵改進:

  1. 符合原則的註冊指引 — 系統會引導使用者註冊符合系統管理員所設定之通行金鑰設定檔限制的通行金鑰類型。這可減少失敗或不合規的註冊嘗試,對於使用 AAGUID 限制設定檔(限制允許的通行金鑰提供者)的組織尤其重要。

  2. 本機裝置優先 — 在原則允許的情況下,註冊作業會優先採用使用者目前裝置原生的通行金鑰。這可確保使用者在自己實際使用的裝置上註冊裝置繫結認證,而非被導向使用另一部裝置的同步通行金鑰,進而改善登入體驗。

為何重要

投資通行金鑰設定檔的組織——尤其是僅限裝置繫結、強制證明或 AAGUID 限制的設定——很可能在註冊過程中遇到阻礙。使用者有時會嘗試註冊不符合系統管理員所設定設定檔的通行金鑰類型,導致註冊失敗與支援票證。這些最佳化正是為了解決這個落差。

時程與所需動作

  • 推出時程: 2026 年 8 月下旬(全球與 GCC)
  • 使用者介面變更:
  • 系統管理員需執行的動作:
  • 影響範圍: 所有透過註冊活動、驗證強度或我的登入註冊通行金鑰的使用者

這是一項幕後的改進,無需任何組態變更即可讓通行金鑰流程更加順暢。如果您目前正在規劃 9 月的通行金鑰遷移(趕在 2027 年 2 月 SMS/語音驗證退役之前),這些最佳化將有助於減少註冊阻礙。

Entra Tenant Governance:集中式多租戶管理(預覽版)

Entra Tenant Governance 是 7 月 30 日「What’s New in Microsoft Security: July 2026」部落格文章所宣布的內容之一,目前已可在 Entra 系統管理中心查看,並已開放預覽。這項功能解決了管理多個 Entra 租戶之組織長期以來的痛點。

功能說明

Tenant Governance 建立治理關係——治理租戶與一個或多個被治理租戶之間的定向連線。這可實現:

  • 跨租戶委派管理 — 系統管理員使用治理租戶的帳戶登入,無需在每個被治理租戶中建立與管理本機或 B2B 系統管理員帳戶。
  • 租戶組態管理 — 利用委派存取權限,確保持續達成被治理租戶的組織安全與合規目標。
  • 安全的租戶建立 — 從現有租戶建立的新增租戶會自動獲得治理關係,並套用預設原則範本。

運作方式

建立治理關係需經過三步驟的握手程序:

  1. 未來的被治理租戶向未來的治理租戶傳送治理邀請
  2. 未來的治理租戶傳送治理要求,並附上選定的治理原則範本。
  3. 未來的被治理租戶審閱並接受要求,建立關係。

治理原則範本

範本是 Tenant Governance 的建置基礎。每個範本定義:

  • 委派的系統管理角色 — 治理租戶使用者在被治理租戶中持有的內建 Entra 角色,透過治理租戶中的群組指派。
  • 多租戶應用程式 — 可在多個被治理租戶中建立與管理的自訂多租戶應用程式。

範本可在多個治理關係之間重複使用,確保一致的存取原則。建立關係時,Tenant Governance 會擷取範本的快照——更新範本不會自動更新現有的關係。套用更新需要重複要求與接受程序,確保被治理租戶隨時有機會審閱權限變更。

與現有工具的差異

功能Azure LighthouseEntra Tenant Governance
方向將客戶資源向上投射至提供者將提供者身分向下投射至客戶
脈絡提供者從自身脈絡管理提供者主體可在客戶租戶內使用
範圍Azure 資源Entra 目錄角色 + RBAC
主要使用案例CSP/MSP 情境一般多租戶管理

已新增租戶治理系統管理員角色(範本識別碼:1981f584-96e9-4a6f-95b0-f522373f8fae),用於管理所有 Tenant Governance 功能。

為何重要

對於擁有多個 Entra 租戶的組織——無論是來自併購、子公司架構,或測試/生產環境分離——Tenant Governance 消除了在每個租戶中維護獨立系統管理員帳戶的營運負擔。三步驟握手程序確保雙方都同意這項安排,而原則範本方法則提供一致且可審閱的存取控制。

Kerberos RC4 最終強制執行:期限已過

2026 年 7 月 14 日是 Kerberos RC4 淘汰的不可逆轉點。隨著 7 月 Patch Tuesday 更新,Microsoft 永久移除了允許網域控制站回復為稽核模式的 RC4DefaultDisablementPhase 登錄機碼。強制執行現在是唯一的狀態。

三階段時程

階段日期變更內容可復原?
初始部署2026 年 1 月 13 日KDCSVC 201-209 稽核事件開始
強制執行2026 年 4 月 14 日未明確設定 msDS-SupportedEncryptionTypes 的帳戶預設改為僅 AES(0x18)是,透過 RC4DefaultDisablementPhase = 1
永久2026 年 7 月 14 日復原機碼已移除。稽核模式已移除。除非逐帳戶明確設定,否則 RC4 遭到封鎖。

會破壞什麼

具備下列 msDS-SupportedEncryptionTypes 設定的服務帳戶將在 Kerberos 驗證時無聲失敗:

  • 空值/Null 屬性(未設定明確的加密類型)
  • 0x0(未設定)
  • 0x4(僅 RC4)
  • 0x7(DES + RC4)

失敗是無聲的——沒有錯誤對話方塊或警示。使用者只是無法存取服務,第一個跡象通常是支援票證。

補救步驟

針對每個受影響的服務帳戶:

# Set AES-only encryption (AES128 + AES256 = 0x18 = decimal 24)
Set-ADUser -Identity "svc-myapp" -Replace @{'msDS-SupportedEncryptionTypes'=24}

# CRITICAL: Reset the password to force AES key generation
# Without this step, the account has no AES keys to use
Set-ADAccountPassword -Identity "svc-myapp"

若要透過網域控制站上的 GPO 進行全網域強制執行:

HKLM\SYSTEM\CurrentControlSet\services\KDC
DefaultDomainSupportedEncTypes = 0x18 (DWORD)

針對 Java 應用程式,更新 krb5.ini

default_tkt_enctypes = aes256-cts aes128-cts
default_tgs_enctypes = aes256-cts aes128-cts
permitted_enctypes = aes256-cts aes128-cts

為何現在重要

與 4 月可使用登錄機碼復原的強制執行階段不同,7 月的更新沒有任何全網域層級的逃生門。若要為特定帳戶重新啟用 RC4,唯一方法是明確將該個別帳戶的 msDS-SupportedEncryptionTypes 設定為包含 RC4 位元——這是 Microsoft 強烈不建議的做法。如果您尚未稽核服務帳戶,請今天就執行。

Entra-Defender 整合:SOC 身分回應

7 月 30 日的「What’s New in Microsoft Security」部落格文章也強調了 Microsoft Entra 與 Microsoft Defender 之間更深層的整合,在 2026 年 6 月推出的 SOC Identity Responder 角色基礎上持續發展。

新增內容

相互連結的 Entra 與 Defender 體驗現在提供:

  • 直接從 Defender 進行身分遏制 — SOC 分析師可直接從 Defender 入口網站使用最低權限 RBAC 模式停用遭入侵的身分,無需廣泛的 Entra 系統管理角色。
  • 共享的使用者體驗 — 身分與存取管理團隊和 SOC 團隊共享相同的使用者體驗,消除產品之間的斷層。
  • 代理式工作流程 — 兩個團隊都能受益於橫跨身分與安全營運的代理式工作流程,簡化事件回應。

SOC Identity Responder 角色

SOC Identity Responder 角色(2026 年 6 月以公開預覽形式推出)是這項整合的基礎。它提供:

功能說明
停用/啟用使用者帳戶在主動入侵期間立即阻止橫向移動
撤銷作用中的登入工作階段讓重新整理權杖失效,即時終結攻擊者的工作階段
重設密碼讓第一線應變人員能對遭入侵的帳戶立即採取行動
限定於系統管理單位支援區域性或分區應變團隊

角色範本識別碼: 58f930cc-fcf4-4152-852c-1d7dbf502139

權限:

  • microsoft.directory/users/disable
  • microsoft.directory/users/enable
  • microsoft.directory/users/invalidateAllRefreshTokens
  • microsoft.directory/users/password/update

Defender for Identity 整合

Defender for Identity 會自動在 Entra ID 中建立企業應用程式。當使用者從 Defender 入口網站發起補救動作時,系統會根據使用者的 Entra ID 角色授權該要求,並由 Defender for Identity 應用程式執行,全程強制 RBAC 與稽核記錄。

為何重要

在作用中的安全事件期間,每一分鐘都很重要。以往 SOC 分析師必須同時持有數個高權限 Entra 角色,或等待身分系統管理員採取遏制動作。SOC Identity Responder 角色與 Entra-Defender 整合消除了這個瓶頸,得以在適當的最低權限邊界內實現更快速的遏制。

Project Perception:代理式安全營運

同樣在 7 月 27 日宣布的 Project Perception 是 Microsoft 專為安全營運打造的協調式專業 AI 代理系統。雖然這並非純粹的 Entra 公告,但身分是這些代理的核心訊號來源。

代理團隊

  • 紅隊代理 — 透過持續測試揭露弱點
  • 藍隊代理 — 調查環境中偵測到的網路威脅
  • 綠色代理 — 強化紅隊與藍隊代理發現的弱點

這些多代理自主工作流程以連續迴圈運作,執行端對端的安全工作流程。這些代理運用全企業範圍的訊號——包括 Entra ID 身分資料——提供全面的安全涵蓋。

對身分管理員的意義

隨著 Microsoft 的代理式安全願景逐步實現,Entra ID 不再只是身分提供者,更是 AI 驅動安全營運的關鍵訊號來源。確保您的身分資料乾淨、治理良好且經過妥善稽核,將直接影響這些代理式工作流程的成效。

行動項目摘要

優先順序動作期限
重大稽核服務帳戶的 Kerberos RC4 合規性立即——強制執行已生效
盤點仍在使用 SMS/語音 MFA 的使用者2026 年 9 月 1 日前
為 SMS/語音使用者設定通行金鑰註冊活動2026 年 9 月 1 日前
評估多租戶情境的 Tenant Governance預覽版現已開放
將 SOC Identity Responder 角色指派給安全分析師現已可用(預覽版)
MC1440968 通行金鑰最佳化無需採取動作2026 年 8 月下旬自動推出

展望未來

Entra ID 的演進步調毫無減緩的跡象。隨著通行金鑰於 9 月 1 日成為預設驗證方法、舊版風險原則於 10 月 1 日退役,以及 SMS/語音驗證於 2027 年 2 月 1 日退役,2026 年下半年充滿了身分轉型的重要里程碑。Entra 與 Defender 的整合,加上 Project Perception 的代理式安全,彰顯了 Microsoft 的更宏大願景:以身分作為 AI 驅動安全營運的基礎。

如需持續更新,請在 X 上追蹤討論:https://x.com/kkaminsk,並查看 Microsoft Entra 官方 What’s New 頁面