Microsoft Entra条件访问中的令牌保护

令牌保护是一种条件访问会话控制机制，通过确保只有绑定设备的身份验证会话令牌（如主刷新令牌（PRT））在应用程序请求访问受保护资源时被 Entra ID 接受，以减少令牌重播攻击。

当用户向Microsoft Entra注册Windows 10或更高版本的设备时，将颁发 PRT 并将其加密绑定到该设备。 此绑定可确保即使威胁参与者窃取令牌，也不能从其他设备使用它。 强制实施令牌保护后，Microsoft Entra验证受支持的应用程序是否仅使用这些绑定登录会话令牌。

可以在 Exchange Online、SharePoint Online 和 Teams 资源上强制实施令牌保护策略。 许多Microsoft 365本机应用程序都支持它。 有关支持的应用程序和资源的综合列表，请参阅“要求”部分。

要求

使用此功能需要Microsoft Entra ID P1 许可证。 若要查找适合你的要求的许可证，请参阅 Microsoft Entra ID 的一般可用功能比较。

以下设备和应用程序支持访问应用令牌保护条件访问策略的资源：

支持的设备

• Microsoft Entra 加入、Microsoft Entra 混合加入或 Microsoft Entra 注册的 Windows 10 或更新设备。 请参阅不受支持的设备类型的 已知限制部分 。
• 混合 Microsoft Entra 加入的 Windows Server 2019 或更高版本。

支持的应用程序

• OneDrive同步客户端版本 22.217 或更高版本
• Teams 本机客户端版本 1.6.00.1331 或更高版本
• Power BI桌面版本 2.117.841.0（2023 年 5 月）或更高版本
• Exchange PowerShell 模块版本 3.7.0 或更高版本
• 使用 Microsoft Graph PowerShell 2.0.0 或更高版本及EnableLoginByWAM选项
• 使用“Windows 身份验证代理”登录选项时，Visual Studio 2022 或更高版本
• Windows App版本 2.0.379.0 或更高版本

以下资源支持令牌保护：

• Office 365 Exchange Online
• Office 365 SharePoint Online
• Microsoft Teams服务
• Azure Virtual Desktop
• Windows 365

已知的限制

• 不支持 Office 永久客户端。
• 访问 Exchange 和SharePoint时，以下应用程序不支持使用受保护的令牌流登录，并且用户会被阻止：
  • 访问SharePoint的 PowerShell 模块
  • 适用于 Excel 的 PowerQuery 扩展
  • 可访问 Exchange 或 SharePoint 的 Visual Studio Code 扩展
• 不支持以下Windows客户端设备：
  • Surface Hub
  • 基于Windows操作系统的Microsoft Teams会议室系统
• 满足主租户中令牌保护设备注册要求的外部用户将得到支持。 但是，不符合这些要求的用户会看到一条不明原因的错误消息，且无法指出问题所在。
• 不支持使用以下方法向Microsoft Entra ID注册的设备：
  • Microsoft Entra已加入Azure Virtual Desktop会话主机。
  • Windows 设备使用 批量注册进行部署。
  • 由 Windows 365 部署的云电脑，已加入 Microsoft Entra。
  • Power Automate托管的已加入Microsoft Entra的计算机组。
  • 使用自行部署模式部署的 Windows Autopilot 设备。
  • 在 Azure 中使用启用了 Microsoft Entra ID 身份验证的虚拟机扩展部署的 Windows 虚拟机。

若要识别由于前面列出的注册类型不受支持而受影响的设备，请检查 tokenProtectionStatusDetails 登录日志中的属性。 由于设备注册类型不受支持而被阻止的令牌请求，可以通过 signInSessionStatusCode 值为 1003 进行标识。

为防止在加入过程中出现中断，您可以通过添加设备筛选条件，排除先前描述的部署类别中的设备，来修改令牌保护的条件访问策略。 例如，若要排除：

• 加入 Microsoft Entra 的云电脑可以使用 systemLabels -eq "CloudPC" and trustType -eq "AzureAD"。
• 加入Microsoft Entra的Azure虚拟桌面，可以使用 systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD"。
• 在已加入Microsoft Entra的Power Automate托管计算机组中，您可以使用 systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD"。
• 当设备通过 Windows Autopilot 的自部署模式部署时，可以使用 enrollmentProfileName 属性。 例如，如果在 Intune 中为 Autopilot 自我部署模式设备创建了注册配置文件作为“Autopilot 自部署配置文件”，则可以使用“enrollmentProfileName -eq”Autopilot 自部署配置文件”。
• 在Azure中加入Microsoft Entra的Windows虚拟机，可以使用 profileType -eq "SecureVM" and trustType -eq "AzureAD"。

部署

对于用户来说，在已注册设备和兼容应用程序上使用兼容客户端平台时，用于强制实施令牌保护的条件访问策略的部署应该是不可见的。

若要最大程度地减少因应用或设备不兼容而导致用户中断的可能性，请遵循以下建议：

• 从一组试点用户开始，并随着时间推移而扩展。
• 在强制实施令牌保护之前，在 仅报告模式下 创建条件访问策略。
• 捕获交互式和非交互式登录日志。
• 分析这些日志的时间足够长，足以涵盖正常的应用程序使用。
• 将已知可靠用户添加到强制策略。

此过程有助于评估用户的客户端和应用兼容性，以便强制实施令牌保护。

创建条件访问策略

执行专用角色的用户（如 特权访问安全级别 中所述的用户）可能是此功能的目标。 建议先通过一小部分开展试点。

以下步骤可帮助你创建条件访问策略，以便在 Windows 设备上为 Exchange Online 和 SharePoint Online 提供令牌保护。

1. 以条件访问管理员、安全管理员或全局管理员身份登录到 Azure 门户。
2. 导航到 Microsoft Entra ID>安全性>条件访问。
3. 选择“创建新策略”。
4. 为策略指定名称。 建议组织为其策略的名称创建有意义的标准。
5. 在分配下，选择用户或工作负载标识。
   1. 在 “包括”下，选择要测试此策略的用户或组。
   2. 在“排除”下，选择“用户和组”，并选择组织的紧急访问或不受限帐户。
6. 在“目标资源”>“资源(以前为云应用)”>“包括”>“选择资源”下

   1. 在 “选择”下，选择以下应用程序：

      1. Office 365 Exchange Online
      2. Office 365 SharePoint Online
      3. Microsoft Teams服务
      4. 如果在您的环境中部署了 Windows 应用，请包括：
         1. Azure Virtual Desktop
         2. Windows 365
         3. Windows云登录

      警告

      应仅为这些应用程序配置条件访问策略。 选择 Office 365 应用程序组可能会导致意外失败。 此更改是一般规则的例外，即在条件访问策略中选择Office 365应用程序组。

   2. 选择 选择。

7. 在“条件”下，执行以下操作：
   1. 在“设备平台”下：
      1. 将“配置”设置为“是”。
      2. 包括>选择设备平台>Windows。
      3. 选择完成。
   2. 在“客户端应用”下：

      1. 将“配置”设置为“是”。

         警告

         未配置 客户端应用 条件，或者选择 “浏览器 ”可能会导致使用 MSAL.js的应用程序（如 Teams Web）被阻止。

      2. 在“新式身份验证客户端”下，仅选择 “移动应用”和“桌面客户端”。 将其他项目保留为未选中状态。

      3. 选择完成。

8. 在“访问控制”>“会话”下面，选择“要求对登录会话使用令牌保护”，然后选择“选择”。
9. 确认设置，然后将“启用策略”设置为“只限报告”。
10. 选择“创建”以启用策略。

确认设置后，使用策略影响模式或仅报告模式，将“启用策略”开关从 “仅报告” 切换到 “打开”。

捕获日志并进行分析

使用策略影响、登录日志和日志分析等功能，在强制实施条件访问之前和之后监视令牌保护。

登录日志

使用 Microsoft Entra 登录日志在仅报告模式下或启用模式下验证令牌保护执行策略的结果。

1. 登录到 Microsoft Entra 管理中心，身份至少为条件访问管理员。
2. 浏览到 Entra ID>监控和运行状况>登录日志。
3. 选择特定请求以确定是否已应用策略。
4. 根据状态转到“条件访问”或“仅报告”窗格，然后选择需要进行令牌保护的策略名称。
5. 在 “会话控制” 下，检查是否满足策略要求。
6. 若要查找有关请求绑定状态的更多详细信息，请选择窗格 “基本信息 ”，并查看字段 “令牌保护 - 登录会话”。 可能的值为：
   1. 绑定：请求使用绑定协议。 某些登录可能包括多个请求，并且所有请求都必须绑定以满足令牌保护策略。 即使单个请求似乎已绑定，如果其他请求未绑定，也不会确保符合策略。 若要查看登录的所有请求，可以筛选特定用户的所有请求或按 corelationid 查找。
   2. 未绑定：请求未使用绑定协议。 请求未绑定时可能的 statusCodes 为：
      1. 1002：由于设备状态缺乏Microsoft Entra ID，请求不受限制。
      2. 1003：请求未绑定，因为Microsoft Entra ID设备状态不符合令牌保护的条件访问策略要求。 此错误可能是由于设备注册类型不受支持，或者未使用全新登录凭据注册设备。
      3. 1005：由于其他未指定的原因，请求被解除绑定。
      4. 1006：请求未绑定，因为 OS 版本不受支持。
      5. 1008：请求未绑定，因为客户端未与平台中介集成，例如 Windows 帐户管理器（WAM）。

日志分析

还可以使用 Log Analytics 查询由于令牌保护强制失败而阻止请求的登录日志（交互式和非交互式）。

下面是一个示例 Log Analytics 查询，在过去 7 天内搜索非交互式登录日志，以突出显示 Blocked 与 Allowed 请求按Application分类的情况。 这些查询只是示例，可能会发生更改。

//Per Apps query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]' 
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"] 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result 
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by Requests desc 

上一个查询的结果应类似于以下屏幕截图：

以下查询示例查看了过去 7 天的非交互式登录日志，其中突出显示了用户所阻止和允许的请求。

//Per users query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by UserPrincipalName asc   

以下查询示例查看过去七天的非交互式登录日志，其中突出显示了使用设备的用户，其中Microsoft Entra ID设备状态不满足令牌保护 CA 策略要求。

AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| where TokenProtectionStatusDetails!= "" 
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails) 
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"]) 
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]) 
| where bindingStatusCode == 1003 
| summarize count() by UserPrincipalName 

最终用户体验

启用令牌保护要求时，注册或注册其支持设备的用户在令牌保护支持的应用程序中的登录体验没有任何差异。

尚未注册或注册其设备的用户，如果已启用令牌保护策略，身份验证后会显示以下屏幕截图。

启用令牌保护策略时未使用受支持的应用程序的用户将在身份验证后看到以下屏幕截图。

相关内容

什么是主刷新令牌？