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