Входы AD FS в идентификаторе Microsoft Entra с Подключение Работоспособности — предварительная версия
Теперь входы AD FS можно интегрировать в отчет о входе Microsoft Entra с помощью Подключение Работоспособности. Отчет отчета о входе в Microsoft Entra содержит сведения о том, когда пользователи, приложения и управляемые ресурсы входят в идентификатор Microsoft Entra и доступ к ресурсам.
Агент Connect Health для AD FS сопоставляет несколько идентификаторов событий, полученных от AD FS (набор событий зависит от версии сервера), и предоставляет сведения о запросах на вход и ошибках в случае сбоя запроса. Эти сведения коррелируются со схемой отчета о входе в Microsoft Entra и отображаются в пользовательском интерфейсе отчета о входе в Microsoft Entra. Наряду с этим отчетом предоставляется новый поток Log Analytics с данными из AD FS и новый шаблон книги Azure Monitor. Этот шаблон можно свободно использовать и изменять для подробного анализа в таких сценариях, как блокировка учетных записей AD FS, неудачные попытки ввода пароля и резкое увеличение количества попыток входа.
Необходимые компоненты
- Microsoft Entra Подключение Health for 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 не выполнили проверку подлинности, а передали процесс стороннему поставщику удостоверений. |
| Единый вход | Это поле будет отображаться, если использовался маркер единого входа. Если используется единый вход с многофакторной проверкой подлинности, будет отображаться значение Multifactor. |
| Многофакторная | Если для маркера единого входа используется многофакторная проверка подлинности и она выполнялась при входе, в этом поле будет отображаться значение Multifactor. |
| Многофакторная идентификация Azure | Служба Azure MFA выбрана в качестве дополнительного поставщика проверки подлинности в 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. Это действие позволит передавать в Log Analytics сведения о входах в AD FS.
Чтобы просмотреть обновленный шаблон книги Azure Monitor, перейдите в раздел "Шаблоны Azure Monitor" и выберите книгу sign-ins (входы). Дополнительные сведения см. в статье Книги Azure Monitor.
Вопросы и ответы
Какие типы событий входа я могу увидеть? Отчет о попытках входа поддерживает события входа через протоколы O-Auth, WS-Fed, SAML и WS-Trust.
Как разные типы входов отображаются в отчете о входах? Если выполняется вход в систему без единого входа, будет одна строка для входа с одним идентификатором корреляции. Если выполняется однофакторная проверка подлинности, отображаются две строки с одинаковым идентификатором корреляции, в которых будут разные способы проверки подлинности (например, Forms и SSO). Если выполняется многофакторная проверка подлинности, отображаются три строки с общим идентификатором корреляции и тремя разными способами проверки подлинности соответственно (например, Forms, AzureMFA и Multifactor). В нашем примере значение Multifactor означает, что для единого входа используется многофакторная проверка подлинности.
Каковы ошибки, которые я вижу в отчете? Полный список связанных ошибок AD FS, заполненных в отчете о входе и описаниях, см . в справке по коду ошибки AD FS.
Я вижу "00000000-0000-0000-0000-000000000000" в разделе "Пользователь" при входе. Что это обозначает? Если вход не удался, и имя участника-пользователя, используемое при попытке входа, не соответствует существующему имени участника-пользователя, поля "Пользователь", "Имя пользователя" и "Идентификатор пользователя" будет иметь значение "00000000-0000-0000-0000-000000000000", а поле "Идентификатор входа" будет заполнено введенным пользователем значением. Все это означает, что была выполнена попытка входа с несуществующим именем пользователя.
Как сопоставить локальные события с отчетом о входе Microsoft Entra? Агент работоспособности Microsoft Entra Подключение для AD FS сопоставляет идентификаторы событий из AD FS, зависящие от версии сервера. Эти события будут отображаться в журнале безопасности для серверов AD FS.
Почему в поле "Идентификатор или имя приложения" для некоторых входов AD FS отображается NotSet или NotApplicable? Отчет о входе AD FS будет отображать идентификаторы OAuth в поле идентификатора приложения для входа OAuth. В сценариях входа WS-Trust wS-Trust идентификатор приложения будет иметь значение NotSet или NotApplicable, а идентификаторы ресурсов и идентификаторы проверяющей стороны будут присутствовать в поле "Идентификатор ресурса".
Почему для полей "Идентификатор ресурса" и "Имя" отображается значение NotSet? Поля "Идентификатор ресурса" и "Имя" будут иметь значение NotSet при некоторых ошибках, таких как ошибки,с вязанные с неправильными именем пользователя и паролем, и в случае неудачных попыток входа в систему через WSTrust.
Есть ли еще какие-нибудь известные проблемы с отчетом в предварительном просмотре? В отчете есть известная проблема, при которой поле "Требование проверки подлинности" на вкладке "Основные сведения" будет иметь значение однофакторной проверки подлинности для попыток входа в AD FS независимо от входа. Кроме того, на вкладке "Сведения о проверке подлинности" в поле "Требование" отображается "Первичная или вторичная". Сейчас мы готовим исправление, которое позволит различать первичный и вторичный типы проверки подлинности.