一、先把边界画出来

理解 Azure 的组织关系时，适合分别看身份、资源授权与计费边界：Entra 租户管理身份，Azure 订阅承载资源及其 Azure 角色分配，计费账户记录费用归属。三者彼此关联，但职责并不相同。

        身份树（认证）                    资源树（授权）                  计费树（账单）

   ┌──────────────────────┐        ┌──────────────────────┐       ┌──────────────────────┐
   │ Microsoft Entra tenant│        │ 管理组 root（=租户ID） │       │ 计费账户（EA/MCA/MPA）│
   │ 目录 / 用户 / 应用 / 设备│        │  ├── 管理组            │       │  ├── 计费配置文件        │
   └──────────┬───────────┘        │  └── 订阅             │       │  └── 发票区 → 订阅      │
              │ 1 个订阅信任 1 个租户   └──────────┬───────────┘       └──────────┬───────────┘
              └──────────────► 订阅 ◄─────────────┘                          │
                                   ▲                                           │
                                   └───────────────────────────────────────────┘
                                        账单归属（与身份树相互独立）

图里的计费层级是示意图；实际层级和可用角色会随协议类型及账户配置而异。

《Associate or add an Azure subscription to your Microsoft Entra tenant》把这几种关系说明得很清楚：订阅是管理 Azure 资源与 Azure 角色分配的作用域，租户是包含用于登录和接收访问的身份的目录；Azure 角色控制 Azure 资源的访问，Entra 角色控制用户、组和域等目录对象的访问。

一个订阅在同一时刻只关联一个目录；一个目录可以关联多个订阅。订阅的目录关联与账单归属是两件事：变更其中一项，不必然改变另一项。

判断某项访问的来源时，不能把某一边界的权限推断为相邻边界的权限。租户管理员与订阅 Owner 的职责不同，应根据显式授权关系分别核对身份、资源和计费。

二、租户与租户：没有自动的信任

租户代表组织在 Microsoft Entra ID 中的存在，全局租户管理员用它管理组织内应用与数据的访问。每个租户有唯一的租户 ID，和一个创建后不可更改的 *.onmicrosoft.com 初始域名。一个组织通常对应一个租户，但这只是惯例，不是约束。

关键在于租户之间的关系：默认没有自动的信任。A 租户的用户想访问 B 租户的应用，需要由资源租户通过支持的协作方式和策略授予访问。常见方式包括：

第一条是 B2B 协作。外部用户以 guest 身份被邀请进本租户后，B 租户里会生成一个 guest 对象。资源租户通常不管理 guest 的本地密码；用户通过其主租户或受支持的外部身份提供商完成认证，也可能使用已配置的其他兑换方式。UPN 通常包含外部用户邮箱、#EXT# 和资源租户的初始域，具体格式以目录中的对象属性为准。

第二条是跨租户访问设置。它分别控制入站与出站协作；资源租户可以配置是否信任来自特定外部租户的 MFA 或设备声明，并将受信任的声明用于本租户的条件访问评估。这些设置按访问方向配置，不要求双方一律互相建立相同的信任；如果双方都需要访问对方资源，则应分别核对两个方向的策略。

第三条是多租户组织与跨租户同步：同一组织出于合规或并购原因拆出的多个租户，用批量同步代替手工邀请。

guest 不等于“只读访客”。角色分配关联目录对象，而不是只看 UPN；guest 也可能被授予目录角色、资源权限或加入角色可分配组。审查外部访问时，我会同时核对 guest 对象的角色与组、权限范围，以及其主租户和跨租户策略。

计费与租户的对应关系这里也要说清，因为它常被想当然。MCA 签约时会选定一个 Entra 租户，新的计费账户只支持该租户的用户。而 EA 的结构又不一样：一个 enrollment 之下可以存在多个租户的账户，各自持有一部分订阅。也就是说，“计费组织”与“身份组织”的覆盖面经常不一致；用户也可能有权访问多个计费账户。具体关联应按协议类型与账户配置核实，不宜概括成固定的一对一或一对多。

三、租户与订阅：一纸目录信任

Azure 订阅关联一个 Microsoft Entra 租户，订阅依赖该目录来认证和授权安全主体与设备。订阅过期时，目录关联仍保留，但安全主体会失去对 Azure 资源的访问。一个订阅同一时刻关联一个目录，一个目录可以关联多个订阅。

还有一条不对称性值得单独记：当订阅的 Owner 把订阅加入一个已有租户时，这位 Owner 不会因此获得该租户的 Global Administrator；而创建租户的用户会自动成为该租户的 Global Administrator。方向是不对称的——身份树的根不因资源树的归属而扩张，资源树的 Owner 也不自动进入身份树。

3.1 改目录的代价

把订阅关联到另一个目录前，我会先查转移文档里的服务影响清单。Azure RBAC 角色分配和自定义角色会从源目录中永久删除，且不会自动复制到目标目录；系统分配的托管标识需要停用后重新启用，用户分配的托管标识需要在目标目录重建。Key Vault 的租户 ID 和访问策略也要更新。AKS 集群及相关资源不能直接转移到另一个目录，需要单独规划迁移。

转移订阅也不等于自动轮换所有资源凭据。存储访问密钥、管理证书或虚拟机本地账户等独立凭据应按各自机制检查和轮换；同时，源目录的角色分配与自定义角色必须在目标目录按需重建。CSP 订阅不支持通过此流程更改目录，转移前应先确认订阅类型。

目录转移会清理角色分配，但不会自动轮换所有独立凭据。做迁移验收时，我会另外检查存储密钥、管理证书和虚拟机本地账户，并按组织流程轮换仍在使用的凭据。

3.2 Global Administrator 的提权桥

这是两套体系之间最重要的一条官方通道。

默认情况下，Entra 角色与 Azure RBAC 分开授权，Global Administrator 并不自动拥有 Azure 资源权限。但 Global Administrator 可以使用 elevate access，在 Azure 根作用域为自己提升 User Access Administrator 权限，并在租户关联的订阅和管理组上管理角色分配。该操作只影响当前用户；审计时应检查提升记录和根作用域分配，并在不再需要时撤销提升。

目录中的 Global Administrator
      │  打开 Access management 开关（elevateAccess）
      ▼
根作用域 / 上的 User Access Administrator
      │  在任意订阅、管理组上分配角色
      ▼
任意订阅的 Owner → 资源控制与数据面
这是一条需要显式启用的跨边界路径：Global Administrator 可以提升对 Azure 根作用域的访问，再由相应 Azure 角色管理资源。审查时，我会核对目录审计日志中的提权事件，以及根管理组上的角色分配；不要把普通的 Entra 角色或订阅角色误当成另一套系统里的权限。

四、订阅与组织：管理组与计费树

4.1 “组织”的三种含义

我建议在读微软文档时给“组织”这个词做三个标注。指 Entra 组织时，强调的是身份边界，就是租户本身；指 Microsoft 365 组织时，强调的是工作负载的归属，同样是租户；指计费组织时，说的是计费账户、EA enrollment 或 CSP 的客户组织，强调谁付钱。三者可以对齐也可以不对齐：企业协议和订阅配置可能涉及多个租户，组织中的用户也可能有权访问多个计费账户。

4.2 管理组

管理组是订阅之上的治理容器。每个目录有一个顶层管理组，即根管理组，其 ID 与租户 ID 相同；管理组和订阅形成层级结构，根管理组可用于目录关联订阅的策略和角色治理。根管理组不能被移动或删除；每个管理组或订阅在层级中只能有一个父节点。管理组上的策略与 RBAC 分配会按各自规则向下继承。层级深度和数量上限可能随服务规则变化，实施时应以当前管理组文档为准。

还有两条默认行为值得单独记：同一管理组内的所有订阅必须信任同一个 Entra 租户；默认情况下租户内任何主体都可以创建管理组，要收紧必须显式开启“要求授权”。同时文档也说明，没有任何人默认拥有根管理组的访问权限。

根管理组上的策略和角色分配会影响其下层级，因此我会连同管理组父子关系一起检查，而不只看根节点。若组织不希望所有主体都能创建管理组，应显式调整相应设置。

4.3 计费账户

计费树由计费账户定义。MOSP 即用即付账户是个人按量付费；EA 计费账户按企业协议签约，Enterprise Administrator 可以在任意活跃的 enrollment account 下创建订阅，Account Owner 可以在自己名下的 enrollment 上创建订阅；MCA 计费账户在签约时选定租户，订阅创建数量受账户类型、订阅配额和当前 Microsoft 规则约束；MPA 面向 CSP 伙伴，用于管理客户相关的计费与订阅。具体配额应以账户门户及适用的当前文档为准，不宜将某一账户的限额推广为所有账户的固定上限。

创建订阅的权限分布在计费树的各层：MCA 下需要发票区、计费配置文件或计费账户上的 Owner/Contributor，或发票区上的 Azure subscription creator 角色；EA 下需要 Enterprise Administrator 或 Account Owner。EA 文档里还有个细节：Account Owner 必须登录主租户才能创建订阅，以 guest 身份登录其他目录时即使角色齐全也不行——计费面本身也是一个身份边界。

计费权限不只是查看账单，部分计费角色也能创建订阅。新订阅的管理组位置决定它继承哪些策略和角色分配。建立订阅流程时，我会把落入哪个管理组、由谁接收通知、是否继承组织策略一并纳入验收。

4.4 移动订阅的三条路

只改目录时，账单归属可以保留，但角色分配和部分身份集成需要重新配置；转移账单则还会改变相应的计费关系。另一种做法是不移动订阅，而是通过 Azure Lighthouse 将订阅或资源组委托给另一个租户管理。做跨租户盘点时，我会分别核对本租户委托出去的资源，以及其他租户委托给本租户的资源。

五、两套角色：Entra 角色与 Azure RBAC

Azure 曾使用 Account Administrator、Service Administrator 和 Co-Administrator 等经典管理员角色；Azure RBAC 提供更细的资源访问控制，Entra 角色则管理目录对象。经典管理员角色已于 2024 年 8 月 31 日退役；2025 年 12 月，公有云中仍有 Co-Administrator 或 Service Administrator 分配的用户会被自动分配订阅范围的 Owner；从 2026 年 5 月起经典角色已完全退役，门户中的 Classic Administrators 页签也已移除。现在检查旧环境时，应核对自动转换生成的 Owner 分配是否仍然必要，并按最小权限原则调整。

两套系统管理不同对象，作用域也不同：Azure 角色控制 Azure 资源，Entra 角色控制 Entra 目录对象；Entra 角色可分配到租户、管理单元或特定对象，Azure RBAC 则可分配到管理组、订阅、资源组或资源。

维度Entra 角色Azure RBAC 角色
管理对象用户、组、应用、设备、策略VM、存储、网络、密钥库
管理面Microsoft Graph 与 Entra 管理中心Azure Resource Manager
作用域租户 / 管理单元 / 对象管理组 / 订阅 / 资源组 / 资源
常见边界关系与 Azure RBAC 分开授权；GA 可显式提升 Azure 访问与 Entra 目录角色分开授权

看到 Global Administrator，不应直接推断它已经拥有所有 Azure 资源权限；看到订阅 Owner，也不应推断它可以管理目录对象。Global Administrator 可以使用 elevate access 提升到 Azure 根作用域的访问权限。实际环境中还要分别检查服务委托、工作负载身份和应用权限等关系。

角色权限随角色定义和产品更新变化，下面按“完成某件事所需的最小角色”整理常用场景，不是完整权限清单；实际可执行的操作以当前的角色权限参考为准。

5.1 Entra 侧：场景与必须角色

  • 管理角色分配（含 PIM 的分配与角色设置）：Privileged Role Administrator。这是目录里“角色分配自由”的角色，本身应最先进入 PIM 管理。
  • 创建与管理应用注册、企业应用、应用凭据：Application Administrator；不需要应用代理时用 Cloud Application Administrator（权限相同但不含应用代理）。两者都不能管理条件访问，也都不能为 Azure AD Graph 和 Microsoft Graph 的应用权限做管理员同意——同意这两个 API 的应用权限需要 Privileged Role Administrator。
  • 管理认证方法策略、每用户 MFA、密码保护策略：Authentication Policy Administrator。
  • 修改普通用户的认证方法与敏感属性（UPN、删除/恢复）：Authentication Administrator，对持有特权角色的用户无效；对所有用户生效的版本是 Privileged Authentication Administrator。
  • 重置非管理员密码、吊销用户刷新令牌、读取设备 BitLocker 恢复密钥：Helpdesk Administrator（Azure 门户中的旧名是 Password Administrator）。
  • 创建用户、管理全部组、分配许可证、重置非管理员密码：User Administrator；不能管理 MFA，也不能管理共享邮箱。
  • 管理 Entra Connect、PTA、PHS、Seamless SSO、联合设置：Hybrid Identity Administrator（不含 Entra Connect Health）。
  • 条件访问：Conditional Access Administrator 或 Security Administrator。
  • 读取 Entra 加入设备的本地管理员密码（Windows LAPS）：Cloud Device Administrator 或 Intune Administrator；Helpdesk Administrator、Security Administrator、Security Reader 只能读取元数据，读不到密码。
  • Intune 的设备策略与合规：Intune Administrator。
  • Exchange 组织配置：Exchange Administrator；管理组织级配置，不等于能读邮件内容。
  • 购买与账务操作：Billing Administrator。

5.2 Azure RBAC 与计费侧：场景与必须角色

  • 分配 Azure 角色：Owner、User Access Administrator，或 Role Based Access Control Administrator。三者都包含 Microsoft.Authorization/roleAssignments/write，都能把主体加为 Owner；RBAC Administrator 的限制是不能用 Azure Policy 等其他方式管理访问。Contributor 不能分配角色——拿到 Contributor 试图管理 RBAC 是最常见的权限误判。
  • 用 Entra 凭据访问 blob 数据：需要数据面角色（Storage Blob Data Reader / Contributor / Owner）加上管理面 Reader 或更高的存储管理角色。只拿 Contributor 读不了数据：控制平面权限不含数据平面。
  • 用账户密钥访问数据：需要 Microsoft.Storage/storageAccounts/listkeys/action，内置角色中 Contributor、Owner、Storage Account Contributor、Reader and Data Access 包含该操作。这是与数据面角色并行的第二条数据通路——持有 listkeys 权限即可换出账户密钥，绕过 Entra 数据面授权。
  • Key Vault 机密与密钥的数据面：Key Vault Secrets Officer / Crypto Officer 这类数据面角色；管理访问策略走控制面权限。
  • 创建 MCA 订阅：发票区、计费配置文件或计费账户上的 Owner 或 Contributor，或发票区上的 Azure subscription creator；creator 只能取消自己创建的订阅。
  • 创建 EA 订阅：Enterprise Administrator 或 Account Owner（须以主租户身份登录）。
  • 根管理组上的角色分配：默认无人拥有；需先在根作用域获得 Owner 或 User Access Administrator（Global Administrator 走 elevate access）。

5.3 容易被忽略的边界

第一，Application Administrator 与 Cloud Application Administrator 可以为应用添加凭据，并用凭据扮演该应用的身份；如果应用标识被授予过创建或更新用户等权限，角色持有者就能借应用身份执行自己角色之外的操作。角色说明明确将这一点标注为相对角色分配的权限提升。授予这两个角色，等于授出该租户全部应用身份的钥匙。

第二，Authentication Administrator 的可操作对象包含四类高价值账户：应用注册与企业应用所有者（可管理自己应用的凭据）、Azure 订阅 Owner、安全组与 M365 组 Owner，以及 Exchange Online、Defender 门户、Purview 门户等其他门户的管理员。修改这些账户的认证方法即等于接管其身份；这四类对象应列入重点监控。

第三，Windows LAPS。Cloud Device Administrator 与 Intune Administrator 可直接读取 Entra 加入设备的本地管理员密码；Helpdesk 与 Security Administrator 只有元数据。可读取本地管理员密码的角色，本身就是一条直达设备的路径。

第四，Contributor 的双面性：它管理所有资源，但既不能分配角色，也不含存储数据面权限；可它包含 listkeys——能换出账户密钥。评估 Contributor 的实际权限要按两条通路计算：控制面操作，加账户密钥数据访问，缺一条都会低估。

第五，计费角色与 Azure RBAC 互不包含。把人加为计费配置文件 Owner，给的是看发票、管付款、在发票区上创建订阅的能力，不给任何 Azure 资源权限；反过来订阅 Owner 也不自动获得发票区权限。两棵树的授权面要分别盘点。

PIM 可以把角色分配拆成“符合条件”与“激活”。符合条件的分配通常要经过激活才生效；激活时是否要求 MFA、审批或理由，取决于具体 PIM 设置。我审查权限时会同时看长期分配、符合条件的分配、激活策略和审计记录，而不会只凭 Eligible 状态推断实际保护强度。

六、工作负载身份：应用、服务主体与托管标识

应用对象是应用在 Microsoft Entra ID 中的全局表示，住在应用的“主租户”；服务主体是应用在特定租户中的本地表示，决定该应用在这个租户里能做什么、谁能访问它、它能访问什么资源。注册应用时主租户自动创建服务主体；多租户应用在每个同意它的租户里各有一个服务主体。服务主体有三种类型：Application、Managed identity（托管标识）和 Legacy。

应用凭据有三种常见形态：client secret、证书、以及用于工作负载身份联合的联合身份凭据。应用所有者可以管理其应用的凭据；Application Administrator 和 Global Administrator 也可管理应用，但具体凭据、权限和同意操作受角色权限及应用类型等限制。多租户应用只能在已完成相应同意、并被授予权限的租户中按其权限运行；仅有应用凭据并不意味着自动获得所有租户或资源的访问权。

审查应用身份时，我会核对近期新增或即将过期的凭据、企业应用的租户同意记录，以及应用被授予的高权限 API 权限。权限名称和风险范围会随 API 与权限类型而异，因此应回到当前的权限说明，确认具体应用实际需要什么，而不是只凭名称判断。

托管标识是服务主体的一种特殊形态：只有服务主体对象，没有应用对象。系统分配的托管标识生命周期绑定到资源，资源删除则标识删除，且只能被该资源使用；用户分配的托管标识是独立资源，可挂到多个资源上。凭据由平台托管，应用不需要持有或轮换 client secret。资源通过 Azure Instance Metadata Service 等受支持的端点请求令牌；使用多个用户分配标识时，需要明确指定要使用的标识。托管标识不能像普通用户一样交互登录；订阅目录转移会影响标识，通常需要重新启用系统分配标识，并在目标目录重建用户分配标识。

托管标识避免了应用自行保存和轮换长期凭据，但仍应按其被授予的资源权限进行审计。对托管标识，我会同时检查它能访问哪些资源、权限是否超出工作负载需要，以及哪些身份可以修改或在关联资源上运行代码；令牌的有效权限由身份分配和目标服务的授权共同决定。

把三类常见工作负载身份放在一起看：service principal 的凭据由应用所有者或管理员管理；托管标识的凭据由平台管理；被当作服务账号用的普通用户仍是用户身份，可能参与交互式登录。三者的凭据管理和审计方式各不相同，不应把它们都视为非交互身份或假定它们不会产生登录记录。

七、本地域控的 TGT 与云上的“域”

7.1 Kerberos 的基本构造

Windows Kerberos 是三方协议：代表安全主体的客户端、目标服务、双方都信任的 KDC。KDC 作为域服务运行在每台域控上，用 AD DS 数据库做账户数据库。用户登录时，Kerberos 客户端向 KDC 证明身份并取得 TGT——TGT 是一种凭据，让客户端请求服务访问时无需再次出示用户密码；客户端把它存进票据缓存，复用直到过期。

取得 TGT 的过程分三步：KDC 先生成一个登录会话密钥，用用户的主密钥加密一份发给客户端；再把会话密钥的副本与用户的授权数据嵌进 TGT，用 KDC 自己的主密钥（KRBTGT 账户密钥）加密。客户端用从用户密码派生的密钥解开会话密钥，把 TGT 原样存进缓存。之后访问任何服务，都是拿 TGT 向 KDC 换取用目标服务密钥加密的服务票据，再把服务票据直接出示给服务——服务因为能用自己的密钥解开票据而无需联系域控。在默认域策略下，Windows TGT 生命周期通常约为十小时；受保护用户组及域策略可能缩短票据生命周期或限制续期行为，具体以当前域策略为准。

KRB_AS_REQ（预认证）→ KDC 签发 TGT（KRBTGT 密钥加密）+ 会话密钥（用户密钥加密）
      │
      ▼
KRB_TGS_REQ（出示 TGT）→ KDC 签发服务票据（目标服务密钥加密）
      │
      ▼
AP_REQ（出示服务票据）→ 服务解密校验，全程不再需要用户密码

整个构造的安全前提可以浓缩成一句话：票据由对应密钥加密，KDC 与目标服务分别依赖各自可用的密钥材料来签发或验证票据。KRBTGT 密钥由域控制器用于保护 TGT；服务账户密钥由 AD DS 管理并供 KDC 和相应服务用于服务票据流程；用户密钥用于客户端认证。后续的安全风险取决于这些密钥材料如何保护与使用。

7.2 Entra ID 不是 Kerberos 域

这是我认为理解云身份很有用的一条边界：Entra ID 本身不是本地 AD 域控，不使用本地域的 KRBTGT 来签发票据。Entra 支持 OAuth 2.0、OIDC 与 SAML 等协议。粗略区分令牌时，可以把 access token 看作发给特定 API 或资源的访问凭据，把 refresh token 看作在策略允许时用于获取新令牌的凭据，把 PRT（Primary Refresh Token）看作受支持设备上的 SSO 凭据。令牌寿命和可访问范围取决于令牌类型、目标资源与策略，不能一概说成固定的一小时。

PRT 的定义是：专门签发给微软第一方 token broker 的安全工件，用于在设备上跨应用实现单点登录；它携带设备与用户声明，供条件访问评估。PRT 通常签发后有效期九十天，Windows 上由 CloudAP 在用户持续使用设备时每四小时尝试续期。边界同样明确：PRT 支持的是 SSO 流程，实际能访问哪些应用，仍受用户授权、设备状态与条件访问策略约束。

严格地说，云上没有“TGT 的等价物”，但 PRT 之于设备 SSO 与 TGT 之于域内 SSO 可以作有限的功能类比。两者的协议与安全机制不同：KRBTGT 密钥泄露会带来伪造 Kerberos 票据的风险；PRT 流程则依赖设备密钥及其证明机制，不能简单套用 Kerberos 的离线伪造模型。PRT 相关风险应按令牌类型、设备保护和身份平台的验证流程具体评估。

7.3 云上的三个“域”

混着“域”这个字的三样东西必须分开。

第一是 Entra Kerberos：它让 Microsoft Entra ID 在受支持场景中充当 Kerberos KDC，域名为 KERBEROS.MICROSOFTONLINE.COM。相关 Cloud TGT 用于特定 Kerberos 工作负载，例如 Azure Files、Azure Virtual Desktop，以及 Azure SQL Managed Instance 的 Windows 身份验证。票据密钥与配置细节因工作负载而异，不应概括成所有云资源都使用同一种服务主体密钥解密。支持范围是列举式的，不是泛指所有 Azure 服务。

第二是 OnPremTgt。在配置了相应混合身份与 Entra Kerberos 流程的场景中，Entra 可以签发用于本地资源访问的“部分 TGT”：它包含用户 SID，但不含完整的本地组信息，本身不足以直接访问本地资源；后续由本地 KDC 按域内配置和授权处理 Kerberos 访问。具体票据交换流程及可访问资源取决于部署，不能把它概括成所有环境都适用的“兑换完整票据后访问 SMB/SQL”步骤。同步、Kerberos 服务器对象和域控配置等前置条件也需按具体部署核实。文档同时提醒，krbtgt_AzureAD 这类 Entra Kerberos 相关的敏感账户不应同步进本地。

第三是 Entra Domain Services：微软托管的真 AD DS 域，有真实的 KRBTGT。它与 Entra ID 是两种东西，只是名字容易让人误以为是同一个。

Cloud TGT 与本地 TGT 不能互相伪造。在适用的混合配置中，PRT 可参与获取 OnPremTgt 的流程；本地后续的票据签发与资源访问，仍由域控配置和授权策略决定。这条链让“云身份”有可能访问本地资源，但它不是默认存在的通道。核对部署时，我会确认 Cloud Kerberos Trust 是否启用、Kerberos 服务器对象所在的域，以及敏感账户是否按文档要求排除在同步范围之外。

八、混合身份：本地 AD 接进云的五条路

企业可能通过目录同步、直通认证、联邦、无缝 SSO 或 Entra Kerberos 等方式连接本地 AD 与 Entra。微软的《Protect Microsoft 365 from on-premises attacks》提醒，混合部署会把本地基础设施与云端身份连接起来，因此本地认证组件、同步范围和联邦信任都需要纳入云安全审查。下面我按每种机制的工作方式、信任位置和防守检查点来梳理。

8.1 密码哈希同步（PHS）

PHS 会从本地 AD 获取密码哈希，经额外处理后同步到 Entra 的认证服务。Microsoft Learn 当前说明，密码哈希同步每两分钟运行一次，密码变更通常在几分钟内反映到云端。正常的本地密码变更会更新云端哈希；管理员若直接在 Entra 重置密码，该值可暂时覆盖同步值，直到本地密码再次变更并同步。它同步的是密码哈希材料，不是明文密码。

在 Entra Connect Sync 的实现中，同步代理通过 MS-DRSR 向域控请求存储的 unicodePwd 哈希属性；AD DS Connector 账户需要相应的目录复制权限。官方流程说明，代理不会接触明文密码，云端保存的也不是本地 AD 原始 MD4 哈希。正因为这项同步需要高敏感权限，Entra Connect Sync 服务器和相关同步账户应按 Tier 0 资产保护。审查时，我会限制服务器管理员范围、监控配置变更、复核同步范围，并确认同步对象没有不必要的云端特权。若环境使用 Entra Cloud Sync，则应按该部署方式对应的当前文档核对组件与权限。

还有一项容易漏掉的生命周期边界：Microsoft Learn 说明，accountExpires 属性不会同步到 Entra。若组织用 AD 账户到期时间管理离职或临时账户，不能假设只设置这个属性就会自动停用云账户；还要确认云端停用、会话撤销和离职流程覆盖到位。

8.2 直通认证（PTA）

PTA 的核心是由本地认证代理向 Active Directory 验证登录请求。代理注册后，Entra 使用代理的公钥保护请求中的凭据，再经队列发送；代理取回请求并在本地解密、验证，将结果返回 Entra。代理与服务之间保持连接，注册和通信也有相应的证书及队列访问控制。

因此，密码验证发生在本地，Entra 不会用明文密码自行完成验证；但登录流程仍涉及云端服务与加密传输，不能简单说“密码完全不经过云”。代理主机能参与认证决策，应按高敏感系统保护，并同时检查云端 Smart Lockout 与本地账户锁定策略。

审查混合认证时，应先确认租户采用 PHS、PTA 还是联邦登录，再检查对应的服务器、同步账户、证书和登录策略。认证模式决定信任所在的位置，但不会自动消除其他模式下的凭据风险。

8.3 ADFS 联邦

配置联邦认证后，用户登录会转到组织的身份提供方，例如本地 ADFS；Entra 根据双方配置的信任关系验证返回的令牌。令牌签名证书是这段信任的关键。如果签名私钥失陷，就可能伪造被信任的断言，这类风险常称为 Golden SAML。实际影响还取决于联邦配置、租户策略和令牌验证行为。

因此，联邦环境的防守重点是保护签名密钥及 ADFS 管理面，监控信任配置和证书变更，并评估仍需联邦的域与应用。是否迁移到 Entra 直认证，应结合组织架构、应用兼容性和微软当前迁移指引决定，不能概括成所有租户都应立即关闭联邦。

8.4 无缝 SSO（AZUREADSSOACC）

启用 Seamless SSO 时，Entra Connect 会在同步的 AD 林中创建 AZUREADSSOACC 计算机账户，并配置相应的 Kerberos SPN。该账户的 Kerberos 密钥会安全地共享给 Entra，以便支持特定网络和浏览器条件下的无缝登录。它是登录流程的一部分，不等同于可供所有应用通用的云端 Kerberos 认证。

微软建议严格限制该账户的管理权限、禁用 Kerberos 委派，并至少每 30 天轮换密钥。Seamless SSO 支持 AES 和 RC4 加密，微软建议使用 AES。另一个近期需要留意的变化是：从 2026 年 7 月的 Windows Server 更新开始，AD DS 的默认 Kerberos 加密类型改为 AES-256；如果 AZUREADSSOACC 仍依赖 RC4，应按微软当前迁移指引评估兼容性。若计划从 RC4 切换到 AES，微软要求先轮换该账户的 Kerberos 密钥，以免 SSO 中断。密钥或账户配置出问题会影响依赖 Seamless SSO 的用户，因此我会定期核对委派设置、加密类型、密钥轮换记录和相关管理操作。

我会把 Seamless SSO 看作一项有明确前置条件的登录集成，而不是所有 Kerberos 票据都能直接换成云令牌的“桥”。审计时应结合微软当前配置指引检查账户权限、委派属性和密钥轮换状态。

8.5 Cloud Kerberos Trust（OnPremTgt）

第五条路在 7.3 已经铺过底：在符合条件的混合部署中，Entra 可签发 OnPremTgt（部分 TGT），其中包含用户 SID，但不含完整组信息；它需要与本地域控完成交换，才能取得用于本地资源访问的完整 TGT。当前文档列出的前提包括：用户已同步、Kerberos 服务器对象已配置并同步、设备运行受支持的 Windows 版本且已 Entra 加入或混合加入、域控已满足要求，并且设备能与域控通信。此流程使用受支持的无密码登录方式，例如 Windows Hello for Business 或 FIDO2；用户还必须符合 RODC 对应的允许/拒绝策略。具体支持条件应以当前文档为准，并注意 Windows 版本的生命周期状态。

因此，Cloud Kerberos Trust 并不是任何云端用户都能默认访问本地资源的通道。审查时，我会先确认上述部署与设备条件，再核对 Kerberos 服务器对象、用户允许策略、域控配置和授权范围。

8.6 委派：三种信任配置

Kerberos 委派允许前端服务在满足条件时代表用户访问后端服务。理解三种配置时，我会先问清楚“谁决定前端能代表用户访问什么”。

  • 无约束委派：信任范围较宽，微软不建议在新设计中使用。若仍有遗留配置，应评估是否能移除或迁移到限制更明确的方案。
  • 约束委派：由前端服务配置允许代表用户访问的服务范围。
  • 基于资源的约束委派（RBCD）：由后端资源指定哪些前端服务可代表用户访问自己，适合需要由资源所有者管理委派关系的场景。

三种模型的设置位置、跨域行为和兼容性并不完全相同，具体行为应以当前 Windows Server 文档为准。审查时，我会清点委派范围、获准代表用户的服务主体、相关对象的管理权限，以及 AZUREADSSOACC 是否按 Seamless SSO 文档要求禁用了委派。目标是确认每一项委派都有明确业务用途和负责人。

8.7 五种机制的对照

把这些机制放在一起，我会从“验证在哪里发生、哪项配置值得检查”两个问题来比较：

                  本地 AD                          Microsoft Entra ID
             ┌──────────────────┐              ┌──────────────────────┐
   PHS       │ 密码哈希材料 ────┼─ 通常每2分钟 ►│ Entra 认证服务         │
   PTA       │ 本地 AD 验证 ◄───┼─ 认证代理通道 ┤ 加密请求队列          │
   ADFS      │ 身份提供方签名 ──┼─ SAML 断言 ──►│ 验证联邦信任          │
   SSO       │ AZUREADSSOACC ──┼─ Kerberos SSO ►│ 按配置验证登录        │
   CKT       │ 本地 KDC ◄──────┼─ OnPremTgt ───│ 受支持的混合流程      │
             └──────────────────┘              └──────────────────────┘

这些机制的信任材料各不相同：PHS 依赖目录同步权限，PTA 依赖认证代理，ADFS 依赖联邦签名证书，Seamless SSO 使用 AZUREADSSOACC，Cloud Kerberos Trust 则依赖 Kerberos 服务器对象与本地 KDC。微软建议保护云端管理员账户，并限制同步对象在云中的权限。我会把这两点与各机制自身的密钥、角色和配置审查结合起来。

九、票据与令牌：相似点和边界

9.1 本地 Kerberos 的风险面

本地 Kerberos 的安全依赖账户密钥、域控和服务配置。KRBTGT 密钥保护域内 TGT，服务账户密钥参与服务票据流程；预认证、密码强度和加密类型也会影响风险。这里不把具体票据技术当作操作步骤，而是把它们归纳成防守问题：哪些密钥或账户是高价值对象，哪些配置不符合组织基线，异常认证是否能在域控与终端日志中关联起来。

如果怀疑 KRBTGT 密钥泄露，应依照 Microsoft 的恢复指引规划分阶段重置，并考虑域控复制与现存票据的有效期；单纯禁用用户或修改一个用户密码，不足以作为域级事件的完整恢复方案。

9.2 云令牌与设备状态

PRT 与 Kerberos TGT 都能支持单点登录，但不是同一种凭据。PRT 的有效期为 90 天；Windows CloudAP 在用户登录时每四小时尝试续期，用户持续使用设备时会持续续期。组织仍可通过条件访问中的登录频率等会话控制要求用户重新验证。PRT 依赖受支持设备和平台验证流程，不能简单视为可离线伪造或对所有资源通用的 bearer token。

令牌泄露后的影响取决于令牌类型、设备绑定、目标资源授权和条件访问策略。设备注册、设备合规和用户认证是不同状态；审查时我会逐一确认策略对目标应用如何生效，而不把其中一个状态当作另一个状态的替代。

9.3 混合环境的审查方法

我会把混合认证看成多条有条件的信任关系，而不是一条笼统的“本地到云”通道。对每种实际启用的机制，记录它依赖的组件、账户、密钥、同步范围和策略，再确认谁负责维护、如何监控、失陷后如何恢复。云到本地的 Entra Kerberos 流程还需另外核对设备与用户前提、RODC 策略和域控配置。

9.4 日志与检测

没有单一事件能证明一次攻击或排除风险。审查时我会把 Entra 审计与登录日志、Azure 活动日志、域控安全日志、设备状态、同步组件日志和联邦服务日志按时间关联起来。Global Administrator 的 elevate access、角色分配变化、同步配置变化、AZUREADSSOACC 密钥与委派管理、异常的设备或令牌活动，都应结合操作者、来源、目标和变更窗口判断。

klist cloud_debug 可用于排查 Windows 设备上的 Cloud TGT 状态，但它只是诊断信息，不是安全事件的充分证据。Defender for Identity、Entra 和其他安全产品的检测范围会随许可、配置及产品更新变化；我会对照当前产品文档和租户实际启用的检测能力，而不假设某种技术必然有固定告警。

十、我会怎样复核这套架构

学完这些概念后，我建议按清单复核自己的环境，而不是背一份固定的“攻击顺序”：

  • 记录每个订阅关联的租户、管理组位置和计费归属；确认目录迁移、CSP 限制及各资源的迁移影响。
  • 分别盘点 Entra 目录角色、Azure RBAC 与数据面角色；检查根管理组和 Global Administrator 的 elevate access。
  • 复核 guest、跨租户访问设置、应用同意、应用凭据和托管标识的授权范围。
  • 核对计费角色是否确有创建订阅的业务需要，并确认新订阅进入组织规定的管理组和策略范围。
  • 识别实际部署的 PHS、PTA、ADFS、Seamless SSO 与 Cloud Kerberos Trust，只检查环境中启用的配置。
  • 保护同步服务器、认证代理、联邦签名材料和 AZUREADSSOACC；审查同步范围、密钥轮换和委派。
  • 复核 PRT、设备加入/合规、条件访问和登录频率策略，并确认日志保留与告警范围符合当前许可。

本文的角色状态与产品行为按 Microsoft Learn 于 2026-10-27 核对；租户配置、许可和服务更新可能改变可用能力，遇到具体部署时应以文末链接的现行文档为准。

本文梳理身份、资源与账单边界，以及本地与云之间常见的混合认证方式。Microsoft 365 与 Azure 的具体关系、Copilot 的数据访问边界，以及 Sentinel、Purview、Defender 与 Intune 等服务，见《Microsoft 365、Copilot 与安全控制面》。

十一、参考

本篇梳理所依据的原始文档与研究，观点均以原文为准：

  • Microsoft Learn：Associate or add an Azure subscription to your Microsoft Entra tenant — https://learn.microsoft.com/entra/fundamentals/how-subscriptions-associated-directory
  • Microsoft Learn：Transfer an Azure subscription to a different Microsoft Entra directory — https://learn.microsoft.com/azure/role-based-access-control/transfer-subscription
  • Microsoft Learn：What are Azure management groups? — https://learn.microsoft.com/azure/governance/management-groups/overview
  • Microsoft Learn：Billing accounts and scopes in the Azure portal — https://learn.microsoft.com/azure/cost-management-billing/manage/view-all-accounts
  • Microsoft Learn：Understand Microsoft Customer Agreement administrative roles in Azure — https://learn.microsoft.com/azure/cost-management-billing/manage/understand-mca-roles
  • Microsoft Learn：Create an Enterprise Agreement subscription — https://learn.microsoft.com/azure/cost-management-billing/manage/create-enterprise-subscription
  • Microsoft Learn：Azure roles, Microsoft Entra roles, and classic subscription administrator roles — https://learn.microsoft.com/azure/role-based-access-control/rbac-and-directory-admin-roles
  • Microsoft Learn：Azure classic subscription administrators — https://learn.microsoft.com/azure/role-based-access-control/classic-administrators
  • Microsoft Learn：Elevate access to manage all Azure subscriptions and management groups — https://learn.microsoft.com/azure/role-based-access-control/elevate-access-global-admin
  • Microsoft Learn：Microsoft Entra built-in roles — https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference
  • Microsoft Learn：Least privileged roles by task in Microsoft Entra ID — https://learn.microsoft.com/entra/identity/role-based-access-control/delegate-by-task
  • Microsoft Learn：Delegate app roles（Application/Cloud Application Administrator 的凭据与提权警告） — https://learn.microsoft.com/entra/identity/role-based-access-control/delegate-app-roles
  • Microsoft Learn：Windows Local Administrator Password Solution in Microsoft Entra ID（读取本地管理员密码的角色矩阵） — https://learn.microsoft.com/entra/identity/devices/howto-manage-local-admin-passwords
  • Microsoft Learn：Steps to assign an Azure role（Owner / User Access Administrator / Role Based Access Control Administrator） — https://learn.microsoft.com/azure/role-based-access-control/role-assignments-steps
  • Microsoft Learn：Choose how to authorize access to blob data（数据面角色与管理面 Reader 的组合） — https://learn.microsoft.com/azure/storage/blobs/authorize-data-operations-portal
  • Microsoft Learn：Troubleshoot Azure Blob Storage access issues（listkeys 权限矩阵） — https://learn.microsoft.com/troubleshoot/azure/azure-storage/blobs/authentication/storage-troubleshoot-portal-access-issues
  • Microsoft Learn：Application and service principal objects in Microsoft Entra ID — https://learn.microsoft.com/entra/identity-platform/app-objects-and-service-principals
  • Microsoft Learn：What is managed identities for Azure resources? — https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/overview
  • Microsoft Learn：Protect Microsoft 365 from on-premises attacks — https://learn.microsoft.com/entra/architecture/protect-m365-from-on-premises-attacks
  • Microsoft Learn：Implement password hash synchronization with Microsoft Entra Connect Sync — https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-password-hash-synchronization
  • Microsoft Learn：Microsoft Entra Cloud Sync overview — https://learn.microsoft.com/entra/identity/hybrid/cloud-sync/what-is-cloud-sync
  • Microsoft Learn：Microsoft Entra pass-through authentication: Technical deep dive — https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-pta-how-it-works
  • Microsoft Learn：Microsoft Entra pass-through authentication security deep dive — https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-pta-security-deep-dive
  • Microsoft Learn：Kerberos authentication troubleshooting guidance — https://learn.microsoft.com/troubleshoot/windows-server/windows-security/kerberos-authentication-troubleshooting-guidance
  • Microsoft Learn：Kerberos Constrained Delegation Overview（RBCD 跨域与信任决定权） — https://learn.microsoft.com/windows-server/security/kerberos/kerberos-constrained-delegation-overview
  • Microsoft Learn：Understanding Primary Refresh Token (PRT) — https://learn.microsoft.com/entra/identity/devices/concept-primary-refresh-token
  • Microsoft Learn：Introduction to Microsoft Entra Kerberos — https://learn.microsoft.com/entra/identity/authentication/kerberos
  • Microsoft Learn：Microsoft Entra seamless single sign-on: Technical deep dive — https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-sso-how-it-works
  • Microsoft Learn：Kerberos authentication overview in Windows Server — https://learn.microsoft.com/windows-server/security/kerberos/kerberos-authentication-overview
  • Microsoft Learn：Key Distribution Center — https://learn.microsoft.com/windows/win32/secauthn/key-distribution-center
  • Microsoft Learn：Microsoft Defender for Identity overview（检测阶段矩阵） — https://learn.microsoft.com/defender-for-identity/what-is
  • Microsoft Learn：Cross-cloud collaboration with Microsoft 365（B2B 与跨租户访问设置章节） — https://learn.microsoft.com/microsoft-365/enterprise/cross-cloud-collaboration
  • Microsoft Learn：What is cross-tenant access? — https://learn.microsoft.com/entra/external-id/cross-tenant-access-overview