2026 年 8 月 15 日至 18 日这一周，Microsoft Entra ID 发布了一系列重点文档更新。本周虽然没有重大的产品发布，但有两项更新对身份管理员具有重要的运维意义：一项是 Global Secure Access Web 筛选策略从 V1 迁移到 V2 的全新引导式迁移体验；另一项是 GitHub 灵活联合身份凭据（FIC）要求的收紧——现在必须包含不可变的存储库声明。本周还有四项文档更新：涵盖 MSA 账户的身份验证强度策略限制、ID Protection 设备阻止修复行为、适用于 Domain Services 的 sAMAccountName 同步，以及许可参考中的 Windows 10 ESU 服务计划标识符。以下是完整梳理。

1. GSA V1 到 V2 Web 筛选的引导式迁移体验

Microsoft 发布了一篇全新的操作方法文章，记录了将 Global Secure Access Web 内容筛选（V1）策略迁移到 Web 筛选（V2）对象模型的引导式迁移体验。这是 8 月 12 日发布的 V2 概念文章的运维对应部分，为管理员提供了一条具体、分步的路径，无需从头重建即可迁移现有策略。

V1 与 V2 之间有哪些变化

V2 模型对 Global Secure Access 中 Web 筛选的工作方式引入了结构性变化：

  • 每个安全配置文件一个策略： V1 允许多个 Web 内容筛选策略链接到同一个安全配置文件。V2 将其整合为包含多个规则的单个策略，每个规则都有自己的操作（action）。
  • 默认操作： V1 策略没有默认操作——只有规则匹配时才会生效。V2 策略始终会产生结果，因为它定义了在没有规则匹配时应用的默认操作。
  • FQDN 目标： V2 中移除了独立的 FQDN 目标类型。FQDN 现在以 URL 目标的形式表示，遵循 URL 匹配逻辑。
  • 功能名称： V2 中“Web Content Filtering”（Web 内容筛选）更名为“Web Filtering”（Web 筛选）。

引导式迁移的工作原理

当您的租户符合条件时，迁移体验会以横幅形式显示在 Entra 管理中心的**安全配置文件（Security Profiles）**页面上。安全配置文件分为三组：

  1. 符合资格（Eligible）的配置文件： 至少有一个关联的 V1 策略且没有现有 V2 策略。这些可以自动迁移。
  2. 不符合资格（Ineligible）的配置文件： 已包含 V2 策略和 V1 策略。这些需要手动处理——要么先移除 V2 策略再迁移，要么手动处理迁移。
  3. 无需迁移： 没有任何关联 V1 策略的配置文件。无需任何操作。

当您启动迁移时，它会在一次操作中处理所有符合资格的配置文件。对于每个符合条件的配置文件，迁移会：

  • 创建一个新的、已启用的 V2 Web 筛选策略
  • 将每个关联的 V1 策略作为规则添加到 V2 策略下，保留其目标、操作和优先级
  • 将新的 V2 策略链接到安全配置文件并移除 V1 策略链接——确保过渡期间不会出现强制策略执行空档

迁移操作在运行一次后即被禁用，以防止重复迁移。

重要注意事项

  • 不同配置文件之间的评估行为不同： 由于 V1 和 V2 评估策略的方式不同，迁移后跨多个安全配置文件的综合结果可能会发生变化。迁移前请审查您的策略结构。
  • Conditional Access 引用仍然有效： 安全配置文件在 Conditional Access 会话控制中通过 GUID 引用，这些引用在 V1 到 V2 的过渡中可以无缝工作。
  • V1 策略仍然可以编辑： 迁移后，现有的 V1 策略可以编辑或删除，但一旦配置文件中存在 V2 策略，就无法再创建新的 V1 策略。要恢复 V1 编写模式，请从配置文件中移除所有 V2 策略。
  • 先决条件： 需要 Global Secure Access Administrator 角色。

对于任何使用 GSA Web 内容筛选的组织来说，这篇迁移指南都是必读内容。即使您还没有准备好迁移，了解 V2 模型及其与 V1 的差异也有助于您规划过渡策略。

2. GitHub 灵活联合身份凭据现在要求不可变的存储库声明

Microsoft 更新了灵活联合身份凭据（FIC）的预览文档，要求 GitHub 配置匹配 sub 声明并且至少匹配一项不可变声明：repository_id 或 repository_owner_id。这一收紧措施堵住了一个安全漏洞——此前联合信任可能绑定到可变的存储库和所有者名称，而非永久标识符。

为什么这很重要

GitHub 存储库和所有者名称可以被重复使用。如果存储库被重命名或账户被删除，另一个存储库或账户可能会占用相同的名称。仅依赖基于名称的主体标识符（repo:owner/repo:ref:refs/heads/main）的联合身份凭据仍然容易受到这种名称重用情况的影响。

不可变标识符——repository_id 和 repository_owner_id——是 GitHub 分配的永久数字 ID，即使名称发生变化，它们也永远不会改变，也永远不会被重用。通过在灵活 FIC 配置中要求这些标识符，Microsoft 确保无论名称如何更改，联合信任始终绑定到原始存储库。

配置示例

GitHub 灵活 FIC 表达式现在看起来像这样：

claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*' and claims['repository_id'] eq '456789'

若要另外将凭据绑定到特定所有者：

claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*' and claims['repository_id'] eq '456789' and claims['repository_owner_id'] eq '123456'

每个声明支持的运算符：

  • sub：eq 和 matches
  • job_workflow_ref：eq 和 matches
  • repository_id：eq
  • repository_owner_id：eq

无论 sub 使用基于名称、自定义还是不可变格式，此要求都适用。门户、Microsoft Graph 和 CLI 示例均已更新，以通过 languageVersion: 1 反映新要求。

更广泛的背景：MC1447671 迁移

此次文档更新补充了 2026 年 8 月 5 日发布的 MC1447671 Message Center 通知，该通知建议各组织将 GitHub Actions 联合身份凭据迁移到不可变的主体格式。该通知的要点：

  • 2026 年 7 月 15 日之后创建的存储库会自动使用不可变的默认主体格式（包含使用 @ 分隔符的 owner_id 和 repo_id）
  • 2026 年 7 月 15 日之前创建的存储库保留基于名称的格式，除非通过 OIDC 设置选择启用
  • 2026 年 7 月 15 日之后的存储库重命名和转移会自动切换到不可变格式
  • 迁移方法：在现有凭据旁边创建第二个联合凭据，进行测试，然后删除旧凭据

灵活 FIC 要求在不可变主体迁移之上增加了一层额外的安全保护：直接在声明匹配表达式中验证不可变声明，而不是仅依赖主体格式。

如果您的组织将 GitHub Actions 与 Entra 联合身份凭据一起使用，请立即审查您的配置，确保其中包含所需的不可变存储库声明。

3. 身份验证强度策略无法应用于通过 MSA 进行身份验证的外部用户

更新后的 Entra ID 文档明确指出，身份验证强度策略目前无法应用于通过 Microsoft 个人账户（MSA）进行身份验证的外部用户。当管理员需要为这些外部用户强制实施多重身份验证时，应使用 Conditional Access 中的 MFA 授权控制（MFA grant control），而不是身份验证强度策略。

这是对现有限制的文档澄清，并非新引入的产品行为。不过，对于在 B2B 协作场景中使用身份验证强度策略、且外部用户通过 Microsoft 个人账户（Outlook.com、Hotmail 等）进行身份验证的组织来说，这一点非常重要。如果您配置了身份验证强度策略并期望它们适用于所有外部用户，请确认通过 MSA 进行身份验证的来宾用户已由单独的 MFA 授权控制策略覆盖。

4. ID Protection 设备阻止修复行为已修订

Identity Protection 文档已更新，以纠正将 Entra 设备作为修复（remediation）一部分禁用时所描述的行为。修订后的指南指出，禁用 Entra 设备会：

  • 阻止该设备签发新令牌
  • 撤销与该设备关联的用户会话
  • 提示用户重新登录

之前的文档还提到会撤销绑定设备的刷新令牌——该表述已被移除。这是一次文档更正，而非行为变更。实际的修复行为没有改变；文档现在更准确地描述了实际发生的情况。

此次更新完善了 8 月 14 日的“攻击者添加的设备修复（Attacker-Added Device Remediation）”条目，其中 Identity Protection Policies 文章用“攻击者添加的设备（Attacker-added device）”术语取代了“设备禁用（Device disablement）”。如果您在内部记录了修复范围（例如用于 Runbook 或培训材料），请更新这些引用，移除刷新令牌撤销的相关表述。

5. 面向 Entra Domain Services 的 sAMAccountName 同步指南

同步文档现在包含与 Microsoft Entra Domain Services 同步 sAMAccountName 属性的增强指南。更新后的页面描述了同步流程，并链接到在 Domain Services 场景中配置 sAMAccountName 的专门指南。

这是对现有功能的文档补充。使用 Entra Domain Services、并因旧版应用程序兼容性或依赖 LDAP 的工作负载而需要 sAMAccountName 属性值的组织，应参考更新后的指南。

6. Windows 10 ESU 服务计划已添加到许可参考

Entra ID 许可服务计划参考（Licensing Service Plan Reference）已于 2026 年 8 月 14 日更新，在 Windows 365 Enterprise 和 Windows 365 Shared Use 条目中添加了 Windows 10 扩展安全更新（ESU）服务计划标识符。参考表和可下载的 CSV 文件已相应更新。

使用许可参考进行计划匹配、基于脚本的许可证分配或报告的管理员，应下载更新后的参考文件，并更新任何包含 Windows 365 计划的内部映射。除使用更新后的参考数据外，无需执行其他管理操作。

总结

2026 年 8 月 15 日至 18 日这一周的特点是文档精炼，而非新产品发布。最突出的两项内容是 GSA V1 到 V2 Web 筛选迁移指南——为管理员提供了迁移策略的具体路径——以及 GitHub 灵活 FIC 不可变声明要求——加强了 GitHub Actions 部署的联合身份安全。

虽然文档更新看起来不如功能发布影响大，但它们往往会产生真实的运维后果。GSA 迁移指南决定了组织如何过渡其 Web 筛选架构，而 GitHub FIC 要求改变了哪些信任配置是有效的。两者都值得负责这些工作负载的身份管理员关注。

如需持续了解 Microsoft Entra ID 的变更，请关注 https://x.com/kkaminsk 并每周回来查看更新。

本文基于 2026 年 8 月 15 日至 18 日期间的 Microsoft Learn 文档更新、Entra.News Daily 摘要和 M365 Message Center 公告。如需查看 Microsoft Entra 官方发布与公告页面，请访问 learn.microsoft.com/en-us/entra/fundamentals/whats-new。