Входы AD FS в идентификаторе Microsoft Entra с помощью Connect Health — предварительная версия
Теперь входы AD FS можно интегрировать в отчет о входе Microsoft Entra с помощью Connect Health. Отчет отчета о входе в Microsoft Entra содержит сведения о том, когда пользователи, приложения и управляемые ресурсы входят в идентификатор Microsoft Entra и доступ к ресурсам.
Агент Connect Health для AD FS сопоставляет несколько идентификаторов событий, полученных от AD FS (набор событий зависит от версии сервера), и предоставляет сведения о запросах на вход и ошибках в случае сбоя запроса. Эти сведения коррелируются со схемой отчета о входе в Microsoft Entra и отображаются в пользовательском интерфейсе отчета о входе в Microsoft Entra. Наряду с этим отчетом предоставляется новый поток Log Analytics с данными из AD FS и новый шаблон книги Azure Monitor. Этот шаблон можно свободно использовать и изменять для подробного анализа в таких сценариях, как блокировка учетных записей AD FS, неудачные попытки ввода пароля и резкое увеличение количества попыток входа.
Необходимые компоненты
- Microsoft Entra Connect Health для AD FS установлен и обновлен до последней версии (3.1.95.0 или более поздней).
- Роль читателя отчетов для просмотра входов Microsoft Entra
Какие данные отображаются в этом отчете?
Доступные данные зеркально отражают те же данные, которые доступны для входа в Microsoft Entra. Пять вкладок с информацией доступны на основе типа входа, идентификатора Microsoft Entra или AD FS. Connect Health сопоставляет события из AD FS (разные в зависимости от версии сервера) со схемой AD FS.
События входа пользователей
На каждой вкладке в колонке событий входа отображаются значения по умолчанию, описанные ниже.
- дата входа;
- Идентификатор запроса
- имя или идентификатор пользователя;
- состояние входа;
- IP-адрес устройства, с которого выполнялся вход;
- идентификатор входа.
Сведения о способе проверки подлинности
На вкладке "Проверка подлинности" могут отображаться указанные ниже значения. Способ проверки подлинности берется из журналов аудита AD FS.
| Метод проверки подлинности | Description |
|---|---|
| Формы | Аутентификация по имени пользователя и паролю |
| Windows | Встроенная проверка подлинности Windows |
| Сертификат | Проверка подлинности с использованием сертификатов смарт-карты или VirtualSmart |
| WindowsHelloForBusiness | Это поле используется для проверки подлинности с использованием Windows Hello для бизнеса (проверка подлинности Microsoft Passport). |
| Устройство | Отображается, если для проверки подлинности устройства выбрано значение Primary (Первичная). Выполняется проверка подлинности из интрасети или экстрасети, а также проверка подлинности устройства. В этом сценарии нет отдельной проверки подлинности пользователей. |
| Федеративные | AD FS не делала проверку подлинности, но отправляла ее стороннему поставщику удостоверений. |
| Единый вход | Если использовался токен единого входа, это поле отображается. Если единый вход имеет MFA, он отображается как Multifactor |
| Многофакторная | Если маркер единого входа имеет MFA и использовался для проверки подлинности, это поле отображается как Multifactor |
| Многофакторная проверка подлинности Microsoft Entra | Многофакторная проверка подлинности Microsoft Entra выбрана в качестве дополнительного поставщика проверки подлинности в AD FS и использовалась для проверки подлинности. |
| ADFSExternalAuthenticationProvider | Это поле обозначает, зарегистрирован ли сторонний поставщик проверки подлинности и использовался ли он для проверки подлинности. |
Дополнительные сведения из AD FS
Доступны следующие сведения о входах в AD FS:
- Server Name (Имя сервера)
- цепочка IP-адресов;
- Протокол
Включение Log Analytics и Azure Monitor
Log Analytics можно включить для входов в AD FS и применять совместно с любыми другими компонентами, интегрированными с Log Analytics, например с Sentinel.
Примечание.
Попытки входа в AD FS могут значительно повысить стоимость использования Log Analytics в зависимости от количества операций входа AD FS в вашей организации. Чтобы включить или отключить Log Analytics, установите или снимите флажок для потока.
Чтобы включить эту возможность в Log Analytics, перейдите в колонку Log Analytics и выберите поток ADFSSignIns. Этот выбор позволяет входам AD FS передаваться в Log Analytics.
Чтобы просмотреть обновленный шаблон книги Azure Monitor, перейдите в раздел "Шаблоны Azure Monitor" и выберите книгу sign-ins (входы). Дополнительные сведения см. в статье Книги Azure Monitor.
Вопросы и ответы
Какие типы событий входа я могу увидеть? Отчет о попытках входа поддерживает события входа через протоколы O-Auth, WS-Fed, SAML и WS-Trust.
Как в отчете о входе отображаются различные типы входов? Если выполняется простой единый вход, существует одна строка для входа с одним идентификатором корреляции. Если выполняется однофакторная проверка подлинности, две строки заполняются одинаковым идентификатором корреляции, но двумя различными методами проверки подлинности (то есть forms, SSO). В случаях многофакторной проверки подлинности есть три строки с общим идентификатором корреляции и тремя соответствующими методами проверки подлинности (то есть forms, Microsoft Entra multifactor authentication, Multifactor). В нашем примере значение Multifactor означает, что для единого входа используется многофакторная проверка подлинности.
Каковы ошибки, которые я вижу в отчете? Полный список связанных ошибок AD FS, заполненных в отчете о входе и описаниях, см . в справке по коду ошибки AD FS.
Я вижу "0000000000-0000-0000-0000-0000000000000" в разделе "Пользователь" входа. Что это значит? Если сбой входа и попытка имени участника-пользователя не соответствует существующему имени участника-пользователя, поля "Пользователь", "Имя пользователя" и "Идентификатор пользователя" — "000000000-0000-0000-0000-000000000000000" и "Идентификатор входа", заполненного введенным пользователем значением, введенным пользователем. В таких случаях пользователь пытается войти в систему не существует.
Как сопоставить локальные события с отчетом о входе Microsoft Entra? Агент Microsoft Entra Connect Health для AD FS сопоставляет идентификаторы событий из AD FS, зависящие от версии сервера. События доступны в журнале безопасности серверов AD FS.
Почему в поле "Идентификатор или имя приложения" для некоторых входов AD FS отображается NotSet или NotApplicable? Отчет о входе AD FS отображает идентификаторы OAuth в поле идентификатора приложения для входа OAuth. В сценариях входа WS-Trust WS-Trust идентификатор приложения NotSet или NotApplicable, а идентификаторы ресурсов и идентификаторы проверяющей стороны присутствуют в поле "Идентификатор ресурса".
Почему поля "Идентификатор ресурса" и "Имя ресурса" отображаются как "Не заданы"? Поля ResourceId/Name являются NotSet в некоторых случаях ошибок, например "Имя пользователя и пароль неверный", а также в ошибках входа на основе WSTrust.
Существуют ли более известные проблемы с отчетом в предварительной версии? В отчете есть известная проблема, из-за которой поле "Требование проверки подлинности" на вкладке "Основные сведения" заполняется как одно значение проверки подлинности для входа AD FS независимо от входа. Кроме того, на вкладке "Сведения о проверке подлинности" отображается поле "Основной или вторичный" в поле "Требование" с исправлением для отличия типов первичной или вторичной проверки подлинности.