Условный доступ: целевые ресурсы

Обзор

Целевые ресурсы (ранее облачные приложения, действия и контекст проверки подлинности) являются ключевыми сигналами в политике условного доступа. Политики условного доступа позволяют администраторам назначать элементы управления определенным приложениям, службам, действиям или контексту проверки подлинности.

• Администраторы могут выбрать из списка приложений или служб, которые включают предустановленные приложения Майкрософт и любые интегрированные приложения Microsoft Entra, включая галерею, не галерею и приложения, опубликованные через Application Proxy.
• Администраторы могут определить политику на основе действий пользователя , таких как Регистрация сведений о безопасности или регистрация или присоединение устройств, позволяя условному доступу применять элементы управления вокруг этих действий.
• Администраторы могут направлять профили перенаправления трафика из Глобального безопасного доступа для расширенных функций.
• Администраторы могут использовать контекст проверки подлинности для обеспечения дополнительного уровня безопасности в приложениях.

облачные приложения Майкрософт

Администраторы могут назначить политику условного доступа Майкрософт облачным приложениям, если субъект-служба отображается в клиенте, за исключением Microsoft Graph. Microsoft Graph функционирует как централизованный ресурс. Используйте Отчеты по аудитории для просмотра базовых служб и нацеливания этих служб в ваших политиках. Некоторые приложения, такие как Microsoft 365/Office 365 и Windows Azure API управления службами включают несколько связанных дочерних приложений или служб. Когда создаются новые облачные приложения Майкрософт, они отображаются в списке средства выбора приложений сразу после создания субъекта-службы в клиенте.

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.

API управления службами Windows Azure

Когда вы используете приложение API управления Windows Azure, политика применяется к токенам, выдаваемым набору служб, тесно связанных с порталом. Эта группировка включает идентификаторы приложений:

• Azure Resource Manager
• портал Azure, который также охватывает Центр администрирования Майкрософт Entra и Центр взаимодействия Майкрософт
• Azure Data Lake
• API для Application Insights
• Log Analytics API

Так как политика применяется к порталу управления Azure и API, любые службы или клиенты, зависящие от API Azure, могут быть косвенно затронуты. Рассмотрим пример.

• Azure CLI
• портал Фабрика данных Azure
• Центры событий Azure
• Azure PowerShell
• Служебная шина Azure
• База данных SQL Azure
• Azure Synapse
• API классической модели развертывания
• Центр администрирования Microsoft 365
• Майкрософт IoT Central
• Управление Microsoft Defender для многопользовательской среды
• Управляемый экземпляр SQL
• портал администрирования подписок Visual Studio

порталы администрирования Майкрософт

Когда политика условного доступа направлена на облачное приложение Майкрософт Admin Portals, политика применяется к токенам, выданным для определенных идентификаторов приложений ресурсов, связанных с порталами администрирования Майкрософт. Группирование приложений не включает внутренние службы, от которых эти порталы могут вызывать или зависеть. Чтобы определить зависимости сервисов административных порталов, используйте отчёты по аудитории условного доступа в журналах входа.

Следующие приложения включают порталы администрирования Майкрософт:

• идентификатор приложения Exchange Admin Center: 497effe9-df71-4043-a8bb-14cf78c4b63b
• идентификатор приложения портала Azure: c44b4083-3bb0-49c1-b47d-974e53cbdf3c
• Microsoft Office 365 идентификатор приложения портала: 0000006-00000-0ff1-ce00-00000000000000
• Microsoft 365 идентификатор приложения Центра безопасности и соответствия требованиям (Центр защиты): 80ccca67-54bd-44ab-8625-4b79c4dc775

Группировка в портале администрирования в первую очередь предназначена для сценариев инклюзии, обеспечивая упрощенный способ нацелить один или несколько порталов администрирования с помощью политик условного доступа (например, для принудительного применения многофакторной аутентификации). Эта группировка используется в MFA для администраторов, управляемых политикой Майкрософт для упрощения создания политики.

Этот параметр не предназначен для работы в качестве механизма массового исключения для всех внутренних служб, связанных с базовыми идентификаторами приложений.

Другие приложения

Администраторы могут добавлять любое Microsoft Entra зарегистрированное приложение в политики условного доступа. Эти приложения могут включать:

• Приложения, опубликованные через Microsoft Entra прокси-сервер приложений
• Приложения, добавленные из коллекции
• Пользовательские приложения, не входящие в коллекцию
• Устаревшие приложения, опубликованные с помощью контроллеров доставки приложений и сетей
• Приложения, использующие единый вход на основе пароля

Некоторые приложения вообще не отображаются в средстве выбора. Единственным способом включения этих приложений в политику условного доступа является добавление Все ресурсы (ранее "Все облачные приложения") или добавление отсутствующего служебного принципала с помощью командлета PowerShell New-MgServicePrincipal или с использованием Microsoft API Graph.

Условный доступ для различных типов клиентов

Условный доступ применяется к ресурсам, а не к клиентам, за исключением случаев, когда клиент является конфиденциальным клиентом, запрашивающим маркер идентификатора.

• Общедоступный клиент
  • Общедоступные клиенты — это те, которые выполняются локально на устройствах, таких как Microsoft Outlook на настольных или мобильных приложениях, таких как Microsoft Teams.
  • Политики условного доступа не применяются к общедоступным клиентам, но основаны на ресурсах, которые они запрашивают.
• Конфиденциальный клиент
  • Условный доступ применяется к ресурсам, запрашиваемым клиентом, и самому конфиденциальному клиенту, если он запрашивает маркер идентификатора.
  • Например, если Outlook Web делает запросы токена для областей Mail.Read и Files.Read, условный доступ применяет политики для Exchange и SharePoint. Кроме того, если Outlook Web запрашивает токен идентификатора, политики условного доступа также применяются для Outlook Web.

Чтобы просмотреть журналы входов для этих типов клиентов из административного центра Microsoft Entra:

1. Войдите в Центр администрирования Microsoft Entra как минимум с ролью читателя отчетов.
2. Перейдите к Entra ID>Мониторинг и работоспособность>журналы входов.
3. Добавьте фильтр для типа учетных данных клиента.
4. Настройте фильтр, чтобы просмотреть определенный набор журналов на основе учетных данных клиента, используемых в входе.

Дополнительные сведения см. в статье Общедоступный клиент и конфиденциальные клиентские приложения.

Условный доступ для всех ресурсов

Применение политики условного доступа ко всем ресурсам (ранее "Все облачные приложения") без исключений ресурсов применяет политику для всех запросов маркеров от веб-сайтов и служб, включая профили пересылки трафика Global Secure Access. Этот параметр включает приложения, которые не могут быть индивидуально нацелены в политике условного доступа, например Windows Azure Active Directory (00000002-0000-0000-c000-000000000000).

Устаревшее поведение условного доступа, если политика всех ресурсов имеет исключение ресурсов

Если любое приложение исключается из политики, чтобы избежать непреднамеренной блокировки доступа пользователей, некоторые области с низкими привилегиями ранее были исключены из применения политики. Эти области действия позволяют вызывать базовые API Graph, такие как Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) и Microsoft Graph (00000003-0000-0000-c000-000000000000), для доступа к профилям пользователей и членству в группах, часто используемым приложениями как часть процесса аутентификации. Например, когда Outlook запрашивает маркер для Exchange, он также запрашивает область User.Read для отображения основных сведений об учетной записи текущего пользователя.

Большинство приложений имеют аналогичную зависимость, поэтому эти области с низким уровнем привилегий были автоматически исключены в политиках всех ресурсов . Ранее исключенные области перечислены следующим образом, согласие по-прежнему требуется для приложений использовать эти разрешения.

• Встроенные клиенты и одностраничные приложения имеют доступ к следующим сферам с низким уровнем привилегий:
  • 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

Новое поведение условного доступа, если политика всех ресурсов имеет исключение ресурсов

Области, перечисленные в предыдущем разделе, теперь оцениваются как доступ к каталогу и сопоставлены с Azure AD Graph (ресурс: Windows Azure Active Directory, идентификатор: 00000002-0000-c000-c0000000000000000000000) для оценки условного доступа.

Политики условного доступа, предназначенные для всех ресурсов с одним или несколькими исключениями ресурсов или политиками, которые явно предназначены для Azure AD Graph, применяются в потоках входа пользователей, где клиентское приложение запрашивает только эти области. Изменений в поведении не происходит, когда приложение запрашивает дополнительный доступ за пределами перечисленных выше.

Рекомендации по оценке влияния, выявлению затронутых приложений и сохранению устаревшего поведения см. в статье "Улучшено применение политик с исключениями ресурсов".

Взаимодействие с пользователем

В потоках входа пользователей, где клиентские приложения запрашивают только указанные выше области доступа, пользователи теперь могут получать вызовы условного доступа (например, многофакторной аутентификации (MFA) или соответствие устройства). Определенная задача зависит от элементов управления доступом, настроенных в политиках, направленных на все ресурсы (с или без исключений ресурсов) или в политиках, которые явно направлены на Azure AD Graph.

В следующем примере клиент имеет политику условного доступа со следующими сведениями:

• Ориентация на всех пользователей и все ресурсы
• Исключения ресурсов для конфиденциального клиентского приложения и Exchange Online
• MFA настраивается в качестве элемента управления предоставлением

Пример сценариев

Нет изменений в поведении, когда клиентское приложение запрашивает сферу за пределы перечисленных ранее, как показано в примерах ниже.

Пример сценариев

Большинство приложений запрашивают области за пределами ранее перечисленных областей и уже подвергаются принудительному применению условного доступа, если приложение явно не исключается из политики. В таких случаях нет изменений в поведении.

Пользовательские приложения, которые намеренно предназначены для запроса только ранее перечисленных областей и не предназначены для обработки проблем условного доступа, может потребоваться обновить, чтобы они могли обрабатывать проблемы условного доступа. Подробности реализации см. в руководстве разработчика Майкрософт по управлению условным доступом.

Как определить, какие приложения затронуты изменением в применении ограничений доступа с низким уровнем привилегий.

Приложения могут быть предварительно авторизованы для запроса только одной или нескольких ранее перечисленных областей. Используйте следующие параметры для выявления затронутых приложений.

# ==============================
# 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 -TenantId $TenantId -Scopes @(
  "DelegatedPermissionGrant.Read.All",
  "Directory.Read.All",
  "Reports.Read.All"
)

# ------------------------------
# Pull oauth2PermissionGrants (paging)
# ------------------------------
$uri = "https://graph.microsoft.com/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://graph.microsoft.com/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://graph.microsoft.com/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

Защита сведений о каталоге

Если рекомендуемая базовая политика многофакторной аутентификации без исключений ресурсов не может быть настроена по деловым причинам, и политика безопасности организации должна включать области с низкими привилегиями, связанные с каталогом (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 включен в ресурсы All> но может быть по отдельности предназначен в политиках условного доступа, выполнив следующие действия.

1. Войдите в Центр администрирования Microsoft Entra в качестве администратора определения атрибутов и администратора назначения атрибутов.
2. Перейдите к Entra ID>Пользовательские атрибуты безопасности.
3. Создайте новый набор атрибутов и определение атрибутов. Дополнительные сведения см. в разделе Добавить или деактивировать определения настраиваемых атрибутов безопасности в Microsoft Entra ID.
4. Перейдите на Entra ID>Enterprise apps.
5. Удалите фильтр типа приложения и найдите идентификатор приложения , который начинается с 00000002-0000-0000-c000-0000000000000000000.
6. Выберите Windows Azure Active Directory>пользовательские атрибуты безопасности>Добавить назначение.
7. Выберите набор атрибутов и значение атрибута, которое планируется использовать в политике.
8. Перейдите к Entra ID>Условный доступ>Политики.
9. Создайте или измените существующую политику.
10. В разделе Целевые ресурсы>Ресурсы (ранее облачные приложения)> под Включить выберите >Выбрать ресурсы>Редактировать фильтр.
11. Настройте фильтр, чтобы включить набор атрибутов и определение из более ранних версий.
12. В разделе "Предоставление>" выберите "Предоставить доступ", "Требовать силу проверки подлинности", выберите многофакторную проверку подлинности, а затем нажмите кнопку "Выбрать".
13. Подтвердите параметры и установите включение политики в режим только для отчетов.
14. Щелкните Создать, чтобы включить эту политику.

Все интернет-ресурсы с глобальным безопасным доступом

Параметр All internet resources with Global Secure Access позволяет администраторам ориентировать профиль пересылки интернет-трафика из Интернет-доступ Microsoft Entra.

Эти профили в Global Secure Access позволяют администраторам определять и контролировать маршрутизацию трафика через Интернет-доступ Microsoft Entra и Частный доступ Microsoft Entra. Профили пересылки трафика можно назначать устройствам и удаленным сетям. Пример применения политики условного доступа к этим профилям трафика см. в статье Как применить политики условного доступа к профилю трафика Microsoft 365.

Дополнительные сведения об этих профилях см. в статье "Профили пересылки трафика с защищённым глобальным доступом".

Все ресурсы агента (предварительная версия)

Применение политики условного доступа ко всем ресурсам агента обеспечивает выполнение политики для всех запросов токенов к основным элементам схемы идентификации агента и агентским удостоверениям.

Действия пользователя

Действия пользователей — это задачи, выполняемые пользователем. Условный доступ поддерживает два действия пользователя:

• Регистрация сведений о безопасности. Это действие пользователя позволяет политикам условного доступа применять правила, когда пользователи пытаются зарегистрировать сведения о безопасности. Дополнительные сведения см. в разделе Объединенная регистрация сведений о безопасности.

• Регистрация или присоединение устройств: Это действие позволяет администраторам применять политику условного доступа, когда пользователи регистрируют или присоединяют устройства к 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 для применения политик условного доступа.

Контекст проверки подлинности

Контекст проверки подлинности защищает данные и действия в приложениях. К этим приложениям относятся пользовательские приложения, бизнес-приложения, SharePoint или приложения, защищенные Microsoft Defender for Cloud Apps. Его также можно использовать с Microsoft Entra управление привилегированными пользователями (PIM) для принудительного применения политик условного доступа во время активации роли.

Например, организация может хранить файлы на SharePoint сайтах, таких как меню обеда или секретный рецепт соуса BBQ. Каждый может получить доступ к сайту меню обеда, но пользователям, обращаюющимся к секретному сайту рецепта соуса BBQ, может потребоваться использовать управляемое устройство и согласиться с конкретными условиями использования. Аналогичным образом, администратору, активировав привилегированную роль через PIM, может потребоваться выполнить многофакторную проверку подлинности или использовать соответствующее устройство.

Аутентификационный контекст работает с пользователями или удостоверениями рабочей нагрузки, но не в рамках той же политики условного доступа.

Настройка контекстов проверки подлинности

Управление контекстами проверки подлинности, перейдя в Entra ID>Conditional Access>Authentication context.

Выберите новый контекст проверки подлинности , чтобы создать определение контекста проверки подлинности. Организации могут создавать до 99 определений контекста проверки подлинности (c1-c99). Настройте следующие атрибуты:

• Display name — это имя, используемое для идентификации контекста проверки подлинности в Microsoft Entra ID и в приложениях, использующих контекст проверки подлинности. Используйте имена, которые можно использовать в ресурсах, таких как доверенные устройства, для уменьшения количества необходимых контекстов проверки подлинности. Ограниченный набор уменьшает количество перенаправлений и обеспечивает лучший пользовательский опыт.
• Описание содержит дополнительные сведения о политиках. Эти сведения используются администраторами и теми, кто применяет контексты проверки подлинности к ресурсам.
• Установите флажок "Опубликовать в приложениях" при выборе, рекламирует контекст проверки подлинности для приложений и делает его доступным для назначения. Если этот параметр не выбран, контекст проверки подлинности недоступен для подчиненных ресурсов.
• Идентификатор доступен только для чтения и используется в маркерах и приложениях для определений контекста проверки подлинности для конкретного запроса. Приведено здесь для устранения неполадок и сценариев использования в разработке.

Добавьте в политику условного доступа.

Администраторы могут выбрать опубликованные контексты проверки подлинности в политиках условного доступа, перейдя в целевые ресурсы и выбрав > в меню Выбор назначения этой политики.

Удаление контекста проверки подлинности

Перед удалением контекста проверки подлинности убедитесь, что приложения не используют его. В противном случае доступ к данным приложения не защищен. Подтвердите это, проверив журналы входа для случаев применения политик условного доступа на основе контекста аутентификации.

Чтобы удалить контекст проверки подлинности, убедитесь, что она не имеет назначенных политик условного доступа и не публикуется в приложениях. Это предотвращает случайное удаление контекста проверки подлинности, который по-прежнему используется.

Пометка ресурсов контекстами проверки подлинности

Дополнительные сведения об использовании контекстов проверки подлинности см. в следующих статьях.

• Использовать метки конфиденциальности для защиты содержимого в Microsoft Teams, группах Microsoft 365 и SharePoint сайтах
• Microsoft Defender for Cloud Apps
• Пользовательские приложения
• управление привилегированными пользователями — для активации требуется контекст проверки подлинности Условный доступ Microsoft Entra

Связанный контент

• Условный доступ: условия— узнайте, как настроить условия для уточнения политик.
• Распространенные политики условного доступа — ознакомьтесь с общими шаблонами политик, чтобы быстро приступить к работе.
• Зависимости клиентского приложения . Узнайте, как зависимости влияют на политики условного доступа.