2026年7月的最后一周为 Microsoft Entra ID 带来了一系列多样化的更新，涵盖身份验证、多租户管理、协议安全和安全运营融合。从通行密钥注册改进到 Kerberos RC4 的不可逆终结，以下是身份管理员需要了解的全部内容。
MC1440968：通行密钥注册优化
7月27日，Microsoft 发布了消息中心通知 MC1440968，详细说明了 Entra ID 中通行密钥注册体验的优化。这些更改涉及三个注册入口：Registration Campaign（注册活动）、Authentication Strengths（身份验证强度）和 My Sign-Ins（我的登录）。
变更内容
更新后的注册逻辑引入了两项关键改进：
符合策略的注册指引 — 用户将被引导注册符合管理员配置的通行密钥配置文件限制的通行密钥类型。这减少了失败或不合规的注册尝试，对于使用 AAGUID 受限配置文件（限制允许的通行密钥提供商）的组织尤为重要。
本地设备优先 — 在策略允许的情况下，注册将优先选择用户当前设备原生的通行密钥。这通过确保用户在正在使用的设备上注册设备绑定凭据（而非被引导使用另一台设备的同步通行密钥）来改善登录体验。
为何重要
已投资于通行密钥配置文件（尤其是仅设备绑定、强制证明或 AAGUID 受限配置）的组织可能在注册过程中遇到过摩擦。用户有时会尝试注册与管理员配置的配置文件不匹配的通行密钥类型，导致注册失败和工单激增。这些优化弥补了这一差距。
时间线与所需操作
- 推出时间： 2026年8月下旬（全球及 GCC）
- 用户界面变更： 无
- 管理员操作： 无
- 影响范围： 所有通过 Registration Campaign、Authentication Strengths 或 My Sign-Ins 注册通行密钥的用户
这是一项幕后改进，无需任何配置更改即可让通行密钥流程更加顺畅。如果您目前正在规划9月的通行密钥迁移（赶在2027年2月 SMS/语音验证停用之前），这些优化将有助于减少注册摩擦。
Entra 租户治理：集中式多租户管理（预览版）
作为7月30日发布的"2026年7月 Microsoft 安全新增功能"博客的一部分，Entra 租户治理（Entra Tenant Governance）现已出现在 Entra 管理中心，并开放预览。该功能解决了管理多个 Entra 租户的组织长期以来的痛点。
功能概述
租户治理建立了治理关系（governance relationships）——治理租户与一个或多个被治理租户之间的定向连接。这带来了：
- 跨租户委派管理 — 管理员使用治理租户中的账户登录。无需在每个被治理租户中创建和管理本地或 B2B 管理员账户。
- 租户配置管理 — 利用委派访问确保被治理租户持续满足组织的安全和合规目标。
- 安全租户创建 — 从现有租户创建的新增租户会自动获得带有默认策略模板的治理关系。
工作原理
建立治理关系需要三步握手流程：
- 未来的被治理租户向未来的治理租户发送治理邀请（governance invitation）。
- 未来的治理租户发送带有所选治理策略模板的治理请求（governance request）。
- 未来的被治理租户审查并接受该请求，从而建立治理关系。
治理策略模板
模板是租户治理的构建基石。每个模板定义：
- 委派管理角色 — 治理租户的用户在被治理租户中拥有哪些内置 Entra 角色。通过治理租户中的组进行分配。
- 多租户应用程序 — 可在被治理租户中创建和管理的自定义多租户应用。
模板可在多个治理关系中重复使用，确保访问策略的一致性。创建关系时，租户治理会对模板进行快照——更新模板不会自动更新现有关系。应用更新需要重复请求和接受流程，确保被治理租户始终有机会审查权限变更。
与现有工具的区别
| 功能 | Azure Lighthouse | Entra 租户治理 |
|---|---|---|
| 方向 | 将客户资源向上投影到提供商 | 将提供商身份向下投影到客户 |
| 上下文 | 提供商在自己的上下文中管理 | 提供商主体在客户租户内可用 |
| 范围 | Azure 资源 | Entra 目录角色 + RBAC |
| 主要用例 | CSP/MSP 场景 | 通用多租户管理 |
新增了一个**租户治理管理员（Tenant Governance Administrator）**角色（模板 ID：1981f584-96e9-4a6f-95b0-f522373f8fae），用于管理所有租户治理功能。
为何重要
对于拥有多个 Entra 租户的组织——无论是因收购、子公司结构还是测试/生产环境分离——租户治理消除了在每个租户中维护独立管理员账户的运营开销。三步握手流程确保双方对安排达成共识，而策略模板方法提供了一致、可审查的访问控制。
Kerberos RC4 最终强制实施：截止日期已过
2026年7月14日标志着 Kerberos RC4 弃用的不归点。随着7月补丁星期二更新，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 的唯一方法是在该单个账户上显式设置包含 RC4 位的 msDS-SupportedEncryptionTypes——Microsoft 强烈不鼓励这种做法。如果您尚未审计服务账户，请今天就完成。
Entra-Defender 融合：SOC 身份响应
7月30日的"Microsoft 安全新增功能"博客还重点介绍了 Microsoft Entra 与 Microsoft Defender 之间更深的融合，这是基于2026年6月推出的 SOC Identity Responder（SOC 身份响应者）角色。
新增内容
互联互通的 Entra 和 Defender 体验现在提供：
- 直接从 Defender 进行身份遏制 — SOC 分析师可以使用最小权限 RBAC 模式直接从 Defender 门户禁用受损身份，无需广泛的 Entra 管理员角色。
- 共享用户体验 — 身份与访问管理团队和 SOC 团队共享相同的用户体验，消除了产品之间的割裂。
- 智能体工作流（Agentic workflows） — 两个团队都能受益于跨越身份和安全运营的智能体工作流，从而简化事件响应。
SOC Identity Responder 角色
SOC Identity Responder 角色（2026年6月作为公共预览版推出）是这一融合的基础。它提供：
| 能力 | 说明 |
|---|---|
| 禁用/启用用户账户 | 在活跃入侵期间即时阻止横向移动 |
| 撤销活动登录会话 | 使刷新令牌失效，实时终止攻击者会话 |
| 重置密码 | 让一线响应人员立即对受损账户采取行动 |
| 限定管理单元范围 | 支持区域性或细分响应团队 |
角色模板 ID： 58f930cc-fcf4-4152-852c-1d7dbf502139
权限：
microsoft.directory/users/disablemicrosoft.directory/users/enablemicrosoft.directory/users/invalidateAllRefreshTokensmicrosoft.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日之前 |
| 中 | 针对多租户场景评估租户治理 | 预览现已可用 |
| 中 | 为安全分析师分配 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 官方新增功能页面。