Microsoft Entra Kerberos 是一种云原生身份验证协议，旨在桥接混合标识方案，从而实现对云和本地资源的安全访问。 它将传统的 Kerberos 功能扩展到 Microsoft Entra 生态系统中，使组织能够现代化其标识基础结构，而不会牺牲与旧系统的兼容性。 它还支持无缝单一登录（SSO）到本地资源，以便使用新式凭据（例如 Windows Hello 企业版或 FIDO2 安全密钥）对用户进行身份验证。
在实践中，Microsoft Entra Kerberos 会将 Microsoft Entra ID 转换为基于云的密钥分发中心（KDC），以便进行 Kerberos 身份验证。 此功能允许Microsoft Entra ID 向用户颁发 Kerberos 票证，从而将传统的 Kerberos 身份验证扩展到本地 Active Directory 之外。 2021 年引入了 Microsoft Entra Kerberos，以帮助弥合旧式、本地身份验证协议和新式云标识之间的差距。
在混合方案中，如果帐户存在于本地 Active Directory 域服务（AD DS），并且这些用户同步到 Microsoft Entra ID，Microsoft Entra Kerberos 起着关键作用。 它使这些混合用户能够使用 Kerberos 向云和本地资源进行身份验证，而无需直接看到域控制器。 例如，如果已加入 Microsoft Entra ID 的 Windows 客户端通过 Internet 访问文件共享或应用程序，Microsoft Entra ID 可以代表本地 Active Directory 环境颁发必要的 Kerberos 票证。
注释
有关 Windows 中的 Kerberos 的详细信息，请参阅 Kerberos 身份验证概述。
混合标识
混合标识是指存在于本地 Active Directory（AD DS）和 Microsoft Entra ID 中的用户标识。 这些标识使用 Microsoft Entra Connect 等工具进行同步，允许用户使用一组凭据访问基于云的和本地资源。 此设置可跨环境实现无缝身份验证和单一登录（SSO）体验。 它非常适合在维护旧基础结构的同时过渡到云的组织。
重要
目前，Microsoft Entra Kerberos 仅适用于混合标识。
主要功能和优势
无缝混合身份验证：Microsoft Entra Kerberos 允许帐户驻留在本地 Active Directory 域服务（AD DS）中的用户，并同步到Microsoft Entra ID，以便跨云和本地资源进行身份验证。 它减少了，在某些情况下无需直接连接到域控制器。 例如，当已加入 Microsoft Entra ID 的 Windows 客户端通过 Internet 访问文件共享或应用程序时，Entra ID 可以作为与资源关联的 KDC 颁发必要的 Kerberos 票证。
通过新式凭据支持增强的安全性：用户可以使用无密码方法（如 Windows Hello 企业版或 FIDO2 安全密钥）登录，但仍可以访问受 Kerberos 保护的本地资源。 启用多重身份验证和无密码身份验证，降低与密码盗窃和网络钓鱼攻击相关的风险。
简化的混合联接：Microsoft Entra Kerberos 支持混合联接方案，而无需 ADFS 或Microsoft Entra Connect 同步。这非常适合非持久性虚拟桌面基础结构（VDI）、断开连接的林和 Azure 虚拟桌面。
安全票证交换：Microsoft Entra Kerberos 使用安全的票证授予票证（TGT）交换模型。
可缩放的组成员身份：解决了具有大型或动态组成员身份的传统 Kerberos 限制，提高了可靠性和用户体验。 在涉及大量用户的方案中，通过站点内所有域控制器（DC）的自动负载分配来优化性能。 对于 Azure 虚拟桌面（AVD）环境中的部署，我们建议确保有足够的 DC 可用，并在地理上靠近环境，以保持响应能力。
Microsoft Entra Kerberos 的工作原理
Microsoft Entra Kerberos 允许Microsoft Entra ID 租户与现有本地 Active Directory 领域一起作为专用 Kerberos 领域运行。 当用户登录到已加入 Microsoft Entra ID 或混合联接的 Windows 设备时，设备会使用 Microsoft Entra ID 进行身份验证，并接收 主刷新令牌。
除了 PRT，Entra ID 还可以颁发部分票证授予票证（TGT）。 此 TGT 使用户可以在需要时将其交换为完全形成的本地 TGT，还可以颁发云票证授予票证（云 TGT），使用户能够请求 Kerberos 服务票证来访问基于云的资源。 在此模型中，Microsoft Entra ID 充当密钥分发中心（KDC），从而促进安全无缝的身份验证。
身份验证流
用户身份验证：
- 用户登录到 Windows 设备（Windows 10 2004+ 或 Windows 11）。
- 本地安全机构（LSA）使用云身份验证提供程序（CloudAP）通过 OAuth 进行身份验证，以Microsoft Entra ID。
- Microsoft Entra ID 颁发包含用户和设备信息的主刷新令牌（PRT）。
- TGT 适用于 KERBEROS.MICROSOFTONLINE.COM 领域，该领域充当基于云的 Kerberos 分发中心（KDC）。
云 TGT 颁发：
如果用户使用无密码方法（如 FIDO2 或 Windows Hello 企业版）登录，Microsoft Entra ID 会为用户的本地 Active Directory（AD） 域颁发部分票证授予票证（部分 TGT）。 此部分 TGT 包含用户的安全标识符（SID），但没有授权数据。
Kerberos 服务器对象存在于本地 AD 中，通过 Microsoft Entra Connect 创建和同步。 此对象允许Microsoft Entra ID 生成这些部分 TGT 供本地域控制器使用，以方便本地资源访问。
Entra ID 颁发的部分 TGT 与本地 Active Directory 域控制器交换，以获取包含组成员身份和其他访问控制数据的完整 TGT。 必须与域控制器交换部分 TGT 才能获取完整的授权信息。
Microsoft Entra ID 还充当云资源的关键分发中心（KDC），在适当时向客户端颁发云票证授予票证（云 TGT）。 云 TGT 存储在客户端的 Kerberos 票证缓存中，客户端将 Microsoft Entra ID 租户识别为云资源的单独 Kerberos 领域。
Microsoft Entra Kerberos TGT 和 Active Directory 访问控制
拥有用户的本地 Active Directory （AD） 域的 Microsoft Entra Kerberos 票证授予票证（TGT）不会自动授予对完整 AD TGT 的访问权限。 若要完成交换，用户必须列在 Azure AD Read-Only 域控制器 （RODC） 对象的“显示凭据允许列表”中，而不是在阻止列表中列出。 最佳做法是，默认配置应设置为“拒绝”，显式允许权限仅授予有权使用Microsoft Entra Kerberos 的组。
在交换过程中，会评估部分Microsoft Entra Kerberos TGT 转换为完整的 AD TGT，以确定访问资格。 如果用户被阻止或未显式允许，则请求被拒绝，并导致错误。
重要
TGT 仅可由本地 Active Directory 识别。 因此，有权访问部分 TGT 不会提供对 AD 外部其他资源的访问权限。
云资源的云 TGT：
- Microsoft Entra ID 充当密钥分发中心（KDC 在领域下 KERBEROS.MICROSOFTONLINE.COM 向客户端颁发云 Kerberos 票证授予票证（TGT）。
- 客户端将 Microsoft Entra ID 租户识别为云资源的单独 Kerberos 领域，TGT 存储在客户端的 Kerberos 票证缓存中。
- 云 TGT 仅包含特定于云服务的授权数据，并且足以访问与 Microsoft Entra Kerberos（例如 Azure 文件和 Azure SQL）集成的资源。
注释
云 TGT 不是本地 TGT 的替代项。 这是另一个允许访问云资源的票证。 访问本地资源仍需要本地 TGT。
领域映射和 Azure 租户信息：
- Windows LSASS 管理 Kerberos 云 TGT、领域映射和 Entra ID 租户信息。 Kerberos 堆栈使用 KDC 代理将 Kerberos 流量路由到 Microsoft Entra ID 来维护云 TGT 和领域映射。
- 对于 Azure 虚拟桌面，用户同时接收 PRT 和云 TGT。 Azure 虚拟桌面使用 FSLogix 从 Azure 文件加载用户配置文件。
服务票证请求和颁发：
访问本地资源：
- Entra ID 颁发部分 TGT。
- 客户端联系本地 AD 域控制器以将其交换为完整的 TGT。
- 然后，此完整的 TGT 用于访问 SMB 共享或 SQL 服务器等本地资源。
访问云资源：客户端使用云 TGT 请求云资源的服务票证。 无需与本地 AD 交互。
- 当用户访问服务（例如 Azure 文件）时，客户端通过演示 TGT 从 Microsoft Entra ID 请求服务票证。
- 客户端将票证授予服务请求（TGS-REQ）发送到Microsoft Entra ID。
- Kerberos 标识服务（例如 cifs/mystuff.file.core.chinacloudapi.cn），并将域映射到 KERBEROS。MICROSOFTONLINE.COM。 KDC 代理协议允许通过 Internet 进行 Kerberos 通信。
- Microsoft Entra ID 验证云 TGT 和用户的标识，并查找在 Microsoft Entra ID 中注册的 Azure 文件资源请求的服务主体名称（SPN）。
- 生成服务票证并使用服务主体的密钥对其进行加密，并将票证返回到 TGS-REP 中的客户端。
- Kerberos 堆栈处理 TGS-REP，提取票证，并生成应用程序请求（AP-REQ）。
- AP-REQ 提供给 SMB，它包含在对 Azure 文件存储的请求中。
- Azure 文件会解密票证并授予访问权限。 FSLogix 现在可以从 Azure 文件存储读取用户配置文件并加载 Azure 虚拟桌面会话。
概要
| 功能 / 特点 | 云 TGT | 本地 TGT |
|---|---|---|
| 发行人 | Entra ID | 本地 AD （通过交换） |
| 领域 | KERBEROS.MICROSOFTONLINE.COM | 本地 AD 域 |
| 授权数据 | 特定于云 | 完整的 AD 组成员身份 |
| Exchange 必需 | 否 | 是（部分→完整 TGT） |
| 用例 | Azure 文件存储、Azure SQL | SMB 共享、旧版应用 |
| 验证工具 （macOS） | tgt_cloud | tgt_ad |
| 验证工具 （Windows） | klist cloud_debug | klist get krbtgt |
Scenarios
使用 Microsoft Entra Kerberos 对 Azure SQL 托管实例的 Windows 身份验证访问
Microsoft Entra ID 的 Kerberos 身份验证使 Windows 身份验证能够访问 Azure SQL 托管实例。 托管实例的 Windows 身份验证使客户能够将现有服务迁移到云，同时保持无缝的用户体验，并为基础结构现代化提供基础。 使用 Microsoft Entra Kerberos 访问 Azure SQL 托管实例的 Windows 身份验证访问的详细信息
使用 SSO 通过 FIDO2 密钥登录到本地资源
Microsoft Entra Kerberos 用户可以使用新式凭据（例如 FIDO2 安全密钥）登录到 Windows，然后访问基于 Active Directory 的传统资源。
无密码安全密钥登录本地资源的详细信息
在平台 SSO 中启用 Kerberos SSO 到本地 Active Directory 并Microsoft Entra ID Kerberos 资源
除了 PSSO PRT，Microsoft Entra 还颁发本地和基于云的 Kerberos 票证授予票证（TGT），这些票证随后通过 PSSO 中的 TGT 映射与 macOS 中的本机 Kerberos 堆栈共享。
详细信息： 在平台 SSO 中启用 Kerberos SSO 到本地 Active Directory 并Microsoft Entra ID Kerberos 资源
使用 FSLogix for Azure 虚拟桌面分析容器
为了托管虚拟桌面的用户配置文件，客户可以将配置文件存储在通过 Microsoft Entra Kerberos 访问的 Azure 文件中。 Microsoft Entra Kerberos 使 Microsoft Entra ID 能够颁发必要的 Kerberos 票证，以使用行业标准 SMB 协议访问文件共享。 详细信息： 在混合方案中使用 Microsoft Entra ID 在 Azure 文件存储 FSLogix 配置文件容器 - FSLogix
为 Azure 文件存储上的混合标识启用 Microsoft Entra Kerberos 身份验证
Microsoft Entra Kerberos 身份验证混合用户使用 Kerberos 身份验证访问 Azure 文件共享，使用 Microsoft Entra ID 颁发必要的 Kerberos 票证以使用 SMB 协议访问文件共享。
详细信息： Microsoft Azure 文件存储上的混合标识的 Entra Kerberos
限制和注意事项
支持仅限于混合用户标识：
- Microsoft Entra Kerberos 仅支持在本地 AD 中创建的混合用户标识，并通过 Microsoft Entra Connect 同步到 Microsoft Entra ID。
- Kerberos 身份验证不支持仅在 Microsoft Entra ID 中托管的仅限云的用户帐户。
作系统和设备限制
- Microsoft已联接的 Windows 10（2004+）和 Windows 11 设备上支持Microsoft Entra Kerberos。
- 某些功能取决于特定的 Windows 版本和修补程序。
ACL 配置的网络连接要求
- 虽然用户可以通过 Internet 访问 Azure 文件共享，但无需直接域控制器连接，但配置 Windows ACL 或文件级权限需要对本地域控制器进行不受限制的网络访问。
无跨租户或来宾用户支持
- 来自其他 Microsoft Entra 租户的 B2B 来宾用户或用户当前无法使用 Microsoft Entra Kerberos 进行身份验证。
密码过期
- 存储帐户的服务主体密码每六个月过期一次，需要轮换才能维护访问权限。
组成员身份限制
- Kerberos 票证的大小约束限制可以包含的组 SID（安全标识符）的数量。 每个票证的默认上限为 1,010 个组。 如果超过，则仅包含前 1010 个，这可能会导致大型组织中的用户访问失败。
Azure 文件身份验证的 MFA 不兼容
- Microsoft Azure 文件共享的 Entra Kerberos 身份验证不支持多重身份验证（MFA）。
- 强制实施 MFA 的条件访问策略必须排除存储帐户应用程序或用户遇到身份验证失败的情况。
- 从需要 MFA 的条件访问策略中排除 Azure 文件。 为此，可以确定策略范围以排除存储帐户或访问 Azure 文件的特定应用程序。
属性同步要求
- 正确同步密钥本地 AD 用户属性对于Microsoft Entra Kerberos 至关重要，包括 onPremisesDomainName、onPremisesUserPrincipalName 和 onPremisesSamAccountName。
每个 Azure 存储帐户的单个 AD 方法
- 对于基于 Azure 文件标识的身份验证，一次只能为每个存储帐户启用一个 AD 方法（Microsoft Entra Kerberos、本地 AD DS 或 Microsoft Entra 域服务）。
- 在方法之间切换需要先禁用当前方法。
Kerberos 加密设置
- 使用 Microsoft Entra Kerberos 的 Kerberos 票证加密仅使用 AES-256。 可以根据要求单独配置 SMB 通道加密。
Microsoft Entra Kerberos 入门
设置Microsoft Entra Connect：
- 将本地 AD DS 用户同步到 Microsoft Entra ID。 有关详细信息，请参阅 Microsoft Entra Connect 安装指南。
启用 Microsoft Entra Kerberos：
- 将 Azure 文件存储或其他服务配置为使用 Microsoft Entra Kerberos 身份验证。 有关说明，请参阅 为 Azure 文件启用 Microsoft Entra Kerberos。
客户端配置：
- 确保 Windows 客户端是最新的，并为 Microsoft Entra Kerberos 配置。
管理服务主体：
- 根据需要监视和轮换服务主体密码。
监视身份验证活动：
- 使用 Microsoft Entra ID 报告和监视工具 跟踪身份验证事件。