Поделиться через

Узнайте подробности о действиях журнала входа

  • Статья

Microsoft Entra регистрирует все входы в клиент Azure в целях соответствия требованиям. ИТ-администратор должен знать, на что указывают значения в журналах входа, чтобы правильно интерпретировать значения журнала.

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

Компоненты действий авторизации

В идентификаторе Microsoft Entra действие входа состоит из трех основных компонентов:

  • Кто: личность, пользователь, осуществляющий вход.
  • Как: Клиент (приложение), используемый для доступа.
  • Что: целевой объект (ресурс), к которому обращается идентификатор.

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

Кто

Следующие сведения связаны с пользователем:

  • Пользователь
  • Имя пользователя
  • Идентификатор пользователя
  • Идентификатор входа
  • Тип пользователя

Как

Способ входа пользователя можно определить, взглянув на следующие детали:

  • Требование проверки подлинности
  • Клиентское приложение
  • Тип учетных данных клиента
  • Непрерывная оценка доступа

Что

Вы можете определить ресурс, к который пользователь пытается получить доступ с помощью следующих сведений:

  • Приложение
  • ID приложения
  • Ресурс
  • ИД ресурса
  • ИД клиента ресурса
  • Идентификатор сервисного принципала ресурса

Уникальные идентификаторы

Журналы входа также содержат несколько уникальных идентификаторов, которые предоставляют дополнительные сведения о попытке входа.

  • Идентификатор корреляции: Идентификатор корреляции группирует входы из одного сеанса входа. Значение основано на параметрах, передаваемых клиентом, поэтому идентификатор Microsoft Entra не может гарантировать его точность.
  • Идентификатор запроса: идентификатор, соответствующий выданному токену. Если вы ищете авторизацию с определенным токеном, сначала необходимо извлечь идентификатор запроса из токена.
  • Уникальный идентификатор маркера: уникальный идентификатор маркера, переданный во время входа. Этот идентификатор используется для сопоставления входа с запросом токена.

Сведения о действиях входа в систему

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

Общие сведения

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

Вы также можете запустить диагностику входа на вкладке "Основные сведения". Дополнительные сведения см. в разделе "Использование диагностики входа".

Коды ошибок входа

Если вход не удался, вы можете получить дополнительные сведения о причине на вкладке "Основная информация" в соответствующем журнале. Код ошибки и связанная причина сбоя отображаются в подробных сведениях. Дополнительные сведения см. в разделе "Устранение неполадок при входе".

Снимок экрана: код ошибки входа на вкладке

Расположение и устройство

На вкладках сведений о расположении и устройстве отображаются общие сведения о расположении и IP-адресе пользователя. Вкладка сведений об устройстве содержит сведения о браузере и операционной системе, используемой для входа. Эта вкладка также содержит сведения о том, соответствует ли устройство требованиям, управляется или подключено к гибридному окружению Microsoft Entra.

Подробные сведения о проверке подлинности

Вкладка "Сведения о проверке подлинности" в журнале входа содержит следующие сведения для каждой попытки проверки подлинности:

  • Список примененных политик проверки подлинности, таких как условный доступ или параметры безопасности по умолчанию.
  • Последовательность методов проверки подлинности, используемых для входа.
  • Если попытка аутентификации прошла успешно, указана причина её успеха.

Эти сведения позволяют устранять неполадки при каждом шаге входа пользователя. Используйте эти сведения для отслеживания:

  • Количество входов, защищенных многофакторной аутентификацией.
  • Показатели использования и успешности для каждого метода проверки подлинности.
  • Использование методов проверки подлинности без пароля, таких как вход без пароля и FIDO2.
  • Как часто требования к проверке подлинности удовлетворяются токенами, например, когда от пользователей не требуется вводить пароль или SMS OTP.

Снимок экрана: вкладка

Условный доступ

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

  • Успех: Политика условного доступа была успешно применена к попытке входа.
  • сбой: политика условного доступа была применена к попытке входа, но попытка входа завершилась ошибкой.
  • Не применяется: вход не соответствует критериям применения политики.
    • Существуют конкретные сценарии, которые из-за их природы должны быть исключены из оценки условного доступа, чтобы предотвратить циклическую зависимость (сценарий с курицей и яйцом), которые не могут быть завершены. Эти сценарии считаются "сценариями начальной загрузки" и могут включать авторизацию, связанную с регистрацией устройства, соответствием устройства или соединениями сервера сетевой политики.
    • Входы с использованием Windows Hello для бизнеса отображаются как "Не применены", так как политики условного доступа защищают попытки входа в облачные ресурсы, а не сам процесс входа в Windows.
  • Отключено: политика была отключена во время попытки входа.

Только отчет

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

На этой вкладке журналов входа отображаются результаты попыток входа, которые попадали под действие политики. Дополнительные сведения см. в статье "Что такое режим отчета условного доступа?"

Сведения о входе и рекомендации

Следующие сценарии важно учитывать при просмотре журналов входа.

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

  • Дата и время: дата и время попытки входа локализованы в часовой пояс для пользователя, выполнившего вход в Центр администрирования Microsoft Entra, а не пользователя, который пытался войти.

  • Условный доступ:

    • Not applied: политика не применяется к пользователю и приложению во время входа. Windows Hello для бизнеса отображается как "Не применено", так как политики условного доступа защищают попытки входа в облачные ресурсы, а не процесс входа в Windows. Другие входы могут быть прерваны, поэтому политика не будет применяться.
    • Success: одна или несколько политик условного доступа были применены или оценены для пользователя и приложения (но не обязательно для других условий) во время входа. Несмотря на то, что политика условного доступа может не применяться, если она была оценена, состояние условного доступа показывает успешность.
    • Failure: Вход удовлетворил условия пользователя и приложения по как минимум одной политике условного доступа, однако элементы управления предоставлением либо не были удовлетворены, либо настроены на блокировку доступа.
    • Условный доступ не применяется к входу в Windows, например Windows Hello для бизнеса. Условный доступ защищает попытки входа в облачные ресурсы, а не процесс входа устройства.

  • Оценка непрерывного доступа. Показывает, применена ли оценка непрерывного доступа (CAE) к событию входа.

  • Тип доступа между клиентами. Описывает тип доступа между клиентами, используемый субъектом для доступа к ресурсу. Возможны следующие значения:

    • none — Событие входа, которое не пересекает границы клиента Microsoft Entra.
    • b2bCollaboration — операция входа между арендаторами, выполненная гостевым пользователем с использованием функции B2B-сотрудничества.
    • b2bDirectConnect — вход между арендаторами, выполняемый службой B2B.
    • microsoftSupport— вход между клиентами, выполняемый агентом поддержки Майкрософт во внешнем клиенте Майкрософт.
    • serviceProvider — Межтенантный вход, выполняемый поставщиком облачных услуг (CSP) или аналогичным администратором от имени клиента этого CSP в тенанте.
    • unknownFutureValue — контрольное значение, используемое MS Graph для помощи клиентам в обработке изменений в списках перечислений. Дополнительные сведения см. в статье Рекомендации по работе с Microsoft Graph.

  • Арендатор: Журнал входа отслеживает два идентификатора арендатора, относящихся к межарендаторским сценариям.

    • домашний арендатор — арендатор, которому принадлежит идентичность пользователя. Идентификатор Microsoft Entra отслеживает идентификатор и имя.
    • арендатор ресурсов — арендатор, которому принадлежит ресурс (целевой объект).
    • В связи с обязательствами по конфиденциальности Microsoft Entra ID не заполняет имя домашнего арендатора во время сценариев межарендаторского взаимодействия.
    • Чтобы узнать, как пользователи за пределами вашего арендатора имеют доступ к ресурсам, выберите все записи, в которых домашний арендатор не соответствует арендатору ресурсов.

  • Многофакторная проверка подлинности. При входе пользователя с помощью MFA происходит несколько отдельных событий MFA. Например, если пользователь вводит неправильный код проверки или не отвечает вовремя, больше событий MFA отправляются, чтобы отразить последнее состояние попытки входа. Эти события входа отображаются как один элемент строки в журналах входа Microsoft Entra. Однако это же событие входа в Azure Monitor отображается в виде нескольких элементов строки. У всех этих событий одинаковое correlationId.

  • Требование проверки подлинности: Показывает самый высокий уровень проверки подлинности, необходимый для успешного прохождения всех этапов процесса аутентификации.

    • Graph API поддерживает $filter (eq и startsWith) операторов только.

  • Типы событий входа: указывает категорию события входа.

    • Категория входа пользователя может быть interactiveUser или nonInteractiveUser соответствует значению свойства isInteractive в ресурсе входа.
    • Категория управляемых удостоверений — managedIdentity.
    • Категория сервиса — servicePrincipal.
    • API Microsoft Graph поддерживает $filter (только оператор eq).
    • Портал Azure не показывает это значение, однако событие входа в систему размещается на вкладке, соответствующей типу события входа в систему. Возможные значения:
      • interactiveUser
      • nonInteractiveUser
      • servicePrincipal
      • managedIdentity
      • unknownFutureValue

  • Тип пользователя: примеры включают member, guestили external.

  • Сведения о проверке подлинности:

    • Код проверки OATH регистрируется как метод проверки подлинности для аппаратных и программных маркеров OATH (например, приложение Microsoft Authenticator).
    • Вкладка сведений о проверке подлинности изначально может отображать неполные или неточные данные, пока данные журнала не будут полностью агрегированы. Известные примеры:
      • При первоначальной регистрации событий входа сообщение соответствует утверждению в токене неправильно отображается.
      • Строка первичной проверки подлинности изначально не логируется.
    • Если вы не уверены в деталях в журналах, соберите идентификатор запроса и идентификатор корреляции, чтобы использовать для дальнейшего анализа или устранения неполадок.
    • Если применяются политики условного доступа для проверки подлинности или времени существования сеанса, они перечислены выше попыток входа. Если вы не видите ни одного из этих вариантов, эти политики в настоящее время не применяются. Дополнительные сведения см. в разделе "Элементы управления сеансами условного доступа".