Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье рассматриваются требования и настройка ключей проверки подлинности в Microsoft Authenticator для Microsoft Entra ID.
Перед выполнением действий, описанных в этой статье, включите ключи доступа и создайте профиль ключа доступа. Инструкции см. в разделе "Включить ключи доступа" (FIDO2) в Microsoft Entra ID.
Предварительные требования для ключей доступа в Authenticator
Учетная запись с разрешением как минимум Authentication Policy Administrator на настройку методов аутентификации.
Необходимо включить вход секретного ключа в политику Passkey (FIDO2) в методах проверки подлинности в Центр администрирования Microsoft Entra.
Android 14 и более поздних версий или iOS 17 и более поздних версий.
Для регистрации и проверки подлинности между устройствами:
Убедитесь, что Bluetooth и активное подключение к Интернету включены на обоих устройствах. Если ваша организация ограничивает использование Bluetooth, вы можете разрешить связывание Bluetooth исключительно с аутентификаторами FIDO2, поддерживающими пароли, чтобы обеспечить вход и регистрацию устройств с использованием паролей. Ваша организация должна разрешить подключение к конечным точкам в следующей таблице, чтобы включить регистрацию и проверку подлинности между устройствами. Устройства должны быть разрешены для доступа к этим URL-адресам. Дополнительные сведения о требованиях к устройствам Apple см. в разделе "Использование продуктов Apple в корпоративных сетях".
Platform URL Андроид cable.ua5v.comiOS cable.auth.comapp-site-association.cdn-apple.comapp-site-association.networking.apple
Примечание.
Пользователи не могут использовать регистрацию между устройствами, если включить аттестацию.
Дополнительные сведения о поддержке FIDO2 см. в разделе Поддержка проверки подлинности FIDO2 с помощью идентификатора Microsoft Entra ID.
Примечание.
Если вы предоставляете контроль «Требовать, чтобы устройство было помечено как соответствующее» в рамках политики условного доступа, это не блокирует доступ приложения Microsoft Authenticator к области UserAuthenticationMethod.Read. Аутентификатор должен получить доступ к области UserAuthenticationMethod.Read во время настройки Аутентификатора, чтобы определить, какие учетные данные пользователь может настроить. Authenticator должен получить доступ к UserAuthenticationMethod.ReadWrite, чтобы зарегистрировать учетные данные, при этом оставаясь в рамках проверки Требуется, чтобы устройство было отмечено как соответствующее.
Настройка профиля для ключей доступа в Authenticator
Войдите в центр администрирования Microsoft Entra в качестве как минимум администратора политики аутентификации.
Перейдите к Entra ID>методам проверки подлинности.
На странице Методы проверки подлинности | Политики выберите Passkey (FIDO2)>Настроить.
Выберите + Добавить профиль.
Введите имя профиля, например ключи доступа Authenticator.
Выберите, следует ли применять аттестацию. Дополнительные сведения см. в разделе «Аттестация аутентификатора».
Для типов секретных ключей выберите привязку к устройству.
Выберите целевой объект AAGUIDS и задайте для параметра "Разрешить поведение".
Выберите + Добавить AAGUID>Microsoft Authenticator и Сохранить.
Включение профиля ключей доступа в Authenticator и настройка целевых групп
Войдите в центр администрирования Microsoft Entra в качестве как минимум администратора политики аутентификации.
Перейдите к Entra ID>методам проверки подлинности.
На странице Методы проверки подлинности | Политики выберите Ключ доступа (FIDO2)>Включить и назначить.
На вкладке Enable and Target убедитесь, что для параметра Enable установлено значение On.
Выберите "Добавить целевой объект" и выберите "Все пользователи" или "Выбрать" , чтобы выбрать определенные группы.
Выберите профиль для ключей доступа в Authenticator и нажмите Сохранить.
Примечание.
Целевая группа (например, инженерия) может быть ограничена для нескольких профилей ключей доступа. Если пользователь имеет область действия для нескольких профилей секретного ключа, регистрация и проверка подлинности с помощью секретного ключа разрешены, если ключ доступа полностью соответствует требованиям по крайней мере одного из профилей доступа с заданной областью. Нет определенного порядка для проверки. Если пользователь входит в исключённую группу в политике Passkey (FIDO2), ему полностью запрещаются регистрация и вход с использованием ключа доступа (FIDO2). Блок имеет приоритет над членством в любых включенных группах.
Аттестация аутентификатора
После включения ключей доступа и создания профиля ключа доступа в центре администрирования Microsoft Entra можно выбрать, следует ли требовать аттестацию. Общие действия по настройке профилей доступа см. в разделе "Включение ключей доступа" (FIDO2).
Если аттестация включена, Microsoft Entra ID проверяет легитимность создаваемого секретного ключа. Когда пользователь регистрирует секретный ключ в Authenticator, аттестация проверяет, что законное приложение Authenticator создало пароль с помощью служб Apple и Google:
iOS: аттестация приложения Authenticator использует службу App Attest от iOS для обеспечения легитимности приложения Authenticator перед регистрацией пароля.
Андроид:
- Для проверки целостности Play проверка Authenticator использует API Play Integrity, чтобы обеспечить легитимность приложения Authenticator перед регистрацией ключа доступа.
- Для аттестации ключей аттестация Authenticator использует аттестацию ключей Android для проверки, что регистрируемый ключ поддерживается оборудованием.
Примечание.
Для iOS и Android аттестация Authenticator использует службы Apple и Google для проверки подлинности приложения Authenticator. Интенсивное использование служб может привести к сбою регистрации секретного ключа, и пользователям может потребоваться повторить попытку. Если службы Apple и Google отключены, проверка подлинности блокирует регистрацию, требующую аттестации, пока службы не будут восстановлены. Чтобы отслеживать состояние службы целостности Google Play, см . панель мониторинга состояния Google Play. Сведения о состоянии службы аттестации приложений iOS см. в разделе "Состояние системы".
Пользователи могут регистрировать только тестированные ключи непосредственно в приложении Authenticator. Потоки регистрации между устройствами не поддерживают регистрацию подтвержденных ключей доступа.
Authenticator AAGUIDs
Вы можете разрешить пользователям использовать только ключи доступа Authenticator, указав глобально уникальный идентификатор аттестации аутентификатора (AAGUID) в профиле ключа доступа.
Если вы предпочитаете, можно также выбрать +Добавить AAGUID и вручную добавить следующие AAGUID:
-
Authenticator для Android:
de1e552d-db1d-4423-a619-566b625cdc84 -
Authenticator для iOS:
90a3ccdf-635c-4729-a248-9b709135078f
Если удалить AAGUID, который вы ранее разрешили, пользователи, которые ранее зарегистрировали разрешенный метод, больше не могут использовать его для входа.
Включите ключи доступа в Authenticator с помощью Graph Explorer
Помимо использования Центр администрирования Microsoft Entra, можно включить ключи доступа в Authenticator с помощью обозревателя Graph. Если вам назначена роль администратора политики аутентификации или выше, вы можете обновить политику методов аутентификации, чтобы разрешить использование AAGUID для аутентификаторов.
Примечание.
В следующем примере используется конечная точка конфигурации FIDO2 уровня клиента. Подход на основе профиля к управлению ключами см. в разделе "Включение ключей доступа" (FIDO2).
Чтобы настроить политику с помощью обозревателя Graph, выполните следующие действия.
Войдите в Graph Explorer и дайте согласие на разрешения Policy.Read.All и Policy.ReadWrite.AuthenticationMethod.
Получите политику методов проверки подлинности:
GET https://graph.microsoft.com/v1.0/authenticationMethodsPolicy/authenticationMethodConfigurations/FIDO2Чтобы включить принудительную проверку аттестации и ограничения для ключей, разрешив для аутентификатора только AAGUID, выполните операцию
PATCH, используя следующее тело запроса:PATCH https://graph.microsoft.com/v1.0/authenticationMethodsPolicy/authenticationMethodConfigurations/FIDO2 Request Body: { "@odata.type": "#microsoft.graph.fido2AuthenticationMethodConfiguration", "isAttestationEnforced": false, "keyRestrictions": { "isEnforced": true, "enforcementType": "allow", "aaGuids": [ "90a3ccdf-635c-4729-a248-9b709135078f", "de1e552d-db1d-4423-a619-566b625cdc84" <insert previous AAGUIDs here to keep them stored in policy> ] } }Убедитесь, что политика доступа (FIDO2) обновлена должным образом.
GET https://graph.microsoft.com/v1.0/authenticationMethodsPolicy/authenticationMethodConfigurations/FIDO2
Ограничить использование Bluetooth для ключей доступа в Authenticator
Некоторые организации ограничивают использование Bluetooth, включая использование ключей доступа. В таких случаях организации могут разрешать пароли доступа, разрешая пару Bluetooth исключительно с аутентификаторами FIDO2 с поддержкой паролей доступа. Дополнительные сведения о настройке использования Bluetooth только для ключей доступа см. в разделах "Секретные ключи" в средах с ограниченным доступом Bluetooth.
Устраните неполадки с ключами доступа в Authenticator
В этом разделе рассматриваются проблемы, которые пользователи могут видеть при использовании секретных ключей в Authenticator и возможных способах их устранения администраторами.
Хранение ключей доступа в профилях Android
Секретные ключи в Android используются только из профиля, в котором они хранятся. Если секретный ключ хранится в профиле Android Work, он используется из этого профиля. Если секретный ключ хранится в личном профиле Android, он используется из этого профиля. Чтобы убедиться, что пользователи могут получить доступ к ключу доступа и использовать необходимый ключ доступа, пользователи с личным профилем Android и профилем Android Work должны создавать ключи доступа в Authenticator для каждого профиля.
Обходные пути для цикла политики условного доступа проверки подлинности
Пользователи могут попасть в цикл при попытке добавить ключ доступа в приложении Authenticator, если политика условного доступа требует фишингоустойчивой аутентификации для доступа к всем ресурсам (ранее — "Все облачные приложения"). Рассмотрим пример.
- Условие: все устройства (Windows, Linux, macOS, Windows, Android)
- Целевой ресурс: все ресурсы (ранее "Все облачные приложения")
- Управление предоставлением доступа: Надёжность аутентификации — требовать ключ доступа в Authenticator
Политика заставляет пользователей использовать секретный ключ для входа во все облачные приложения, включая приложение Authenticator. Для этого пользователям требуется использовать секретный ключ при попытке добавить ключ доступа в Authenticator в Android или iOS.
Ниже приведены некоторые обходные пути.
Вы можете отфильтровать приложения и перенести целевой объект политики из всех ресурсов (ранее "Все облачные приложения") в определенные приложения. Начните с анализа приложений, которые используются в вашем арендаторе. Используйте фильтры, чтобы пометить Authenticator и другие приложения.
Чтобы сократить затраты на поддержку, вы можете запустить внутреннюю кампанию, чтобы помочь пользователям внедрять секретные ключи, прежде чем применять их. Когда вы будете готовы применить использование секретного ключа, создайте две политики условного доступа:
- Политика версий мобильной операционной системы (ОС)
- Политика в отношении версий настольных ОС
Требуется другая сила проверки подлинности для каждой политики и настройка других параметров политики, перечисленных в следующей таблице. Вы можете включить временный проход доступа (TAP) для пользователей или включить другие методы проверки подлинности, чтобы помочь пользователям зарегистрировать секретный ключ.
TAP ограничивает период, в течение которого пользователи могут зарегистрировать ключ доступа. Его можно принять только на мобильных платформах, где разрешена регистрация секретного ключа.
Политика условного доступа ОС для настольных компьютеров Мобильная ОС Name Требовать ключ доступа в Authenticator для доступа к настольной ОС. Требовать TAP, учетные данные, устойчивые к фишингу, или любой другой указанный метод аутентификации для доступа к мобильной ОС. Условие Определенные устройства (настольные операционные системы). Определенные устройства (мобильные операционные системы). Devices N/A. Android, iOS. Исключить устройства Android, iOS. N/A. Целевой ресурс Все ресурсы. Все ресурсы. Предоставить управление Надежность проверки подлинности. Надежность проверки подлинности. 1 Methods Ключ доступа в Authenticator. TAP, секретный ключ в Authenticator. Результат политики Пользователи, которые не могут выполнить вход с помощью ключа доступа в приложении Authenticator, перенаправляются в режим мастера Мои входы. После регистрации им будет предложено войти в Authenticator на своем мобильном устройстве. Пользователи, которые войдите в Authenticator с помощью TAP или другого разрешенного метода, могут зарегистрировать ключ доступа непосредственно в Authenticator. Цикл не возникает, так как пользователь соответствует требованиям проверки подлинности. 1Чтобы пользователи могли регистрировать новые методы входа, элемент управления доступом в мобильной политике должен соответствовать политике условного доступа для регистрации сведений о безопасности.
Примечание.
При использовании обходного решения пользователи также должны удовлетворять любой политике условного доступа, предназначенной для регистрации сведений о безопасности , или они не могут зарегистрировать секретный ключ. Если у вас есть другие условия, настроенные с помощью политик всех ресурсов , эти условия должны выполняться при регистрации ключа доступа.
Пользователи, которые не могут регистрировать секретные ключи из-за требования утвержденного клиентского приложения или требовать элементы управления условным доступом политики защиты приложений
Пользователи не могут регистрировать ключи доступа в Authenticator, если они включены в следующую политику условного доступа:
- Условие: все устройства (Windows, Linux, macOS, Windows, Android)
- Целевой ресурс: все ресурсы (ранее "Все облачные приложения")
- Управление предоставлением: требовать утвержденное клиентское приложение или требовать политику защиты приложений
Политика требует, чтобы пользователи входили во все облачные приложения с помощью приложения, поддерживающего политики защиты приложений Microsoft Intune. Authenticator не поддерживает эту политику в Android или iOS.
Ниже приведены некоторые обходные пути.
Вы можете отфильтровать приложения и перенести целевой объект политики из всех ресурсов (ранее "Все облачные приложения") в определенные приложения. Начните с проверки приложений, которые используются в вашем арендаторе. Используйте фильтры для тегов соответствующих приложений.
Вы можете использовать управление мобильными устройствами (MDM) и элемент управления Требовать, чтобы устройство было помечено как соответствующее требованиям. Authenticator может удовлетворять этому элементу управления предоставлением доступа, если MDM полностью управляет устройством и устройство соответствует требованиям. Рассмотрим пример.
- Условие: все устройства (Windows, Linux, macOS, Windows, Android)
- Целевой ресурс: все ресурсы (ранее "Все облачные приложения")
- Управление предоставлением: требовать утвержденное клиентское приложение или требовать политику защиты приложений или требовать, чтобы устройство было помечено как соответствующее
Вы можете предоставить пользователям временное исключение из политики условного доступа. Рассмотрите возможность использования одного или нескольких компенсирующих элементов управления:
- Разрешить исключение только в течение ограниченного периода времени. Сообщайте пользователю, когда ему разрешено зарегистрировать ключ доступа. Удалите исключение по истечении срока. Затем порекомендуйте пользователям позвонить в службу поддержки, если они пропустили назначенное время.
- Используйте другую политику условного доступа, чтобы пользователи регистрируются только из определенного сетевого расположения или соответствующего устройства.
Примечание.
При использовании любого предлагаемого обходного решения пользователи также должны соответствовать всем политикам условного доступа, которые применяются к регистрации сведений о безопасности, иначе они не смогут зарегистрировать ключ доступа. Если у вас есть другие условия, настроенные с помощью политик всех ресурсов , они также должны быть выполнены, прежде чем пользователи смогут зарегистрировать секретный ключ.
Регистрация ключа доступа в Authenticator
После того как администратор включит ключи доступа в приложении Authenticator, пользователи смогут зарегистрировать ключ доступа в приложении на своем устройстве iOS или Android.
Инструкции по регистрации см. в разделе "Регистрация секретного ключа" в Microsoft Authenticator.
Вход с помощью ключа доступа в Authenticator
После регистрации пользователи могут войти в Microsoft Entra ID с помощью секретного ключа в Authenticator на своем устройстве.
Инструкции по входу см. в разделе "Вход с помощью секретных ключей" в Authenticator.
Связанное содержимое
- Включение секретных ключей (FIDO2) в идентификаторе Microsoft Entra
- Регистрация секретного ключа в Microsoft Authenticator
- Вход с помощью секретных ключей в Authenticator
- метод проверки подлинности Microsoft Authenticator
- Поддержка проверки подлинности FIDO2 с помощью идентификатора Microsoft Entra
- Поддержка секретного ключа в Windows