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

Поддержка секретных ключей в Authenticator в клиенте Идентификатора Microsoft Entra

  • Статья

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

Хранение ключей доступа в профилях Android

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

Обходные пути

Используйте следующие обходные пути для проблем с ключами доступа Authenticator.

Обходные пути для цикла политики условного доступа проверки подлинности

Пользователи могут попасть в цикл при попытке добавить ключ доступа в Authenticator, если политика условного доступа требует фишинг-устойчивой аутентификации для доступа к Все ресурсы (ранее "Все облачные приложения"). Например:

  • Условие: все устройства (Windows, Linux, macOS, Windows, Android)
  • Целевой ресурс: все ресурсы (ранее "Все облачные приложения")
  • Управление доступом: сила проверки подлинности — требовать ключ-пароль в Authenticator

Политика заставляет пользователей использовать секретный ключ для входа во все облачные приложения, включая приложение Authenticator. Для этого пользователям требуется использовать секретный ключ при попытке добавить ключ доступа в Authenticator в Android или iOS.

Ниже приведены некоторые обходные пути.

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

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

    • Политика версий мобильной операционной системы (ОС)
    • Политика для версий ОС для настольных компьютеров

    Требуется другая сила проверки подлинности для каждой политики и настройка других параметров политики, перечисленных в следующей таблице. Вы можете включить временный пропуск доступа (TAP) для пользователей или включить другие методы аутентификации, чтобы помочь пользователям зарегистрировать ключ доступа.

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

    Политика условного доступа Настольная ОС Мобильная ОС
    Имя. Для доступа к настольной операционной системе требуется пароль в Authenticator. Требовать TAP, учетные данные, стойкие к фишингу, или другой указанный метод проверки подлинности для доступа к мобильной ОС.
    Условие Определенные устройства (настольные операционные системы). Определенные устройства (мобильные операционные системы).
    Устройства N/A. Android, iOS.
    Исключить устройства Android, iOS. N/A.
    Целевой ресурс Все ресурсы. Все ресурсы.
    Предоставить управление Надежность проверки подлинности. Надежность проверки подлинности.1
    Методы Ключ доступа в Authenticator. TAP, секретный ключ в Authenticator.
    Результат политики Пользователи, которые не могут войти с помощью ключа доступа в Authenticator, направляются в режим мастера входа My Sign-ins. После регистрации им будет предложено войти в Authenticator на своем мобильном устройстве. Пользователи, которые войдите в Authenticator с помощью TAP или другого разрешенного метода, могут зарегистрировать ключ доступа непосредственно в Authenticator. Цикл не возникает, так как пользователь соответствует требованиям аутентификации.

    1 Чтобы пользователи смогли зарегистрировать новые методы входа, управление предоставлением прав для мобильной политики нужно сопоставить с политикой условного доступа для регистрации информации о безопасности.

Примечание.

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

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

Пользователи не могут регистрировать ключи доступа в Authenticator, если они включены в следующую политику условного доступа:

  • Условие: все устройства (Windows, Linux, macOS, Windows, Android)
  • Целевой ресурс: все ресурсы (ранее "Все облачные приложения")
  • Управление доступом: Требовать утвержденное клиентское приложение или Требовать политику защиты приложений

Политика заставляет пользователей входить во все облачные приложения с помощью приложения, которое поддерживает политики защиты приложений Microsoft Intune. Authenticator не поддерживает эту политику в Android или iOS.

Ниже приведены некоторые обходные пути.

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

  • Вы можете использовать управление мобильными устройствами (MDM) и контроль , требующий, чтобы устройство было отмечено как соответствующее,. Authenticator может удовлетворить этот элемент управления доступом, если MDM полностью управляет устройством и оно соответствует требованиям. Например:

    • Условие: все устройства (Windows, Linux, macOS, Windows, Android)
    • Целевой ресурс: все ресурсы (ранее "Все облачные приложения")
    • Управление предоставлением: Требовать наличие утвержденного клиентского приложения, или Требовать наличие политики защиты приложений, или Требовать, чтобы устройство было помечено как комплаентное.

  • Вы можете предоставить пользователям временное исключение из политики условного доступа. Рекомендуется использовать один или несколько компенсирующих элементов управления:

    • Разрешить исключение только в течение ограниченного периода времени. Сообщите пользователю, когда они могут зарегистрировать ключ доступа. Удалите льготу после истечения периода времени. Затем попросить пользователей позвонить в службу поддержки, если они пропустили свое время.
    • Используйте другую политику условного доступа, чтобы пользователи регистрируются только из определенного сетевого расположения или соответствующего устройства.

Примечание.

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

Ограничьте использование Bluetooth для паролей в Authenticator

Некоторые организации ограничивают использование Bluetooth, включая использование ключей доступа. В таких случаях организации могут разрешать ключи-пароли, позволяя сопряжение Bluetooth исключительно с аутентификаторами FIDO2, поддерживающими ключи-пароли. Дополнительные сведения о настройке использования Bluetooth только для ключей доступа см. в разделах "Секретные ключи" в средах с ограниченным доступом Bluetooth.

Связанное содержимое