DeviceDetail.deviceId в Entra ID и Microsoft Authenticator для MFA

Поле DeviceDetail.deviceId в журналах входа Entra ID представляет собой уникальный идентификатор устройства, которое участвовало в многофакторной аутентификации с помощью Microsoft Authenticator. Чтобы идентифицировать это устройство, проверьте Device Info в логах или используйте PowerShell для фильтрации по deviceId, сопоставив его с зарегистрированными устройствами в Entra ID. Устройство для Microsoft Authenticator не обязано совпадать с тем, на котором был первоначальный вход — подойдет любое другое с установленным приложением и настроенной MFA.

Содержание

• Что такое поле DeviceDetail.deviceId в журналах Entra ID
• Как идентифицировать устройство с Microsoft Authenticator
• Анализ логов входа: Device Info и Authentication Details
• Фильтрация по deviceId с помощью PowerShell
• Нужно ли устройство MFA совпадать с устройством первоначального входа
• Практические рекомендации по настройке и проверке
• Источники
• Заключение

Что такое поле DeviceDetail.deviceId в журналах Entra ID

Представьте: пользователь входит в корпоративный портал, проходит первичную проверку, а потом ему прилетает push-уведомление на телефон с Microsoft Authenticator. Именно в этот момент в журналах Entra ID (бывший Azure AD) фиксируется не только факт входа, но и детали устройства, которое подтвердило многофакторную аутентификацию. Поле DeviceDetail.deviceId — это ключевой элемент в разделе Authentication Details. Оно содержит уникальный идентификатор устройства, на котором запущено приложение Authenticator и произошло одобрение MFA.

Почему это важно? Без deviceId админы слепы к тому, откуда именно пришла вторая фактор — с корпоративного ноутбука, личного смартфона или вообще с эмулятора. Согласно официальной документации Microsoft Learn, это поле появляется именно при методах вроде Microsoft Authenticator — push, номер телефона или даже биометрия. DeviceId генерируется Entra ID на основе аппаратных характеристик и регистрации устройства, делая его стабильным маркером.

Но вот загвоздка: deviceId не всегда виден в простом интерфейсе. В CSV-экспорте логов или JSON-ответах API оно прячется внутри DeviceDetail. Если вы новичок в Entra ID, начните с портала admin.microsoft.com — там в Sign-in logs это поле разворачивается при клике на запись. А для глубокого анализа подключайте Graph API или PowerShell. В общем, это не просто строка символов, а ваш компас в лабиринте MFA-логов.

Как идентифицировать устройство с Microsoft Authenticator

Идентифицировать устройство по DeviceDetail.deviceId проще, чем кажется, но требует пары шагов. Сначала откройте Entra admin center, перейдите в Identity > Monitoring & health > Sign-in logs. Выберите подозрительный вход, кликните на него — и вот оно, Device Info. Там deviceId, OS, браузер и даже IP. Скопируйте значение и ищите совпадения в списке устройств пользователя.

Дальше — магия сопоставления. В Entra ID устройства регистрируются автоматически при первой MFA или вручную через Intune. Зайдите в Devices > All devices, фильтруйте по пользователю и сравните deviceId. Если совпадает — bingo, это тот самый смартфон с Authenticator. Как отмечает эксперт Marilee Turscak из Microsoft Q&A, для BYOD-устройств (bring your own device) это особенно полезно: Authenticator регистрирует deviceId при первом сканировании QR-кода.

А что если deviceId не в списке? Тогда проверьте unregistered devices — иногда MFA работает на гостевых гаджетах. Или используйте Microsoft Graph: запросите /auditLogs/signIns с фильтром по deviceDetail. Вы удивитесь, сколько инсайтов даст такая проверка. Кстати, для мобильных устройств Authenticator часто показывает deviceId в настройках приложения — раздел Accounts > QR-код для перерегистрации.

Анализ логов входа: Device Info и Authentication Details

Журналы входа в Entra ID — это золотая жила для security-анализа. Вкладка Device Info раскрывает deviceId, location и даже trust level (доверенное ли устройство). А в Authentication Details увидите, как именно завершилась многофакторная аутентификация: “Microsoft Authenticator - push notification approved” с привязанным DeviceDetail.deviceId.

Разберем на примере. Допустим, лог показывает: DeviceDetail = { “deviceId”: “abc123-def456” }. Это значит, что push ушел именно на устройство abc123-def456. Сравните с Intune: Devices > поиск по ID. Если там Android/iOS с Authenticator — вопрос решен. Tony Redmond в Office 365 for IT Pros подчеркивает: экспорт в CSV упрощает массовый анализ, но для deviceId лучше JSON.

Плюс риски: если deviceId меняется (редко, но бывает при сбросе устройства), логи покажут несоответствие. Фильтруйте по статусу Success/Failure — часто фейковые MFA приходят с чужих deviceId. И не забудьте Conditional Access: там можно заблокировать MFA с unregistered устройств.

Фильтрация по deviceId с помощью PowerShell

PowerShell — ваш лучший друг для автоматизации. Подключитесь к AzureAD: Install-Module AzureAD, Connect-AzureAD. Затем выньте логи:

Get-AzureADAuditSignInLogs -Filter "deviceDetail/deviceId eq 'abc123-def456'" | Select-Object UserPrincipalName, AppDisplayName, DeviceDetail

Этот cmdlet вытащит все входы с конкретным deviceId. Ищите Microsoft Authenticator в AuthenticationMethods. Для Graph API — еще мощнее:

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=deviceDetail/deviceId eq 'abc123-def456'

Как советует Marilee Turscak, комбинируйте с Get-AzureADUserRegisteredDevice для полного матчинга. Скрипт на 10 строк сэкономит часы ручной работы. А если тенант большой? Используйте AllDevices — deviceId там уникален в пределах пользователя.

Проблема? Retention логов — 30 дней по умолчанию. Настройте Log Analytics для долгосрочного хранения.

Нужно ли устройство MFA совпадать с устройством первоначального входа

Короткий ответ: нет, не нужно. Первоначальный вход может быть с корпоративного ПК (deviceId: pc-xyz), а MFA — с телефона (deviceId: phone-abc). Entra ID не требует синхронизации — главное, чтобы Authenticator был зарегистрирован на аккаунт. Документация Microsoft Learn прямо подтверждает: устройство MFA независимо.

Почему так? MFA — это вторая линия обороны, и гибкость упрощает жизнь. Пользователь логинится с ноутбука дома, подтверждает на смартфоне в кармане. Но риски есть: если злоумышленник перехватит сессию, чужой deviceId выдаст фишинг.

В Conditional Access настройте “Require device to be marked as compliant” — тогда MFA только с доверенных устройств. Идеально для enterprise.

Практические рекомендации по настройке и проверке

Начните с аудита: еженедельно тяните логи по топ-устройствам MFA. В Intune включите device compliance для Authenticator — там deviceId синхронизируется автоматически. Для пользователей: при регистрации сканируйте QR в Authenticator, чтобы deviceId зафиксировался.

Если подозрения — заблокируйте deviceId в Entra: Devices > Block sign-in. Тестируйте: создайте тестовый пользователь, войдите с двух гаджетов, сравните логи.

Масштаб? Интегрируйте Sentinel: алерты на новые deviceId в MFA. И помните о privacy — deviceId не раскрывает личные данные, но логи храните по GDPR.

Источники

1. Microsoft Learn — Документация по отчетам MFA и журналам входа в Entra ID: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-reporting
2. Microsoft Q&A — Объяснение DeviceDetail.deviceId и PowerShell-фильтрации от Marilee Turscak-MSFT: https://learn.microsoft.com/en-us/answers/questions/1302373/sign-in-logs
3. Office 365 for IT Pros — Анализ устройств MFA и экспорта логов от Tony Redmond: https://office365itpros.com/2024/03/14/entra-id-registered-device-mfa/

Заключение

DeviceDetail.deviceId — мощный инструмент для трекинга Microsoft Authenticator в многофакторной аутентификации Entra ID, позволяющий быстро идентифицировать устройства без лишней мороки. Главное takeaway: оно не привязывает MFA к первоначальному устройству входа, давая гибкость, но требуя строгого мониторинга. Регулярно анализируйте логи с PowerShell, настройте политики — и ваша MFA станет железобетонной.