条件访问：目标资源

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

• 管理员可以从应用程序或服务列表中进行选择，其中包括内置 Microsoft 应用程序和任何 Microsoft Entra 集成应用程序，包括库应用程序、非库应用程序以及通过 应用程序代理 发布的应用程序。
• 管理员可以根据用户操作（如注册安全信息或注册或加入设备）定义策略，让条件访问在这些操作周围强制实施控制。
• 管理员可以使用 身份验证上下文 在应用程序中提供额外的安全层。

Azure云应用程序

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

Office 365

Microsoft 365提供基于云的生产力和协作服务，如 Exchange、SharePoint和Microsoft Teams。 在条件访问中，Microsoft 365套件的应用程序显示在“Office 365”下。 Microsoft 365云服务已深度集成，以确保顺畅协作体验。 创建策略时，此集成可能会导致混淆，因为某些应用（如Microsoft Teams）依赖于其他应用，例如SharePoint或 Exchange。

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

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

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

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

Windows Azure服务管理 API

当你将 Microsoft Azure 服务管理 API 应用程序作为目标时，策略将强制适用于一组与门户紧密相关的服务所颁发的令牌。 此组包括以下项的应用程序 ID：

• Azure Resource Manager
• Azure门户，其中还包括Microsoft Entra管理中心和Microsoft参与中心
• Azure Data Lake
• Application Insights API
• Log Analytics API（日志分析API）

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

• Azure CLI
• Azure Data Factory门户
• Azure Event Hubs
• Azure PowerShell
• Azure Service Bus
• Azure SQL Database
• Azure Synapse
• 经典部署模型 API
• Microsoft 365管理中心
• Microsoft IoT Central
• Microsoft Defender 多租户管理
• SQL 托管实例
• Visual Studio订阅管理员门户

Microsoft 管理门户

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

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

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

其他应用程序

管理员可以将任何已注册Microsoft Entra的应用程序添加到条件访问策略。 这些应用程序可能包括：

• 通过 Microsoft Entra 应用程序代理发布的应用程序
• 从库中添加的应用程序
• 不在库中的自定义应用程序
• 使用基于密码的单一登录的应用程序

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

不同客户端类型的条件访问

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

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

若要查看登录日志，请从Microsoft Entra管理中心查看这些客户端类型：

1. 登录到 Microsoft Entra 管理中心至少需要具备 Reports Reader 角色。
2. 浏览到 Entra ID>监控和运行状况>登录日志。
3. 为“客户端凭据类型”添加筛选器。
4. 调整筛选器，根据登录中使用的客户端凭据查看特定日志集。

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

所有资源的条件访问

将条件访问策略应用于 所有资源（以前称为“所有云应用”），且没有任何资源排除项，这会强制对来自网站和服务的所有令牌请求实施该策略。 此选项包括条件访问策略中无法单独定位的应用程序，例如 Windows Azure Active Directory （00000002-00000-0000-c000-00000000000000000）。

当 ALL 资源策略具有资源排除时，旧条件访问行为

如果策略中排除了任何应用，为了不无意阻止用户访问， 以前 将某些低特权范围从策略强制中排除。 这些范围允许调用基础 Graph API，例如 Windows Azure Active Directory （000000002-0000-0000-c0000-0000000000000） 和Microsoft Graph（00000003-0000-0000-c000-0000000000000），以访问应用程序常用的用户配置文件和组成员身份信息作为身份验证的一部分。 例如：当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

当 ALL 资源策略具有资源排除时的新条件访问行为

上一节中列出的范围现在评估为目录访问，并被映射到 Azure AD Graph（资源：Windows Azure Active Directory，ID：00000002-0000-0000-c000-000000000000），用于条件访问评估。

在客户端应用程序仅请求这些作用域的情况下，强制实施条件访问策略。这些策略以“所有资源”为目标，但排除一个或多个资源，或者明确地以 Azure AD Graph 为目标。 当应用程序请求除上面列出的范围之外的任何其他范围时，行为没有变化。

用户体验

在客户端应用程序仅请求上面列出的范围的用户登录流中，用户现在可能会收到条件访问质询（例如 MFA 或设备符合性）。 挑战的具体情况取决于策略中配置的访问控制，这些策略要么针对所有资源（无论是否包含资源排除项），要么显式针对 Azure AD Graph。

在以下示例中，租户有一个条件访问策略，其中包含以下详细信息：

• 面向所有用户和所有资源
• 机密客户端应用程序与 Exchange Online 的资源排除规则
• MFA 配置为授权控制

示例方案

当客户端应用程序请求的范围超出前面列出的范围时，行为没有变化，如以下示例所示。

示例方案

大多数应用程序请求的范围超出先前列出的范围，并且已经受到条件访问的强制执行，除非应用程序被显式排除在策略之外。 在这种情况下，行为没有变化。

为了应对条件访问质询，那些有意设计为仅请求前面列出的范围而不具备处理条件访问质询功能的自定义应用程序可能需要进行更新。 有关实现详细信息 ，请参阅Microsoft条件访问开发人员指南 。

如何识别受低特权范围强制更改影响的应用程序

应用程序可预先获得授权，仅请求一个或多个之前列出的权限范围。 使用以下选项标识受影响的应用程序。

# ==============================
# Inventory of apps whose delegated consent grants include ONLY
# the OIDC scopes + specific directory scopes listed below.
#
# Enhancements incorporated:
#  - Supported both PowerShell 5.1 and 7.x
#  - Add user sign-in count (last 7 days) per app
#
# Output:
#  - ServicePrincipalObjectId (oauth2PermissionGrants.clientId = SP object id)
#  - AppId
#  - AppDisplayName
#  - AppOwnerOrganizationId (for classification)
#  - Scopes (union of delegated scopes granted)
#  - UserSigninsLast7Days (Successful + Failed)
# ==============================

$TenantId = Read-Host "Enter your Microsoft Entra tenant ID (GUID)"

$BaselineScopes = @(
  "openid", "profile", "email", "offline_access",
  "User.Read", "User.Read.All", "User.ReadBasic.All",
  "People.Read", "People.Read.All",
  "GroupMember.Read.All", "Member.Read.Hidden"
)

Disconnect-MgGraph -ErrorAction SilentlyContinue

Connect-MgGraph -Environment China -ClientId 'YOUR_CLIENT_ID' -TenantId $TenantId -Scopes @(
  "DelegatedPermissionGrant.Read.All",
  "Directory.Read.All",
  "Reports.Read.All"
)

# ------------------------------
# Pull oauth2PermissionGrants (paging)
# ------------------------------
$uri = "https://microsoftgraph.chinacloudapi.cn/beta/oauth2PermissionGrants?`$select=clientId,scope,consentType"
$grants = @()
while ($uri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $uri
  $grants += $resp.value
  $uri = $resp.'@odata.nextLink'
}

# ------------------------------
# Build baseline-only candidate set (Jun: HashSet per clientId)
# ------------------------------
$scopesByClient = @{}  # key: clientId (SP objectId), value: HashSet[string] (case-insensitive)

foreach ($g in $grants) {
  $cid = $g.clientId.ToString().Trim()
  if (-not $cid) { continue }

  if (-not $scopesByClient.ContainsKey($cid)) {
    $scopesByClient[$cid] = [System.Collections.Generic.HashSet[string]]::new(
      [System.StringComparer]::OrdinalIgnoreCase
    )
  }

  foreach ($s in ($g.scope -split '\s+')) {
    if ($s -and $s.Trim().Length -gt 0) {
      [void]$scopesByClient[$cid].Add($s.Trim())
    }
  }
}

$candidates = foreach ($cid in $scopesByClient.Keys) {
  $scopes = $scopesByClient[$cid]
  if ($scopes.Count -le 0) { continue }

  $outside = $scopes | Where-Object { $_ -notin $BaselineScopes }
  if ($outside.Count -eq 0) {
    [PSCustomObject]@{
      ServicePrincipalObjectId = $cid
      Scopes = ($scopes -join ' ')
    }
  }
}

# ------------------------------
# Pull per-app sign-in summary for last 7 days (Graph REST via Invoke-MgGraphRequest)
# Endpoint: GET /beta/reports/getAzureADApplicationSignInSummary(period='D7')
# In this API output, 'id' corresponds to the appId (clientId)
# ------------------------------
$signInSummary = @()
$signInUri = "https://microsoftgraph.chinacloudapi.cn/beta/reports/getAzureADApplicationSignInSummary(period='D7')"

while ($signInUri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $signInUri

  if ($resp -and $resp.value) {
    $signInSummary += $resp.value
  }

  # Paging (if present)
  $signInUri = $resp.'@odata.nextLink'
}

# appId -> total sign-ins (7d)
$signInCountByAppId = @{}
foreach ($s in $signInSummary) {
  $appId = $s.id
  if (-not $appId) { continue }

  # PS5.1-safe null handling
  $success = 0
  $failed  = 0
  if ($null -ne $s.successfulSignInCount) { $success = [int]$s.successfulSignInCount }
  if ($null -ne $s.failedSignInCount)     { $failed  = [int]$s.failedSignInCount }

  $signInCountByAppId[$appId] = $success + $failed
}

$resultsTenantOwned = @()
$resultsNotTenantOwned = @()

# ------------------------------
# Filter to tenant-owned or external apps; enrich with appId/displayName + sign-in counts
# ------------------------------
foreach ($c in $candidates) {
  try {
    $spUri = "https://microsoftgraph.chinacloudapi.cn/beta/servicePrincipals/$($c.ServicePrincipalObjectId)?`$select=id,appId,displayName,appOwnerOrganizationId"
    $sp = Invoke-MgGraphRequest -Method GET -Uri $spUri

    $signinCount7d = 0
    if ($sp.appId -and $signInCountByAppId.ContainsKey($sp.appId)) {
      $signinCount7d = $signInCountByAppId[$sp.appId]
    }

    $row = [PSCustomObject]@{
      ServicePrincipalObjectId = $c.ServicePrincipalObjectId
      AppId                   = $sp.appId
      AppDisplayName          = $sp.displayName
      AppOwnerOrganizationId  = $sp.appOwnerOrganizationId
      Scopes                  = $c.Scopes
      UserSigninsLast7Days    = $signinCount7d
    }

    if ($sp.appOwnerOrganizationId -eq $TenantId) {
      $resultsTenantOwned += $row
    }
    else {
      $resultsNotTenantOwned += $row
    }
  }
  catch {
    # Ignore non-enumerable / missing service principals
  }
}

# ------------------------------
# Output
# ------------------------------
'=== Tenant-owned apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

'=== External apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsNotTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

保护目录信息

如果因为业务原因无法配置未排除资源的基线 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）是表示存储在目录中的数据的资源，例如用户、组和应用程序。 Windows 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. 在 “访问控制>授予”下，选择“ 授予访问权限”，“ 要求身份验证强度”，选择 “多重身份验证”，然后选择“ 选择”。
13. 确认设置，然后将“启用策略”设置为“只限报告”。
14. 选择创建以启用您的策略。

用户操作

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

• 注册安全信息：此用户操作使条件访问策略能够在用户尝试注册其安全信息时强制实施规则。 有关详细信息，请参阅 组合安全信息注册。

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

认证上下文

身份验证上下文保护应用程序中的数据和操作。 这些应用程序包括自定义应用程序、业务线（LOB）应用程序、SharePoint或受Microsoft Defender for Cloud Apps保护的应用程序。 Microsoft Entra Privileged Identity Management（PIM）还可用于角色激活期间强制实施条件访问策略。

例如，组织可能会将文件存储在SharePoint网站，例如午餐菜单或秘密的SBBS酱食谱。 每个人都可以访问午餐菜单网站，但访问机密BBQ酱食谱网站的用户可能需要使用托管设备并同意特定的使用条款。 同样，管理员在通过 PIM 激活特权角色时，可能需要进行多重身份验证或使用合规的设备。

身份验证上下文适用于用户或工作负载身份，但不能在同一条件访问策略中使用。

配置身份验证上下文

通过转到 Microsoft Entra ID>安全>条件访问>身份验证上下文来管理身份验证上下文。

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

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

添加到条件访问策略

管理员可以转到分配>云应用或操作，并从选择此策略应用于菜单中选择身份验证上下文，在条件访问策略中选择已发布的身份验证上下文。

删除身份验证上下文

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

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

使用身份验证上下文标记资源

若要了解有关使用身份验证上下文的详细信息，请参阅以下文章。

• 使用敏感度标签来保护Microsoft Teams、Microsoft 365组和SharePoint网站中的内容
• Microsoft Defender for Cloud Apps
• 自定义应用程序
• Privileged Identity Management - 激活时，需要Microsoft Entra条件访问身份验证上下文

相关内容

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