条件访问：目标资源

目标资源（以前是云应用、作和身份验证上下文）是条件访问策略中的关键信号。 条件访问策略允许管理员将控制分配给特定应用程序、服务、作或身份验证上下文。

• 有应用程序或服务列表可供管理员选择，这些应用程序或服务包含内置的 Microsoft 应用程序和任何 Microsoft Entra 集成应用程序（其中包括库、非库和通过应用程序代理发布的应用程序）。
• 管理员可以根据用户操作（如注册安全信息或注册或加入设备）来定义策略，让条件访问对这些操作强制实施控制。
• 管理员可以将来自全局安全访问的流量转发配置文件设定为目标，以增强功能。
• 管理员可以使用身份验证上下文在应用程序中提供额外的安全层。

管理员可以在租户中出现服务主体时，将条件访问策略分配给 Microsoft 云应用，但 Microsoft Graph 除外。 Microsoft Graph 作为一个综合性资源。 使用受众报告查看基础服务，并在您的策略中针对这些服务。 某些应用（如 Office 365 和 Windows Azure 服务管理 API ）包括多个相关的子应用或服务。 创建新的Microsoft云应用程序时，一旦在租户中创建服务主体，它们就会显示在应用选取器列表中。

Microsoft 365 提供基于云的生产力和协作服务，如 Exchange、SharePoint 和 Microsoft Teams。 Microsoft 365 云服务已深度集成，以确保用户拥有顺畅的协作体验。 创建策略时，此集成可能会导致混淆，因为某些应用（如 Microsoft Teams）依赖于其他应用（如 SharePoint 或 Exchange）。

Office 365 应用分组使可以一次性针对这些服务。 建议使用 Office 365 分组，而不是针对单个云应用，以避免 服务依赖项出现问题。

以此组应用程序作为目标有助于避免因策略和依赖关系不一致而导致的问题。 例如：Exchange Online 应用关联到邮件、日历和联系人信息等传统的 Exchange Online 数据。 相关元数据可以通过不同的资源（例如搜索）来公开。 为了确保所有元数据按预期方式受到保护，管理员应将策略分配到 Office 365 应用。

管理员可以从条件访问策略中排除整个 Office 365 套件或特定 Office 365 云应用。

可在条件访问 Office 365 应用套件中包含的应用一文中找到包含的所有服务的完整列表。

当您以 Microsoft Azure 服务管理 API 应用程序为目标时，将针对一组紧密关联到门户的服务颁发令牌并执行策略。 此组包括以下项的应用程序 ID：

• Azure Resource Manager
• Azure 门户，其中还涵盖 Microsoft Entra 管理中心
• Azure Data Lake
• Application Insights API
• 日志分析 API

由于策略应用于 Azure 管理门户和 API，因此依赖于 Azure API 的任何服务或客户端都可能会间接受到影响。 例如：

• Azure CLI
• Azure 数据工厂门户
• Azure DevOps
• Azure 事件中心
• Azure PowerShell
• Azure 服务总线
• Azure SQL 数据库
• Azure Synapse
• 经典部署模型 API
• Microsoft 365 管理中心
• Microsoft IoT Central
• SQL 托管实例
• Visual Studio 订阅管理员门户

有关如何为 Windows Azure 服务管理 API 设置示例策略的详细信息，请参阅 条件访问：要求进行 Azure 管理 MFA。

对 Microsoft 管理门户云应用使用条件访问策略时，将对颁发给以下 Microsoft 管理门户的应用程序 ID 的令牌强制实施该策略：

• Azure 门户
• Exchange 管理中心
• Microsoft 365 管理中心
• Microsoft 365 Defender 门户
• Microsoft Entra 管理中心
• Microsoft Intune 管理中心
• Microsoft Purview 合规性门户
• Microsoft Teams 管理中心

我们会不断向列表添加更多管理门户。

有些应用程序根本不会出现在选取器中。 在条件访问策略中包括这些应用程序的唯一方法是包括 所有资源（以前为“所有云应用”）， 或使用 New-MgServicePrincipal PowerShell cmdlet 或使用 Microsoft Graph API 添加缺少的服务主体。

条件访问适用于非客户端的资源，除非客户端是请求 ID 令牌的机密客户端。

• 公共客户端
  • 公共客户端是在桌面版Microsoft Outlook 等设备上本地运行的客户端，或者Microsoft Teams 等移动应用。
  • 条件访问策略不适用于公共客户端本身，而是基于它们请求的资源。
• 机密客户端
  • 条件访问适用于客户端请求的资源，如果机密客户端请求 ID 令牌，也适用于机密客户端本身。
  • 例如：如果 Outlook 网页版请求 Mail.Read 和 Files.Read 范围的令牌，条件访问将适用于 Exchange 和 SharePoint 的策略。 此外，如果 Outlook Web 请求 ID 令牌，条件访问也会应用 Outlook Web 的策略。

若要在 Microsoft Entra 管理中心查看这些客户端类别的 登录日志，请按以下步骤操作：

1. 至少以报表读取者身份登录到 Microsoft Entra 管理中心。
2. 导航至 Entra ID>监控和健康>登录日志。
3. 为“客户端凭据类型”添加筛选器。
4. 调整筛选器，根据登录中使用的客户端凭据查看特定日志集。

有关详细信息，请参阅 公共客户端和机密客户端应用程序一文。

将条件访问策略应用于 所有资源（以前称为“所有云应用”）， 在不排除任何应用的情况下，会强制执行来自网站和服务的所有访问令牌请求，包括全局安全访问流量转发配置文件的请求。 此选项包括条件访问策略中不能单独定位的应用程序，例如 Windows Azure Active Directory （000000002-0000-0000-c0000-000000000000000）。

如果策略中排除了任何应用，为了不无意阻止用户访问，则会从策略强制实施中排除某些低特权范围。 这些范围允许调用基础图形 API，例如 Windows Azure Active Directory（000000002-0000-0000-c000-0000000000000）和 Microsoft Graph （000000003-00000-0000-00000000000000），以访问应用程序常用的用户配置文件和组成员身份信息作为身份验证的一部分。 例如：当 Outlook 请求 Exchange 令牌时，它还要求 User.Read 范围能够显示当前用户的基本帐户信息。

大多数应用具有类似的依赖项，这就是为什么每当 所有资源 策略中存在应用排除时，这些低特权范围都会自动排除。 这些低特权范围排除仅允许访问基本用户信息和组信息，无法获取其他数据。 排除的范围如下列出，应用仍需同意才能使用这些权限。

• 本机客户端和单页应用程序（SPA）有权访问以下低特权范围：
  • Azure AD Graph：email、offline_access、openid、profile、User.Read
  • Microsoft Graph: email、offline_access、openid、profile、User.Read、People.Read
• 机密客户端可以访问以下低特权范围（如果它们被排除在“所有资源”策略之外）：
  • Azure AD Graph：email、offline_access、openid、profile、User.Read、User.Read.All、User.ReadBasic.All
  • Microsoft Graph：email、offline_access、openid、profile、User.Read、User.Read.All、User.ReadBasic.All、People.Read、People.Read.All、GroupMember.Read.All、Member.Read.Hidden

有关提到的范围的详细信息，请参阅 Microsoft Graph 权限参考 和 Microsoft 身份平台中的作用域和权限。

如果由于业务原因而无法配置建议的不含应用排除的基线 MFA 策略，并且组织的安全策略必须包括与目录相关的低特权范围（User.Read、User.Read.All、User.ReadBasic.All、People.Read、People.Read.All、GroupMember.Read.All、Member.Read.Hidden），请创建一个单独针对Windows Azure Active Directory（00000002-0000-0000-c000-000000000000）的条件访问策略。 Windows Azure Active Directory（也称为 Azure AD Graph）是一种资源，表示存储在目录中的数据，例如用户、组和应用程序。 Azure Active Directory 资源包含在 “所有资源 ”中，但可以使用以下步骤在条件访问策略中单独定位：

1. 以属性定义管理员和属性分配管理员身份登录到 Microsoft Entra 管理中心。
2. 浏览到 Entra ID>自定义安全属性。
3. 创建新的属性集和属性定义。 有关详细信息，请参阅 Microsoft Entra ID 中的添加或停用自定义安全属性定义。
4. 浏览到 Entra ID>企业应用。
5. 删除 应用程序类型 筛选器，并搜索以 000000002-00000-0000-0000-000000000000 开头的 应用程序 ID。
6. 选择 Windows Azure Active Directory>自定义安全属性>添加分配。
7. 选择要在策略中使用的属性集和属性值。
8. 请导航到 Entra ID>条件访问>策略。
9. 创建或修改现有策略。
10. 在“目标资源”“资源”（以前称为云应用）>“包含”下，选择“选择资源”“编辑筛选器”。>>>
11. 调整筛选器，以包含之前的属性集和定义。
12. 保存策略

用户操作是用户执行的任务。 条件访问支持两种用户操作。

• 注册安全信息：使用此用户操作，可以在启用了组合注册的用户尝试注册其安全信息时强制实施条件访问策略。 在 组合安全信息注册中了解详细信息。

• 注册或加入设备：使用此用户操作，管理员可以在用户向 Microsoft Entra ID 注册或加入设备时强制实施条件访问策略。 使用此操作可以针对注册或加入设备的操作精细配置多重身份验证，而无需配置当前存在的租户范围的策略。 关于此用户操作，有三个关键注意事项：
  • Require multifactor authentication 和 Require auth strength 是此用户操作中唯一可用的访问控制，所有其他访问控制均已禁用。 此限制可防止与依赖于 Microsoft Entra 设备注册或不适用于 Microsoft Entra 设备注册的访问控制发生冲突。
    • 不支持 Windows Hello 企业版和设备绑定的密钥，因为这些方案要求设备已注册。
  • Client apps和Filters for devicesDevice state条件不适用于此用户作，因为它们依赖于 Microsoft Entra 设备注册来强制实施条件访问策略。

身份验证上下文保护应用程序中的数据和操作。 这些应用程序包括自定义应用程序、业务线（LOB）应用程序、SharePoint 或受 Microsoft Defender for Cloud Apps 保护的应用程序。

例如，组织可能会将文件存储在 SharePoint 网站（如午餐菜单或机密的 SAUCE 酱食谱）中。 每个人都可以访问午餐菜单网站，但访问机密BBQ酱食谱网站的用户可能需要使用托管设备并同意特定的使用条款。

身份验证上下文与用户有关联，但不属于同一条件访问策略。

在 Entra ID>条件访问>身份验证上下文下管理身份验证上下文。

选择 “新建身份验证上下文 ”以创建新的身份验证上下文定义。 组织最多可以创建 99 个身份验证上下文定义（c1-c99）。 配置以下特性：

• “显示名称”是用于标识 Microsoft Entra ID 以及使用身份验证上下文的应用程序中的身份验证上下文的名称。 建议使用可在不同资源（例如“受信任的设备”）中使用的名称，以减少所需的身份验证上下文数量。 使用更少的一组名称可以限制重定向次数，并提供更好的端到端用户体验。
• 说明 提供有关策略的详细信息。 管理员和将身份验证上下文应用于资源的管理员使用这些信息。
• 选中“发布到应用”复选框会将身份验证上下文播发到应用，使这些应用可供分配。 如果未选中，身份验证上下文将不可用于下游资源。
• “ID”是只读的，在令牌和应用中用于创建特定于请求的身份验证上下文定义。 此处列出了故障排除和开发用例。

管理员可以选择其条件访问策略中已发布的身份验证上下文，方法是转到“分配”“云应用或操作”，然后从“选择此策略的适用对象”菜单中选择“身份验证上下文” 。

在删除身份验证上下文之前，请确保没有应用程序使用它。 否则，访问应用数据将不受保护。 如果正在应用身份验证上下文条件访问策略，可以通过检查登录日志来确认此先决条件。

若要删除身份验证上下文，请确保它没有分配的条件访问策略，并且不会发布到应用。 此项要求有助于防止意外删除仍在使用中的身份验证上下文。

若要详细了解如何在应用程序中使用身份验证上下文，请参阅以下文章。

• 使用敏感度标签保护 Microsoft Teams、Microsoft 365 组和 SharePoint 网站中的内容
• Microsoft Defender for Cloud Apps
• 自定义应用程序

• 条件访问：条件 - 了解如何配置条件以优化策略。
• 条件访问通用策略 - 浏览通用策略模板以快速入门。
• 客户端应用程序依赖项 - 了解依赖项如何影响条件访问策略。